Building complex software takes time.
Exactly how long?
Great question. It’s one we get asked. A lot. And our answer has changed over time.
At the outset, we only had a general sense of how much work was entailed.
Months later, after spending countless hours on research and customer discovery, the picture became a lot clearer as to what we were planning to create; so, too, did the overall resource requirements. Along with these came a preliminary timeline and a staffing plan.
Only now, seven months in, after considerable effort designing and actually building the product’s foundation, do we finally have a sufficient grasp of product scope to set a roadmap with reasonable confidence.
We’re incredibly fortunate in the length of runway we have as a startup. And, recognizing this, we’ve been disciplined stewards of our resources, spent carefully, and taken a very calculated and measured approach to product development (as detailed in a prior post).
Our intended path runs contrary to conventional startup wisdom regarding the need to move fast, to be the first to market, to scale quickly, to grow revenue and market share as quickly as possible.
For many startups, the focus is how they can become a significant software company as quickly as possible. In our company, the focus is on how we can achieve this as efficiently as possible. We are making a conscious trade-off in prizing capital efficiency over speed.
The debate of the merits of the two approaches is an interesting one.
On the one hand, the “speed” camp extols the strategic importance of market penetration and points to the manner in which markets reward fast growth.
On the other hand, the counter argument for “capital efficiency” points out that the pitfalls of scaling fast:
- It’s not cost effective. In building software, productivity erodes as developer headcount rises. Want to go 50% faster? Just double the number of engineers. And add some management.
- It creates overhead: not only does each incremental software engineer introduce complexity in the software development process, the rest of the organization must also grow to support increased scaling.
- It reduces the margin for error: missteps are not only easier to make, but, with a higher burn rate, the consequences can be much scarier.
- It’s dilutive: raising more money dilutes investors. Issuing fewer options to more employees dilutes the upside potential for each team member. A bigger team dilutes responsibility and weakens culture.
- It’s restrictive: once you commit to the trajectory of scaling fast, it’s near impossible to get off. One great discussion of one aspect of this is this article.
This is not to say that an emphasis on speed might not be appropriate at some time in the future — once we have a proven, market-beating product, it may very well make sense to invest in scaling sales and customer support fast. And this is certainly not to say that an emphasis on fast scaling isn’t right call for other companies who are in a similar stage to ours.
But for us, right now, we fall firmly on the side of capital efficiency.
Make sure to check out our other the blog posts, and follow Gain Compliance on LinkedIn, Facebook and Twitter.