Founder Friday is a weekly guest post written by a founder who is based in or hails from the Silicon Prairie. Each month, a topic relevant to startups is presented and founders share lessons learned or best practices utilized on that topic. December’s topic is outside development.
About the authors: Andy Kallenbach is the founder of FormZapper and We Solve Tech.
We launched FormZapper a little more than a year ago, have always used some form of outside development and have been pleased with the result. Although I have many years of software development experience, I chose to outsource the majority of our work for the benefits of dependable talent and the lower payroll commitment.
However, outside development requires a much larger commitment to communication.
A contractor won’t be in the office every day to absorb information and will not have the same motivation to help the company succeed. Founding teams will need to overcome this by spending significant time as a project manager, wireframing (with tools like Balsamiq), and regular updates (daily or weekly).
Many outsides developers want a completely laid out project that is planned from A to Z. Being a startup, this is often difficult with the pace of change and shifting priorities. We completely map out development and expectations for 1- to 2-week goals and have larger objectives in the future that are purposely left a little fuzzy. While this is not quite an A to Z list, it has been a good compromise. One thing that contract developers loathe is “feature creep,” and you should be cognizant of trying to avoid adding features unnecessarily in the middle. Providing regular goals to a contractor without moving the goal posts provides a high level of success and satisfaction for both parties involved. If you are setting 1- to 2-week goals, introducing a new idea after the current goal is achieved is mostly a non-issue.
I prefer a web development company versus individual contractors. A development company may want a larger time commitment, but they will have talented individuals with different skill sets and added capacity that may be needed to complete your project successfully. With an individual you will be subject to the whims of their other clients. Unless you sourced up a rock-star contractor, you may also have some sub-par parts of the project that would have been evened out by a larger balanced team.
It’s important that you have an advisor, a third-party auditor or a tech-related person to ensure nothing fishy is going on with your project, and to help the company define a good standard or process for your development cycle. Don’t leave the choice of the language or framework that your project is written in entirely up to an outsourced developer. There are a thousand stories of outside developers that have produced a terribly written mess that can be mitigated by having someone to lean on for advice.
Own your code. Developers should be committing changes to a code repository that you own. You should know how to look at it and how to grant others access to it. I also require developers to make comments on each code update to know what was accomplished. Beyond this you should also have legal protections for code your developers write with an intellectual property agreement drawn up by your attorney.
If you are a company providing a technology product, it is important to build your factory. Maybe you hire outside contractors or a mix of employees and contractors, but they all work in your factory. As such, here are some key things to assist you in a smooth running operation:
Onboarding process. Know how to onboard new developers efficiently. Provide access to code, development environment setup and architecture overview
Coding practices. Have a list of acceptable languages and frameworks. Define standard for code commenting and format (doesn’t have to be overbearing, but at a minimum you should require code commenting and keep code neat).
Testing. Have a separate platform for testing new updates.
Code Repository. Separate current development code from production code. Require some frequency of code commits. Committed code should compiled, be commented and the commit itself should include a description or overview of main changes.
Stage Site. This can sometimes be skimped on, but becomes important to have a site to deploy approved changes to that mimics your production site as closely as possible. This will minimize downtime or issues when making changes to your production site.
Update windows. Have acceptable update times for stage and production. Be capable of announcing updates to users as needed.
Bug lists/feedback/support. Have standard processes for collecting feedback from users, keeping track of bugs that need to be fixed and being able to provide customers with quick support on issues.
Maintenance. Have standard procedures for server restarts, fixing of production code and how to handle emergency issues with production.
The benefits of outside development are being able to source talented individuals with the flexibility to scale your outgoing costs as needed. The downside is the extra communication and added time and processes needed to support a flexible development team. As with many things, planning is the key to a success.
Credits: Photo from LinkedIn.
