Smoothing the transition from prototype to production

I’ve been talking to a number of startups hiring developers at various stages of development that are having problems gaining momentum in getting their product built. This often stems from not having a core technical expertise they can rely on for advice and to ensure things are built properly. Having a product built properly allows new features to be added easier, less surprises happen and the software runs smoothly. Another source of the problem is not knowing how much time and resources should be invested as the concept is unproven.

This situation can seem to be a catch 22, to build a product properly it takes more time and resources than to put together a prototype product. To over rely on a prototype product can prevent in fully capitalizing on an opportunity in the future and to scale too soon can delay product release and resources.

My preference is to take the low risk option by only investing what you can justify. If there is a proven high demand for the idea then building a more complex prototype can be done. If the demand is not proven, then spend more time fostering the demand or be willing to take the risk. The is central to any business looking for a return on investment.

The question is, how do you transition from the prototype phase to production quality phase smoothly without hindering the growth of the business ?

To answer is not so simple, in some aspects there is an art to it and in others there is many common pitfalls that can be avoid. Let me start with an outline of the progression that I’ve seen many companies go threw and second some recommendations to avoid common pitfalls.

Progression of getting a product built

The first stage is a startup is looking for someone to build version one of the product, usually for the lowest cost possible as it is unknown if the product is worth continuing with and little requirements are put on the technical requirements of the codebase. Having a low level requirements and utilizing junior developers in this case can reduce costs as it may be more important to test an idea then to build a foundation for a future product. The trap is that your prototype code written quickly gets turned into a production application which sets the stage for disorganization.

The next stage is they have a code base built and hired a number of developers to get to where they are. As a result there is usually two or three different frameworks and or languages that make up their product which is put together in what ever way works. At this point they are starting to run into problems getting more advanced features added or getting features added consistently. Bugs are also starting to appear and maybe at random. A company might persist in this state for a number of years particularly if the product is profitable and if features do manage to get added.

The third stage is where it is recognized the code base needs to be cleaned up and it is holding back growth of the company. Usually at this point the founders have developed a fair amount of knowledge around the development process and are starting to seek out a core technical person or have become more technical. The goal is to create new code in a standardized way and in a manner that allows additional features to be added.

The four stage is the company has a core technical team, has a set of standards and an organized code base, development cycle and is looking to regularly roll out features. At this point companies usually have a good idea of what type of developer they want to hire and what they want them to produce. Problems faced at this stage is is trying to find developers who fit their mold exactly or not having a quality on boarding process to allow smart developers who can learn the development environment.

This may seem like an acceptable route to take as progress is continuously made, often at the cost of sweat, blood and tears. Essentially it involves hiring several developers over the time span as the founders learn the ropes of getting a product developed one piece at a time. This route can consume a significant amount of time, finances, emotional energy and allow for competitors to get an edge.

Is there a better way ?

The proposed alternative is to recruit a trusted senior technical advisor or technical founder earlier on in the process to ensure proper standards are in place. The second part founders being more proactive in learning the development process and assessing what is needed to be built. If you are building a technology based product then knowing what you are getting into is key so you have the ability to make decisions. This is not necessarily knowing enough to be a rockstar but understanding the process and what is done at the ground level makes proper decision making easier to do.

When proper standards and practices are in place then it is a small cost at the beginning with a large savings down the road. With more understanding of the technology then the hiring process goes smoother, you get access to more talented staff and that staff can do a better job.

Simple best practices

The good news is there is plenty of guides on best practices out there some basics are

  1. Test your assumptions before building
  2. Use an organized development process like agile
  3. For anything more than the absolute basics test start using an object oriented development framework. Model View Controller is an example of such
  4. Be proactive about keeping things organized and efficient

The following are a few resources, feel free to suggest some more

For non technical founders

http://justinmares.com/what-the-non-technical-need-to-know-about-tech/

http://www.groovehq.com/blog/non-technical-founder

Hiring process

http://www.quora.com/Stripe-company/What-is-the-engineering-interview-process-like-at-Stripe

http://www.fastcolabs.com/3015662/want-to-recruit-better-developers-give-them-broken-code

http://www.forbes.com/sites/theyec/2013/07/26/how-to-hire-a-programmer-even-if-you-dont-know-code/

MVC Best practices

http://www.yiiframework.com/doc/guide/1.1/en/basics.best-practices

http://blog.codinghorror.com/understanding-model-view-controller/

Leave a Reply

Your email address will not be published. Required fields are marked *