A Technical MVP Isn’t a Product. It’s a Bet That One Exists.

Recently, I wrote about the AI bot I built and how one blue silently became four blues.

It was a design problem, but it was also a warning. When we build quickly without enough deliberate design direction, small decisions multiply. Before long, the experience has drifted, not because anyone made a bad decision, but because too many independent decisions were made quickly.

I am now seeing the same pattern at a much larger scale.

I’m watching the complete rebuilding of a system that is nearly 80% complete as a technical MVP. It is a massive and truly impressive achievement. The platform has been rebuilt from the ground up, decades of technical constraints have been removed, all tech debt resolved, and includes a full lossless data migration.

AI helped make this possible at pace that could never be achieved even with multiple teams of developers.

We’re now at the point where dev speed has outpaced every other function and exposed a different kind of problem. We have a substantial technical product, but not a product foundation.

There were no detailed product or design requirements guiding much of what was built. As a result, there are many surfaces, flows, features, and tickets that need to be reviewed and iterated on. Different areas have different visual treatments, interaction patterns, and assumptions about how users should move through the system.

None of it means the work was wrong. It means it was built to prove what was technically possible, quickly move the project forward, but not yet prove that customers will find it intuitive, coherent, or valuable.

We built a technical MVP. Now we need a Minimal Lovable Product.

The MVP proved something important, modern platforms can be built fast. Lossless migration can be supported fast. Limitations created from years of technical debt can be removed fast.

This is what I’m calling a Bob the Builder moment of “Can we build it? … Yes we can!”

But “it works” is not the same as “people will want to use it.”

A product can be technically viable and still be difficult to understand. It can contain all the required functionality and still feel inconsistent, unfamiliar, or frustrating. It can look modern in individual screens while the end-to-end journey feels like several different products stitched together.

That’s why I am increasingly drawn to the idea of a Minimal Lovable Product (MLP).

An MVP asks: Can we build this?

An MLP asks: Will customers want to use it?

“Lovable” does not mean adding glitter and rainbows. It means the product is useful, intuitive, trustworthy, coherent, and ready for customers to adopt with confidence.

It means users shouldn’t have to work out which design pattern applies in this part of the product, or remember different rules between screens, or suffer through hundreds of tiny paper cuts. It means product behaviour should feel intentional and consistent. It means quality is not something we cross our fingers and hope for at the end; it’s something we define as part of the product up front.

The moment the debt moved

For years, technical debt has been the enemy of software modernisation.

Old frameworks. Brittle dependencies. Slow delivery. Workarounds that become permanent. Bolt ons to avoid rather than fix tech debt. A codebase shaped by years of disconnected decisions.

AI can quickly help reduce some of that debt. It can accelerate architecture, code generation, documentation, test drafting, and implementation.

But it does not eliminate all debt. It can just as quickly move it.

I’ve watched the tech debt quickly and silently move to product, design, UX, and quality debt.

It’s appeared as questions like:

• What is the intended user journey here?
  
• Why does this workflow behave differently from the one next to it?
  
• What should happen in an error state?
  
• Which customer problem is this feature actually solving?
  
• What does “done” mean?
  
• How should QA know what to test when the expected behaviour was never defined?
  

This QA question is where the problem becomes impossible to ignore or delay changing the process any more.

QA can’t begin normal test cycles when there are no real requirements or a established foundation to test against. They can find technical issues, but they cannot validate whether the product experience is correct if nobody defined what “correct” means.

That’s a product maturity problem, not a QA failure.

Why speed makes foundations more important, not less

Before AI, the cost and effort of building often forced teams to slow down and make choices earlier. Not always well, and things were still missed, but decisions and up front checks were necessary.

Now, it’s so much easier to create a screen, workflow, or feature, it is tempting to just keep building, and worry about review and that boring foundational work later.

I often leave the cleaning up or working out schedules to ‘future Fiona’. The problem is always when that future lands I’m stuck with a much larger and more complex mess.

The system build “later” means, every missing decision becomes more expensive and complex. Every inconsistent flow impacts another one. Every visual discrepancy risks shifts from a single digit to multi digit patterns. Every ticket built without sufficient product direction becomes something that has to be revisited, understood, and productised.

This is not an argument against moving quickly. It is an argument for being intentional about what speed gets you vs the trade off you are making.

AI should help us learn faster, not just create more output.

Productisation is not a development pause

I’ve now made a deliberate strategic change: rather than continuing to build everything as quickly as possible, we need to go back and work through what already exists and define the foundation.

That means reviewing every surface, flow, feature, and ticket. Product and design need to provide direction. Engineering needs to iterate, sometimes causing rework. QA needs a clear, testable foundation. Together, we need to turn a technical MVP into a coherent MLP foundation.

This can often be perceived as a pause or a blocker from the outside because net-new feature development stops. It isn’t. It’s the important work needed to ensure the platform is not only modern under the hood, but smooth, intuitive, and enjoyable for the people using it.

Only after that foundation exists should we move into the future operating model: smaller pieces of new capability shaped by product and design, built quickly with AI assistance, reviewed in real time, and validated by QA before release.

The trap to avoid

The trap is thinking that AI-generated specifications, AI-assisted development, and a handover to product, design, or QA is still a normal delivery process. It’s not. If AI is helping development create the requirements, build the product, and then hand it over for review, we are simply accelerating the gap between what was built and what’s actually needed.

The outcomes I’ve seen are:

1. Assumptions become requirements.
2. Development moves fast.
3. Product, design, and QA can’t keep up and see the work later.
4. Journey gaps, inconsistent UX, edge cases, and quality issues emerge.
5. Rework grows.

That’s not a reason to stop using AI. It is a reason to put the right human collaboration around it. Create a human harness around your AI development process.

What I’m learning

The most valuable role for AI is not replacing people. It is making each of the disciplines involved in software development more effective and lean in on their expertise.

AI helps engineers explore options and build faster. It helps product teams synthesise information. It help designers investigate patterns and variations and build working prototypes. It helps QA generate test ideas and identify risks.

But it cannot decide whether a customer journey makes sense. It cannot determine what should feel intuitive. It cannot resolve trade-offs between simplicity, flexibility, trust, and usability. And it cannot create a shared understanding across a team unless the team actively builds one.

That work is still ours, and we are still the best at it.

The lesson I am taking from this modernisation project is ‘the faster we can build, the more deliberate we need to be about our foundation’.

AI speed can get us to a technical MVP. It cannot, however get us to a product people are happy with or enjoy using.