8 min Read
Building an MVP with AI Tools, and What Still Takes Judgment
AI compresses build time. It does not decide what belongs in version one, and that decision moves the cost far more than the tooling.
Nikhil Sharma
Key takeaways
- AI has made building faster and has not made deciding what to build any easier, which means scope discipline matters more now, not less
- The cheapest MVP is the one that tests the riskiest assumption first, even when that assumption is uncomfortable
- Faster prototyping tempts teams into building more, which is the exact failure MVPs exist to prevent
- Code generated quickly still has to be owned, understood and maintained by someone after launch
Building software got dramatically faster in the last two years. Deciding what to build got no easier at all.
That gap is where most MVP budgets now disappear, and it is worth understanding before you start, because the tooling actively makes the problem worse.
The temptation the tools create
When building was slow, scope discipline enforced itself. Every feature had a visible cost in weeks, so somebody pushed back.
Now a feature can be prototyped in an afternoon. The friction that used to protect you is gone, and the natural response is to build more, because you can. Six months later there is a large product, a burned budget, and still no clear answer to whether anyone wants the thing.
The MVP was never a cost saving exercise. It is a learning exercise. Cheaper building has not changed what needs to be learned, it has just removed the excuse for not building everything.
Start with the assumption, not the feature list
Before any scope conversation, one sentence: this only works if X is true.
Then: what is the cheapest way to find out whether X is true.
Sometimes the honest answer is not software. If the assumption is that a particular profession will pay for something, twenty conversations will tell you more than a build. If the assumption is that a workflow can be automated reliably enough to trust, then you do need to build, because nothing else will settle it.
Most products that fail did not fail on execution. They executed well against an assumption nobody had tested, and the build was the most expensive possible way to discover it was wrong.
Cut toward the risk, not away from it
The usual instinct when cutting scope is to cut the hard things and ship the easy ones. That produces something demonstrable and answers nothing.
If the risky part is whether your matching algorithm produces results people accept, then the algorithm is version one and the account management can wait. If the risky part is whether people will complete a long onboarding, then onboarding is the product and the rest can be manual behind the scenes.
Version one should be uncomfortable. It should be missing things you feel embarrassed about, and it should contain the one thing you are least sure of.
What manual is fine for
An enormous amount of an early product can be a person doing something by hand while the interface implies otherwise. Matching, moderation, onboarding, support, even fulfilment.
This is not cheating. It is the fastest way to learn what the automated version needs to do, because you find out from real cases rather than from guessing. Automate the parts that hurt, in the order they hurt, once you know their actual shape.
Where AI genuinely helps
- Scaffolding. The boilerplate that used to take a week now takes an afternoon and is largely the same everywhere.
- Unfamiliar territory. Working in a language or framework you do not know well is dramatically less painful.
- Throwaway prototypes. Building something specifically to be discarded is now cheap enough to do properly.
- Tests. Coverage that teams used to skip under deadline is now realistic.
Where it does not help is the part that decides whether you have a business: which assumption is riskiest, what evidence would settle it, and what to leave out.
Own what gets generated
One practical warning. It is now possible to accumulate a large amount of code that nobody on your side has read.
That is fine while it works. It becomes expensive the first time something breaks at an inconvenient moment and nobody can explain what the system does. Someone has to understand what is running. Whether it was typed or generated does not change that, and the speed makes it easier to skip.
The sequence that works
Write the assumption. Decide what evidence settles it. Cut everything that does not produce that evidence. Build the uncomfortable part first. Do the rest by hand until it hurts.
That is the whole method, and none of it is about tooling. If you want it done against your specific project, with the architecture and a real number attached, that is an MVP Roadmap.
FAQ
Quick answers to the most common questions about this topic.
Sixty to ninety days from kickoff to something real in front of users is a reasonable target for a focused scope. The variable that moves it most is not engineering speed, it is how quickly decisions get made on the client side. Projects slip in the gap between asking a question and getting an answer far more often than in the building.
It reduces build time meaningfully, and build time was never the largest cost on a badly scoped project. A tightly scoped MVP built with AI assistance is cheaper than it was two years ago. A sprawling one is just as expensive as it ever was, and arrives sooner in a worse state.
The smallest thing that tests whether the core assumption holds. Not the smallest useful product, and definitely not the smallest impressive one. If you already know users want it and the question is whether you can deliver it profitably, the MVP tests delivery, not desire.
It is good enough to build on and it is not good enough to ignore. The failure pattern is accepting large volumes of code nobody has read, which works right up until something breaks and no one can say why. Generated or not, someone on your side has to understand what is running.
Write down the assumption being tested and the specific evidence that would settle it, before building anything. Every proposed feature then gets one question: does this change what we learn. Most do not, and having the assumption written down is what makes that answerable rather than political.
Written by
Nikhil Sharma
Founder, DigiBenders
Twelve years shipping software, five of them leading a studio in New Brunswick. I build the software and run the marketing around it, which is an unusual combination and the reason most of my work arrives by referral. One person accountable, and everything ends up in your name.
You read the thinking
Now tell me what you are actually building.
If this was useful, the call usually is too. You describe the problem, I tell you what it takes and whether I am the right person for it.
Thirty minutes, no pitch
Honest read, including when the answer is no
Replies within one business day
Keep reading
