Creating MVPs - Avoiding Gotchas

It's hard to create an MVP, to build something that demonstrates your core idea, all the while allowing for some "playground" experience for users and still remaining easy to maintain and low effort to build.

In this post, we'll take a broad look at the foundations of MVPs and some areas which should be prioritised.

The Real Purpose of an MVP

"Minimum Viable Product". What does this mean? What does this look like? These are difficult questions to fully explain as it's often hard to quantify. Every idea that reaches MVP stage will differ in the criteria used to define the minimum work required to sufficiently capture the proposed problem and solution. "MVP" is a term laden with expectation which sometimes will be unhelpful, driving founders and creators to over-engineer, or over-sell.

An MVP - in essence - is a proof of concept, one which needs external input to become feasible. It can be extremely simple, as long as it demonstrates a real-world problem and the solution.

Plan Ahead, But Don't Execute Everything

Clarity is key, and not just on the technical roadmap. Brutally, 35% to 42% of startups fail due to "No Market Need" - validating the point that "good ideas" often fail to address a truly painful issue for a large enough group. Founders need to have a clear view of their motives for starting and continuing, their expectations on themselves and on the market, and what the cutoffs are for viability. The key question is "Is this still worth it for me?".

The Modularisation Trap

Even with AI-driven development, there are risks. Agents, unless carefully instructed, have a tendency for verbosity, to create a lot of noise, to over-engineer solutions. They'll happily create a huge mess while confidently declaring success. Without insight into how to develop robust, modular, maintainable software, there's huge potential for a "house of cards" scenario, with a brittle stack and implementation.

Recent benchmarks show that while AI-enabled coding is faster, the actual delivery of quality features is 19% slower due to the massive increase in code review time and logic errors. Speed without structure isn't speed at all.

Little-by-little, step-by-step, piece-by-piece. This should be how MVPs are built. Solid specifications for each stage of the build, with defined functionality, acceptance criteria, and with an understood tolerance for issues on the founder's side, but also on the user's side. Early doors projects must be framed as such, otherwise expectations won't align.

Expect to Bin Work (And Why That's Fine)

Even with planning, careful capturing of functionality, insight into the market, sometimes the best thing to do is start over. It seems like a drastic solution, but scaling requires stability. Retention of a customer base requires - among a thousand other things - speed of turnaround, efficiency of the system, and predictability of outcomes when using the system. Customers don't enjoy buggy software, balk at long wait times for fixes, and are frustrated when promised features are delayed.

All the above can be mitigated somewhat with planning, but moreso with a solid stack, a clean implementation (tests included) - and a view of what's coming up. Accenture's Digital Core Report puts the global cost of technical debt at $2.41 trillion - much of it originating from "speed-to-market" code that was never designed to last, but was also not properly evaluated after market fit was confirmed.

The Tech Stack Question

How to figure out what the correct stack is? A tough question. You're not just weighing up what the system needs to do, you're also considering the staff resources needed to build, then maintain it. You're evaluating the trends in technology to see if there's a promising offering that would be a better fit.

Stability, speed, whatever-the-dev-knows, all of these are of key importance. More than planning? No. But they should influence planning, and to a certain extent what is promised to customers. It is possible to change tech stack but the later this is left, the more it can cost in lost revenue, developer time, and infrastructure spend.

When the MVP Works - What Next?

Does the founder have a plan for "surprise success"? If they do, then kudos to them. This plan should be well structured, include "gotchas" (things that are outside of the control of the company/founder), and show that the offering can grow and expand - likely at pace - as the customers come in. Modern SaaS companies are scaling faster than ever, but the pace can catch many off guard.

If the founder has no plan for post MVP, it's likely they don't have insight into how the future might look, what shape growth might take and perhaps how to handle the changes that are precipitated by onboarding second, third, fourth customers. When this happens, it's a time to collect, consider, and consolidate learning from the MVP stage and come up with a bulletproof plan for the next.

The Gotchas

What isn't a gotcha when first setting out? Here's a few with some mentioned in the post and some which would require more scrutiny:

Slowdowns: technical problems missed in planning, bad hires, unforeseen legislation, staffing changes

Showstoppers: data breaches, system downtime, no market need, technical debt that makes scaling impossible

Mitigation through careful consideration and planning is key. Insight can help avoid pitfalls, can address issues before customers perceive them, can help retain users even when things are bumpy. Bain's research argues that while AI democratises building, architectural planning and tangible quality are what separate survivors from those who fall flat.

If you're building an MVP - or inheriting one that needs rescuing - I've spent eighteen years building and leading engineering teams, including as the former CTO of a startup that navigated the journey from inception to acquisition. I've seen what works, what doesn't, and where the gotchas hide. Get in touch.

References: