MVP first: avoiding AI over-engineering

Consider the case of a startup founder who recently audited his initial product launch. His team had spent about five months and something north of €80k utilizing Lovable, Claude code and similar AI tools to build "the platform"—complete with two dashboards, three user roles, a billing module, and a polished notifications center. Despite the highly sophisticated build, the product launched to zero paying customers. When the founder later reviewed the analytics to see how many people had actually used the system, the reality was stark: only two of his co-founders had ever properly logged in.

That story is not unusual any more. AI coding tools are so good at generating features that the natural budget signal — "we can't afford to build that yet" — has quietly disappeared. And when the friction disappears, so does the discipline.

Why this keeps happening

Before AI, scope was self-limiting. A settings screen was a real week of work, so you asked whether you needed it. Now it's a good prompt and a coffee, so you don't ask. The thing is, every screen you add is still a decision the user has to make, and those decisions add up into a product that feels bloated to everyone except the team that built it.

The other thing we notice — and I've caught myself doing this too — is that polishing a demo feels productive in a way that showing it to a stranger doesn't. Nobody argues with a Figma. A customer will absolutely tell you your onboarding is confusing.

What we actually do on new projects

We're not evangelists about any particular methodology. But we've settled into a rhythm that works for early-stage products:

The first two weeks are discovery, and honestly most of that time is spent cutting things. We write down the smallest workflow that could plausibly be useful to one specific person, and we delete everything else from the scope doc. Not "postpone" — delete. You can always add it back later; you almost never will.

Then we build for roughly four to six weeks. AI tooling with a senior engineer keeping an eye on the output. One end-to-end journey. No admin panels, no role hierarchies beyond "the user" and "us", no configurable anything. It'll feel underbuilt. That's the point.

And then — this is the part that gets skipped most often — we sit next to five or ten real users while they try it. Not a survey, not an interview. Watching. What they do is almost never what you thought they'd do, and the roadmap you write on the plane home looks nothing like the one you started with.

A recent case: Orenita

Orenita is a Dutch platform for equipment vendors who run demo loans and rentals. Historically that workflow — request, approval, contract, delivery, return, condition report, invoicing — lived across spreadsheets, email threads and paper. Very solvable problem, and very tempting to over-solve.

We could have designed the complete thing on day one. Multi-warehouse inventory. Shipping integrations. A parts catalog. ERP sync. A customer portal. An installer app. The founders had opinions on all of it. Instead the first release covered one loan flow, for one type of equipment, for one pilot customer. It shipped in about eight weeks.

Watching that customer use it produced a very different roadmap than the one we would have written up front. The condition-report photos turned out to matter more than the calendar view we'd spent two days on. The customer's own field technicians wanted the app on their phones more than the sales team did. ERP sync — the thing we'd almost built anyway — could wait another quarter. Every one of those adjustments would have been an expensive rebuild if we'd committed to it in advance.

The current product is at orenita.com. Every module now on the site earned its place by being used, not by being imagined.

If you're about to start something

A few things to try. Write down the single journey your product needs to complete, in one sentence, and don't let yourself add "and". Cap the first release at six to eight weeks — if a feature won't fit, it's a hypothesis, not a requirement. Ship it to a small named pilot group, not "the market". Only build the second wave of features after a real user has asked for them twice.

AI has made the MVP the cheapest it has ever been to build. Which means the expensive mistake now isn't shipping too little — it's pretending you already know the product.