During working in early-stage startups in multiple roles, I’ve released over 10 MVPs and witnessed about 80% of them sadly fail regardless of engineering quality but at the same time, I also often found engineers including myself are in a tug-of-war between higher quality and corner-cutting in engineering.
This is a likely discussion of engineering quality confusion in early-stage startups.
A manager at a startup: “Look, we have 5 months of runway. Does that make sense?”
Junior dev from large corp: “Yes. But if you don’t use Terraform we wont be able to see our infrastructure changes over time. We don’t even have a proper code review process.”
A manager at a startup: “We have two micro instances. Do not install Terraform. Finish the important prototype… now.”
Junior dev from large corp: “Sigh, ok, just saying in 2 years from now we wont be in a good spot”.
Engineering quality is not only about code quality but also includes a wide range of engineering decisions and practices such as documentation, system design, hiring, architecting, test (if any) coverage, code review, etc. A startup will end up owing unpayable technical debts in the long run if it doesn’t build good engineering quality in the development process for a long period of time.
In big tech companies, most engineers with plentiful project resources undoubtedly follow the rule — “keeping highest quality as much” since they are very likely not to consider the product market fit or business continuity into the engineering standard. The engineering here tends to be conservative and risk-averse rather than agile because they have a lot to lose by low-quality engineering, while startups don’t. Pre-PMF startups under survival pressure just need to test their hypothesis ASAP in the market and quickly move out if it turns out nobody wants their new novel product. There is never enough time and resources to invest in quality for them.
The dilemma is that we know keeping higher engineering quality is a high return investment for the long run, but it can be challenging to find the right starting time for startups that live in the short-term and are resource constrained.
BUT, what if our product suddenly gets an overnight success? wouldn’t the accrued technical debts become a blocker?
As a go-to-market product or MVP has more features and finally gets the desired traction a lot, the underlying application architecture may begin to reveal its limitations. This is the point where many pre-PMF startups find short-term technical convenience has ironically become a blocker to long-term success. What if we mitigate this expected issue without slowing down the iteration speed?
The solution
Taking shortcuts for being agile is unavoidable for pre-PMF startups. Quality is only valued if it helps them survive. After that, it’s a matter of choosing between cutting or keeping corners, and the decision requires experience (which is why startups love to hire experienced engineers). There are, however, things that could be one-way-door decisions. Startups would want to spend enough effort on these.
Things that require a huge effort to change:
- Flexibility in system architecture (database selection, API design, caching layer, etc)
- Cloud & infrastructure service provider
- Engineering team quality & hiring bar (firing is way harder than hiring)
- Hard dependency code implementation (e.g., written in assuming the db interface will never be changed)
- Code structure (class design, data abstraction level, React component policy, convention, etc)
Things that can be (relatively) changed or added later:
- Code
- Security
- Documentation
- Tests in all levels (unit tests, E2E tests, automated tests)
- Operation (logs, monitoring, alarms, dashboard, etc)
- Scaling management (it is arguable, but many scaling solutions are available nowadays)
- Deployment & release process
Automation is a key to optimizing development efficiency. Using tools such as code style auto-linter, Git repo-based CI/CD integration, preview staging, and Slack hook saves a lot of manual effort, and a worthwhile setup early.
For scaling, using off-the-shelf cloud or SaaS solutions is a good option and a general approach. Nowadays, most solutions support a reasonable amount of traffic and can scale up with just a few clicks (and the bill, though). When it comes to the cost, there are many ways to get 1–2 years of free cloud credits for startups.
For code quality, design review is mandated while code review is arguably optional in the pre-PMF stage, but having time-to-time discussions about code reviews and tests with the team is a good start. Once it resonates with the team, adoption would be a soft landing when necessary. A post-commit review is a good alternative.
Hiring is an area having a huge impact on engineering quality and many pre-PMF startups inevitably compromise it because of the hiring difficulty. Since small startups are relatively less preferred among a majority of candidates compared to big techs and large startups, they either lower the bar or end up with out-sourcing or part-time internships. I think it is ok, but believe checking a ‘growth’ mindset is critical when hiring or referring someone for a startup. In startups, (almost) everything is up to the growth of the company and individuals.
— — — — — —
Related an interesting article: Why Product Innovation Slows After the Series A?
