build decisions

Stop Building MVPs: Build This Instead

Imran GardeziFebruary 27, 202613 min read

You paid $50K to build your software. It worked. Users signed up. Everything looked great. Then six months later they tell you: "We need another $150K to fix it."

What the hell happened?

I'll tell you what happened. You built an MVP.

Everyone has advice about building your first product. Two camps. Both wrong.

Camp one. The lean startup crowd. "Build it cheap. Build it fast. Validate. Iterate." Sounds smart. In practice? You end up with a cheap build that becomes an expensive rewrite. The "iterate" part sounds harmless until you realize that iterating on a broken foundation is like renovating a house with a cracked slab. Every improvement you make is temporary because the base can't support it.

Camp two. The new wave. "Don't build an MVP at all. Create a clickable prototype. Pre-sell it. Validate demand first. THEN build the real thing." Also sounds smart. Also breaks in practice. You validate demand. Now you need to build. So you hire the cheapest developers you can find to "just make it work for real." And you're right back in the same trap as camp one.

"Both paths lead to the same place. A product that looks like it works but can't scale, can't be maintained, and needs a full rewrite within six months."

I've been building production systems for 15 years. Shopify. Brex. Motorola. Pfizer. I've rebuilt more "MVPs" than I can count. The pattern is always the same.

There's a third option. The one nobody talks about. A production-grade MVP. Costs more upfront. Saves multiples downstream. And you never end up rewriting.

I'm going to tell you three stories. Each one cost over $100K. Each one was completely preventable. Then the framework that prevents it. Then the math that proves it.

The $100K Marketplace

First story.

Founder had an idea for a marketplace. Niche B2B. Connecting suppliers with retailers in a specific vertical. Good idea. Real market. Real pain point. He'd done the research.

He hired a solid agency. Spent $100K. The design was beautiful. Code was clean. Custom matching algorithm. Messaging system. Payment integration. Review system. The full works. Every feature was well-engineered. The problem wasn't execution quality. It was strategic direction.

Launched to crickets.

Nobody used it. Not because it was buggy. Not because the marketing was bad. Because users didn't want a marketplace. They wanted a directory. A simple list of suppliers with contact info. That's it. No matching algorithm. No messaging system. No payment integration. Just a list and a phone number.

"Built a Ferrari when all they wanted was a reliable Honda."

$100K. Twelve months of his life. And the thing that would have worked? A WordPress site with a spreadsheet behind it. He could have tested that in a weekend.

Now, the "prototype first" crowd would tell you this proves their point. "See? He should have validated before building." And they're partly right. He should have validated. But the answer isn't "don't build." The answer is build the RIGHT thing with the RIGHT foundations. If he'd spent two weeks talking to potential users before writing a line of code, he would have discovered that the pain point was discovery, not transactions. That single insight would have redirected the entire build.

His problem wasn't building. It was WHAT he built. No amount of prototyping fixes bad strategy. And no amount of cheap development fixes a wrong product.

Dev Purgatory

Now let me show you the other side.

Different founder. She DID validate. Had customers waiting. Had pre-orders. Had demand. She did everything the lean startup playbook tells you to do. The product was right.

Then she hired a cheap dev team to build the MVP. "Keep it under $20K. We'll iterate later."

They delivered something. It worked. Kind of. Login was flaky. The database was a mess. But it worked. The surface-level functionality masked the structural problems underneath. Users could sign up. They could use the core features. Everything appeared fine for the first few weeks.

Then she wanted to add a feature. Two weeks. Then another feature. Three weeks. Then a bug appeared that nobody could find. Then a different bug appeared that broke the first fix. Each change introduced new instability because the foundation wasn't designed to accommodate growth. The codebase had no separation of concerns, no proper error handling, and a database schema that treated every table like a catch-all spreadsheet.

Six months. Six months of "almost ready to launch." Every week: "just one more thing." Her spouse asked the question every founder dreads. "When is this business going to make money?"

She ran out of runway. Never launched.

"That's Dev Purgatory. Being stuck for months with nothing to show. The 'almost ready' cycle that never ends."

The product was right. The demand was real. The foundation was wrong. And the wrong foundation ate the whole business.

Now here's the version that keeps me up at night. Third founder. She hired three different agencies. One after another. Spent over $100K combined. She had mockups. She had code. She had invoices. She had nothing usable.

Each agency inherited the last one's mess. Each one promised to fix it. Each one made it worse. More code on top of bad code. More features bolted onto broken architecture. The third agency spent their entire engagement just trying to understand what the second agency built, only to discover it was unmaintainable. They started over. On a fresh codebase. With the same flawed approach.

She sat across the table from me and said seven words I'll never forget: "I feel stupid. Everyone else seems to get this."

She wasn't stupid. She was making decisions without the context to evaluate them. Three agencies. Over $100K. Nothing to show. Not because they were scammers. Because the foundation was wrong from day one and nobody had the integrity to say so.

Three founders. Over $300K combined. All preventable. Here's the framework that would have saved every single one of them.

The Third Path

So here's where I disagree with everyone.

Camp one says build cheap and iterate. That gives you Fragile Foundations. Decisions that seem fine today but explode six months from now. The "cheap" in "build cheap" doesn't mean you spend less money total. It means you spend the same money (or more) spread across a painful timeline of patches, fixes, and eventual rewrites.

Camp two says don't build at all. Prototype. Pre-sell. Validate the offer. THEN build. The validation step is correct. But it creates a dangerous gap. Founders end up with a prototype that LOOKS real. They get excited. Customers are waiting. So they hire the cheapest developers they can find to "just make it work for real." The urgency of validated demand pushes them to cut corners on the build, which is the worst possible moment to cut corners because now you have real users depending on the software.

And they end up in Dev Purgatory. Same as camp one. Different entrance, same room.

"The answer is neither cheap MVPs nor prototypes. It's a production-grade MVP."

A production-grade MVP costs more upfront and saves you multiples downstream. The cheap MVP becomes the expensive rewrite. This isn't a philosophical difference. It's a mathematical one. The total cost of the cheap path is nearly always higher than the total cost of the production-grade path.

Everyone tells you speed means cutting corners. It doesn't. Speed is correct sequencing. Building the right thing in the right order with the right foundations. Not skipping steps.

You wouldn't pour a thin foundation and call it a house. But that's exactly what a cheap MVP is. Six months later the foundation cracks. Can't add a second floor. The fix costs 3x more than doing it right the first time. And you have to move out while they do the work.

"Software is the same. Except worse. Because while your software is down for a rebuild, your users don't wait. They leave. And they don't come back."

And here's something nobody tells you. Developers are translators, not strategists. A great developer translates your product vision into code. They don't create the product vision. And they don't create the business strategy. Hiring great developers into a bad plan doesn't fix the plan. It means you have expensive people executing the wrong thing, well. The strategy has to be right before the first line of code is written. No amount of engineering talent compensates for building the wrong product.

"Validate like a scientist. Build like an engineer. That's the sequence."

The Six Non-Negotiables

So what does a production-grade MVP look like?

Six things. Non-negotiable. This is what separates a product that scales from a product that becomes a rewrite.

One. Real authentication. Not rolled from scratch by some developer who thinks they can do it better. Clerk. Auth0. Supabase Auth. $25 a month. Battle-tested. Maintained by teams of security engineers. One breach from homegrown auth and your business is done. Your users are gone. All to save $25 a month. The risk-reward calculation on custom auth is one of the worst in software. You save a trivial amount of money and expose yourself to a business-ending vulnerability. Every week brings news of another company that got breached because someone decided to build their own auth.

Two. Real data model. Schema designed for 10x your current scale from day one. Not "we'll restructure later." Later means migration. Migration means downtime. Downtime means lost users. I've seen database restructuring cost anywhere from $30K to $80K. All because nobody asked "what happens when we have ten times the users?" in month one. A well-designed schema takes a few extra days upfront. A schema migration on a live system with real users takes weeks of careful planning, testing, and execution, plus the risk of data loss at every step.

Three. Error handling. When something fails (and it will) the system fails gracefully. Users see a clear message, not a white screen of death. The team gets an alert. Not a tweet from an angry customer two weeks later. Good error handling is invisible to users when it works. Bad error handling is the first thing they see when something goes wrong. And their impression of your product is shaped far more by how it handles failure than by how it handles success.

Four. Basic observability. You know what's happening in production. Errors are tracked. Performance is measured. You are not flying blind. I've seen companies lose 10% of revenue for months because a checkout bug went undetected. No monitoring. Nobody knew. Users didn't call support. They just left. That silent churn is the most expensive kind because you can't fix what you can't see. By the time someone notices the revenue dip in the quarterly report, you've already lost thousands of users who will never come back.

Five. Sane deploys. CI/CD pipeline. Push code, it gets tested, it gets deployed. Predictable. Repeatable. Not a developer SSHing into a server at midnight and crossing their fingers. Sane deploys aren't just about convenience. They're about safety. Every manual deployment step is a potential point of failure. Automate it once, and you eliminate an entire category of production incidents.

Six. Documentation. Not a 200-page manual. A living document. What the system does. How it's structured. How to deploy it. Remember the Three Agency Client? None of those three agencies left her documentation. That's why every handoff was a disaster. Each new team spent their first month reverse-engineering what the previous team built, and their understanding was never complete.

That's it. Six things. Not fifty. Not a year-long enterprise architecture project. Six foundations that take a few extra weeks upfront and save you months of pain downstream.

And when someone tells you "we'll fix it later," write that down. Because later never comes. You're always under deadline pressure. You're always shipping the next feature. That "fix it later" becomes the technical debt that eats your velocity six months from now.

"Later never comes. Later is the most expensive word in software."

"Real auth. Real data model. Error handling. Observability. Sane deploys. Documentation. Everything else is negotiable. These six are not."

The Math

Everything I just told you? I can prove it with math. And the math is devastating.

The cheap path.

Initial build: $20K to $35K. Ship fast. Everyone's excited. The first few months feel like validation. The product works. Users are signing up. The corners you cut are invisible. Everyone congratulates themselves on the smart decision to keep costs down.

First six months: $15K to $25K in bug fixes, patches, and "just one more thing." Still not stable. Still not scalable. Still "almost ready." The excitement fades as each new feature takes longer than the last. The developers start spending more time debugging existing code than building new features. Every change introduces unexpected side effects.

Rewrite when it can't scale: $80K to $120K. Because you can't patch a bad foundation. You replace it. This is the moment the founder realizes the "cheap" path was the expensive one all along. And the rewrite isn't just money. It's time, momentum, and the trust of early users who sat through months of instability.

Total: $115K to $180K. Plus six to twelve months of lost time. Plus every user who churned during the chaos. Plus the momentum you'll never get back.

The production-grade path.

Initial build: $50K to $75K. Takes a bit longer. Costs a bit more. But the foundation is solid.

Year one maintenance: $10K to $15K.

Total: $60K to $90K. Still working. Still scaling. Still shipping features.

"The 'expensive' option is half the price. Every single time."

And that's just the invoice. Six months spent rewriting is six months you're not growing. For most startups, that's the difference between raising the next round and running out of runway. That's not 2x. That's everything.

Now, I know what you're thinking. "What if I can't afford $50K to $75K?"

Fair. Real question. Here's my answer.

If you can't afford to build it right, you definitely can't afford to build it twice. Scope down. Build fewer features. But build them on a solid foundation. A production-grade MVP with three features beats a cheap MVP with twelve features. Every time. Because those three features work. They scale. They don't need a rewrite. You can add features later on a solid foundation. You can't add a solid foundation later under a live product.

"Scope is negotiable. Foundations are not."

The Acid Test

That's the math. Now let me show you how to tell if you're on the right path or heading for a rewrite.

Here's what happens when you build production-grade from day one.

Month one: You ship. Not a prototype. Not a demo. A real product with real foundations. It handles auth. It handles errors. It monitors itself. It deploys cleanly.

Month three: You're adding features. Not fighting fires. Not patching. Building. Each new feature slots cleanly into the existing architecture because the data model was designed for growth.

Month six: You're scaling. Not rewriting. The foundation holds. You're adding users, adding features, growing revenue. Your competitor who went cheap? They're on rewrite number two. You're on feature number twenty.

"That's the compound effect of correct foundations. Every month the gap widens."

Here are the signals you're on the right path. Features ship in days, not months. Bugs are caught before users see them. New developers ramp up in weeks. Deploys happen without anxiety. You can answer "what happens at 10x scale?" with specifics.

And here are the signals you're in trouble. "Just one more thing" before launch. Every feature breaks something else. Your developer is the only person who understands the code. Deploys happen at midnight with someone watching. "We'll fix it later" appears in every conversation.

Go ask your developer three questions right now.

"What happens at 10x our current users? Show me the test."

"Show me exactly how passwords are stored."

"If you disappeared tomorrow, how does a new developer take over?"

If the answers are vague or defensive, you have a problem. And you know it now before it costs you $150K to learn it later.

If you're the technical co-founder and you've been trying to explain this to your business partner, send them this video. That's the list. That's the math. That's the test.

The Close

Here's the reality.

The MVP debate is a distraction. Everyone's arguing about whether to build cheap or not build at all. Both miss the point.

The question isn't whether to build. It's whether to build right.

The lean startup crowd is right about one thing: validate before you build. The prototype crowd is right about one thing: strategy before execution. Where they're both wrong is what happens next. Both camps treat the build phase as a cost to minimize rather than an investment to optimize. That framing is what leads to cheap builds, expensive rewrites, and wasted years.

Building cheap doesn't save money. It spends money twice. Building a prototype doesn't build a product. It builds an expectation that's expensive to fulfil on a broken foundation.

There's a third path. Validate first. Then build production-grade. Real auth. Real data model. Error handling. Observability. Sane deploys. Documentation. Those six things. Non-negotiable.

"It costs more upfront. It saves you multiples downstream. And you never end up in Dev Purgatory."

I've watched founders burn through $100K building something nobody wanted. I've watched founders burn through $100K across three agencies with nothing to show. I've watched founders with real demand and real customers run out of runway because the foundation was wrong.

Every single one of them would tell you the same thing. Build it right the first time. The "expensive" option is the cheap one.

And yes, I sell this. I know that creates a bias. So don't take my word for it. Take the math. Take the three stories. Ask your developer those three questions. If the answers scare you, that's your signal.

If you've already spent the money and you're sitting on something broken, it's not over. But the next dollar you spend needs to go in the right direction.

"Don't build cheap. Don't avoid building. Build right."

If you're sitting on an idea and you want to build it once (not twice, not three times, once) book a Strategy Session. In 90 minutes, I'll map your production-grade MVP. What to validate. What to build. What to skip. And I'll tell you if you shouldn't build it at all. That's not a sales call. That's a diagnosis.

"The cheap MVP is the most expensive decision you'll ever make. Stop building them."

Key Takeaways

"Build cheap, validate fast" creates Expensive Rubbish. The cheap MVP feels like a smart investment until six months later when bug fixes, patches, and "just one more thing" have cost more than building it right would have. The total cost of the cheap path ($115K-$180K) is nearly always double the production-grade path ($60K-$90K). The "savings" are an illusion.
Prototypes validate demand but create a dangerous urgency gap. Once you've proven demand and customers are waiting, the pressure to ship fast leads founders to hire the cheapest developers available. That urgency produces the same broken foundation as the cheap MVP camp. Different entrance, same room. The validation was right. The build that follows is wrong.
A production-grade MVP costs more upfront and saves multiples downstream. Six non-negotiables separate a product that scales from a product that becomes a rewrite: real authentication, real data model, error handling, basic observability, sane deploys, and documentation. These take a few extra weeks upfront and prevent months of pain, rework, and user churn later.
"We'll fix it later" is the most expensive sentence in software. Later never comes. You're always shipping the next feature, always under deadline pressure. That deferred fix becomes compounding technical debt that eats your engineering velocity. Every month you wait, the fix gets harder, more expensive, and more disruptive. Write down every "fix it later" promise and watch how many actually get fixed.
Scope is negotiable, foundations are not. If you can't afford $50K-$75K, don't cut foundations. Cut features. A production-grade MVP with three features beats a cheap MVP with twelve. Those three features work, scale, and don't need a rewrite. You can always add features later to a solid foundation. You cannot add a solid foundation later under a live product with real users.

Frequently Asked Questions

How much does it really cost to build an MVP, and why do cheap MVPs end up costing more?

A cheap MVP typically costs $20K-$35K upfront, but the true cost over 12-18 months balloons to $115K-$180K when you add bug fixes ($15K-$25K), patches, and the inevitable rewrite ($80K-$120K). A production-grade MVP costs $50K-$75K upfront with about $10K-$15K in year-one maintenance, totaling $60K-$90K. The "expensive" option is roughly half the total cost because you're not paying to solve the same problems twice. Plus, the cheap path costs you six to twelve months of lost growth while you rebuild.

What are the non-negotiable foundations every software product needs from day one?

Six things. Real authentication (use Clerk, Auth0, or Supabase Auth instead of building your own). A real data model designed for 10x your current scale. Proper error handling so users see clear messages instead of white screens. Basic observability so you know what's happening in production. Sane deploys with a CI/CD pipeline instead of manual server access. And documentation so any new developer can understand the system without the original team. These take a few extra weeks and prevent months of expensive rework.

Should I build a prototype first or go straight to building the real product?

Validate first, always. Talk to users. Test demand. But don't confuse validation with prototyping. A clickable prototype validates that people want the concept. It doesn't validate that you can build it sustainably. Once demand is proven, skip the cheap build entirely and go production-grade. The most common failure pattern is: validate successfully, then hire cheap developers to "just make it work," and end up with a foundation that crumbles under real usage. Strategy before code. Production-grade from the first commit.

How do I know if my current software is heading for a rewrite?

Ask your developer three questions. "What happens at 10x our current users? Show me the test." "Show me exactly how passwords are stored." "If you disappeared tomorrow, how does a new developer take over?" Vague or defensive answers are red flags. Other warning signs: every new feature breaks something else, deploys happen at midnight with someone watching, "we'll fix it later" appears in every conversation, and your developer is the only person who understands the codebase. If multiple signals apply, you're likely on the cheap path heading toward a rewrite.

What if I genuinely can't afford $50K-$75K for a production-grade build?

Scope down, not quality down. Build fewer features on a solid foundation rather than more features on a broken one. A production-grade MVP with three features beats a cheap MVP with twelve features because those three features work, scale, and don't need a rewrite. You can always add features later to a solid foundation. You cannot add a solid foundation later under a live product. If $50K is out of reach, consider a Strategy Session ($2K) to map exactly which three features matter most and what the minimum viable production-grade build looks like for your specific case.