The Startup Founder Double Whammy: Low Software Development Success Rates and Startup Gotchas
Expensive Technical Resources, Changing Burn Rates and Technical Debt
We wrote before how after twenty five years the success rate for software development teams across all industries has increased from 16% to only 29% being on time and within budget. The startup founder who enters this arena should be aware of this because they already know that there will be startup gotchas, another way of saying challenges that are unique to startups and early stage companies and unlikely to be an issue with traditional enterprise teams.
These challenges are many. Whether they are bootstrapped or venture-funded, they have extremely limited money for software development, which can be expensive. The product is inevitably going to change frequently so they may need to quickly speed up or slow down development based on feedback on their MVP, the minimum viable product to prove their idea is doable. Lastly they may be too focused on the MVP and proving their idea. If the product is as successful as all founders believe, there will suddenly be more traffic, new devices to support, third-party application integrations needed, etc. Is the product built for that?
Jason Grad is an entrepreneur with an idea for a mobile fundraising platform. He and the rest of his in-house technical team chose Speed & Function, a web application development company, for the following:
- Quality code following best practices
- Frequent communication
- Agile daily scrums
- Good rates
In order to manage his software development costs, Jason seamlessly leveraged Speed & Function resources along with his in-house team to build a successful MVP (minimum viable product) to prove out his product goals. Jason: “The engineers I got from Speed & Function all had 10-20 years of experience and lower rates than their junior counterparts in the US, who may only come with two to three years of experience but cost 2-3 times as much.”
Growing a startup can be hard and having engineers on staff present another challenge. Product feedback and changes in product direction can mean changes in amount of work needed to be done. Jason realized it is hard to modify engineering burn rate when there are only salaried employees doing all of the work. He worked with Speed & Function to be agile with their engineering processes as his business was agile, quickly adapting to the changing demands of startup life.
Low software development success rates often force teams to focus all of their effort on today, trying to get work done on time and within budget. Teams can’t afford to think about whether a solution will handle tomorrow and the next day when there will be more of everything, as noted above. This results in technical debt. Techopedia says: “Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”
Having too much traffic to handle is a problem that most founders would like to have to worry about. But if it happens, it can be disastrous. Yet it’s a problem that can usually be addressed with some upfront work and a technical team with the expertise and a proactive perspective.
What is the decision point for a solution that works today versus one that works today AND in the future? It turns out that it’s usually very early in the process.
Jason knew that he needed a solution with excellent performance and it needed to scale to meet the goals he had.What follows is an example of the difference between building a solution that works today and one that work today AND in the future! The Speed & Function team worked collaboratively with Jason’s team on all decisions.
The key decisions were with the architecture. Access to the database would only be through an API server. This would make for an extremely scalable solution and one that could handle new third party integrations which are unlikely to be known when the product was first imagined. Another was to choose an auto scalable platform, so as traffic increases the amount of API server traffic could be scaled horizontally.
The bottom line is that by making a relatively small investment, they would save a lot of time and money by eliminating performance bottlenecks down the road. This would result in minimizing the technical debt which can haunt a product in the future.
Fast forward to today, the platform has been immensely successful with a significant increase in traffic year after year. The solution worked well initially and has continued to work well thanks to the decisions made at the beginning of the project.
Jason has been able to deal successfully with the Startup Founder double whammy: low software development success rates and startup gotchas of expensive technical resources, changing burn rates and technical debt.
Jason: “I have heard so many horror stories of dev shops and that simply is not the case with Speed & Function. Their Agile methodology conforms to our demands and they communicate clear paths to success and blockers that are in the way. I really appreciate their approach in that we have daily scrums so that I can keep track of the project and help fill in the gaps, where needed. Speed and Function is the best dev shop I have worked with.”