You want a 90-day MVP that isn't a slide: what you can (really) deliver and what you're dreaming

An MVP isn’t the brand and three Figma screens

You’re a founder, you have an idea, and they’ve told you the magic word: MVP. «Let’s do an MVP in 90 days and put it on the market.» The problem is that “MVP” means very different things depending on who says it, and the distance between those versions is the distance between a product that validates your idea and an invoice for slides. Before you sign anything, it’s worth focusing on what actually sits inside a 90-day software MVP — and what, instead, you’re dreaming.

Let’s start from what an MVP isn’t. It isn’t the logo, the brand, the colour palette and three screens drawn in Figma. That’s a mockup: beautiful to show investors, useless to use, because it doesn’t work — it’s a drawing. It isn’t even a clickable prototype where it “looks like” things happen but underneath there’s nothing. An MVP — Minimum Viable Product, a minimum working product — is real software: something a real person uses, on real data, to actually do the thing. The key word is viable, working: if it doesn’t work, it isn’t an MVP, it’s a presentation.

This confusion isn’t innocent: it’s where founders burn time and money. You pay thinking you have a product to test on the market, and you end up with pretty screens that do nothing, and the discovery that “now the real development is needed” — that is, that the bulk still has to start. This article is there to give you honest expectations: what fits in 90 days, what doesn’t, why frontend without backend is a betrayal, and what happens on day 91. So you know what you’re buying, and you recognise whoever sells you a dream from whoever builds you a product.

Mockup, prototype, MVP, product: four different things

A large part of the misunderstandings (and the rip-offs) comes from calling different things by the same name. It’s worth putting order, because knowing what you’re talking about lets you understand what you’re buying and what you’re paying for.

The mockup is a drawing: static screens, pretty, made with a design tool. It serves to decide the look and to show the idea. It doesn’t work: it doesn’t save anything, it doesn’t do anything. It costs relatively little and it’s useful, but if someone sells it to you as “the MVP”, they’re deceiving you.

The prototype is a mockup you can click: you go from one screen to another and it looks like things happen, but underneath there’s no logic or real data. It serves to test the user path and to make an impression in a presentation. It’s still an animated drawing, not software: no real data, no real action.

The MVP is real software, minimum but working: a complete flow that a person uses on real data, with users and logic underneath. It’s the first thing on the list that actually works — and that’s why it costs more than the mockup and the prototype, because under the surface there’s the invisible work (backend, data, logic). It’s the difference between a prototype that looks and a product that is.

The complete product is the MVP grown up: all the flows, the edge cases, the integrations, the scale. It’s months or years of work, and you get there after validating the idea with the MVP, not before.

The expensive confusion is between the prototype (a drawing that looks like it works) and the MVP (software that works). Many founders pay thinking of the MVP and receive a prototype, then discovering that “the real development” still has to start. When you talk budget and timelines, clarify which of these four you’re buying: the word “MVP” alone isn’t enough to protect you.

What fits in 90 days: one flow, real users, real data

Ninety days are few and they’re many: they’re enough for a real MVP, if you know what to put in and what to leave out. The golden rule is: one flow, done well, working, with real users and real data. Not ten things halfway: one thing that actually works.

What does “one flow” mean in practice? It means choosing the heart of your idea — the central action that solves your user’s problem — and building that, complete, from start to finish. If your idea is a marketplace, the flow isn’t “the whole marketplace”: it’s, for example, “a user publishes a thing, another finds it and books it”. If it’s a management tool, the flow is the main sequence the user does every day. Everything else — the thousand accessory functions, the edge cases, the secondary sections — is left out of the 90 days.

And this flow has to be real on two dimensions. Real users: there’s a login, there are roles, people get in and it’s really theirs — not “a fake user for the demo”. Real data: the system works on real (or realistic) data, that comes from somewhere precise, not on a pasted example. An MVP with real users and real data is something you can put in real people’s hands and see if your idea holds. It’s exactly the kind of minimum product I talk about for whoever wants to productise an idea and not stop at the demo: small, but real — a product in miniature, not a demonstration.

What does NOT fit in 90 days

Equally important is knowing what doesn’t fit, because that’s what founders dream and what blows timelines (and budget). If someone promises you these things in 90 days, they either won’t do them, or they’ll do a fake version.

The complete marketplace. “Let’s do Airbnb of sector X” in 90 days doesn’t get done. A mature marketplace is two sides (demand and supply), payments, reviews, search, dispute handling, moderation, notifications… In 90 days one flow of that marketplace fits, to validate the central idea, not the whole platform.

The magic AI. “And then we put AI that does everything.” Serious AI, well integrated on real data with error handling, is a project in itself; throwing it into a 90-day MVP as if it were a free ingredient is the road to a PoC that ends in a drawer. In 90 days AI can do a bounded, verified piece, not “everything magically”.

Ten integrations. “It connects to the ERP, to Stripe, to Salesforce, to WhatsApp, to shipping…” Every serious integration is real work, with its edge cases. In 90 days one, maybe two integrations essential to the flow fit, not an ecosystem.

All the edge cases. The MVP handles the normal case, the one that happens 80% of the time. The odd cases, the rare exceptions, the particular scenarios are faced later, when you’ve validated that the base idea works. Wanting them all immediately is the way to deliver nothing.

In 90 days it fits	In 90 days it does NOT fit
One central flow, complete and working	The complete platform with all functions
Real users (login, roles)	Ten integrations with external systems
Real data from a precise source	“The AI that does everything”
One, maybe two essential integrations	All edge cases and exceptions
The normal case, done well	The mature marketplace/ecosystem

The discipline of cutting — deciding what NOT to do in the 90 days — is the competence that distinguishes whoever delivers a real MVP from whoever makes you dream and then overruns. A good partner tells you “this yes, this no, this later”, not “yes to everything”.

Frontend without backend: the betrayal

There’s a specific way founders get betrayed, and it’s worth naming because it’s frequent: they deliver a frontend without a backend. That is, the screens — pretty, clickable, that look like they work — but underneath there’s no logic, data doesn’t really save, actions don’t make anything real happen. It’s a shell: it looks like a product, it’s an animated drawing.

Why does it happen? Because the frontend is visible and the backend isn’t. A supplier who wants to impress you fast (or who only knows how to do the façade) shows you wonderful screens, you’re happy, and the hard, invisible part — the backend, the data, the logic — stays behind or isn’t there. Then you try to use it for real, you discover that “it doesn’t save”, that “that button does nothing”, that data disappears, and they tell you “yeah, that’s the next step”. You paid for a product and you have a clickable demo.

It’s the same betrayal as the showcase site sold as a product: the façade is there, the state isn’t. For an MVP the rule is sharp: it has to actually work, not look like it works. Fewer screens but real, that save, that hold state, that make things happen — not lots of pretty empty screens. When you evaluate an MVP in progress, the question is: “can I actually use it, does the data stay, do actions have an effect?”. If the answer is “almost”, you’re looking at a frontend without a backend.

Data: if you don’t know the source, there is no MVP

A point founders always underestimate: the data. An MVP works on data, and the first serious question isn’t “which screens”, it’s “where does the data come from and what state is it in”. If your idea needs data (and almost all of them do) and you don’t know where it comes from, you don’t yet have an MVP: you have an idea with a hole in the centre.

Let’s take examples. Your product compares prices? Where do you get the prices, and are they reliable, up to date, obtainable? It aggregates information? From which sources, and do you have the right to use them? It works on the client’s data? In what format is it, how dirty is it, who gives it to you? The data source is often the real bottleneck of an MVP, much more than the screens: you can have the prettiest interface in the world, but if the data it has to show isn’t there or is a swamp, nothing works.

That’s why a serious partner, before talking about screens, asks you about the data: where it lives, what state it’s in, who owns it, how you get it. If whoever proposes the MVP skips this question and starts from the design, it’s a warning signal — they’re building the façade before knowing if the foundations are there. It’s the same principle that holds for every serious data product: under every interface there’s a data layer, and if that doesn’t hold, the interface is theatre. If you don’t know the data source, there is no MVP: there’s an unaddressed risk.

How you work, week by week

A good MVP project isn’t a black box you throw money into and after 90 days something comes out: it’s a visible path, week by week, where you see the product grow and you can correct course. That rhythm is also your protection: if you see something every week, you notice in time if it’s going wrong, instead of discovering it at the end.

Roughly, a healthy weekly rhythm looks like this. The first weeks aren’t code: they’re focusing — which exact flow, which users, where the data comes from, what’s in and what’s out. Skipping this phase is cause number one of MVPs that overrun. Then you enter building, and from there every week you should see something concrete grow: first the skeleton of the flow, then the pieces filling in, then the flow working end-to-end on real data. Towards the end, testing with real users, which brings out the adjustments before launch.

The signal of a healthy project is that every week there’s something to see and try, and an honest conversation about what’s done, what’s missing, what has to be cut to stay on time. The signal of a sick project is silence: “we’re working”, for weeks, with nothing to show, until a final delivery that either doesn’t arrive or isn’t what you thought. Demand weekly visibility: it’s normal, it’s healthy, and it’s how you notice in time if you need to correct. For an MVP the same incremental testing discipline holds as for every product that has to be validated with real users.

Budget: ranges, not a magic number

Let’s talk money with honesty. A serious MVP has a cost, and whoever gives you a precise magic number without having understood your flow and your data is either guessing or hooking you with a price that will then grow. The honest way to talk budget is in ranges, tied to what determines the cost.

What makes an MVP budget vary? The complexity of the flow (how many steps, how much logic), the state of the data (a clean, accessible source costs little to integrate, a swamp costs a lot), the number of essential integrations, and how defined the idea is (a clear idea is built straight, a confused idea wastes time in rethinks). An MVP focused on one flow, with accessible data and a couple of integrations, sits in one range; the same “MVP” but with data to clean and five integrations sits in another, higher one.

The important thing, as a founder, is to reason on the budget relative to what you need: the MVP serves to validate the idea spending as little as possible to discover if it works, not to build the whole company. If the budget they propose is that of a complete product, they’re selling you too much; if it’s suspiciously low, it’s probably a frontend without a backend or a mockup. The right range is the one that buys you one real, working, testable flow — enough to know if it’s worth continuing. On how to evaluate what you’re buying when you commission a build, and how not to get hooked by a magic number, everything I say in the guide to buying custom software holds.

What happens on day 91

Here’s the question few ask and which is instead crucial: what happens the day after delivery? Because an MVP isn’t the end, it’s the beginning. On day 91 you have a minimum working product in your hands, and the real part starts: putting it in front of users, learning, deciding whether and how to continue.

There are, essentially, three possible outcomes on day 91, and a good MVP makes them all manageable. It works and you grow: users use it, the idea holds, and then you build the next flow, then the next — the product expands in layers, on the basis of what you’ve learned. It works but needs correcting: users tell you things you hadn’t predicted, and then you adjust the flow before expanding — and that’s gold, because you discovered it with a cheap MVP and not with an expensive complete product. It doesn’t work: the idea, put to the test with real users, doesn’t hold as you thought — and this too is a success of the MVP, because you discovered it spending 90 days instead of two years and the whole budget.

For all three outcomes to be manageable, though, on day 91 two things have to be true: that the code and the data are yours (you can continue with whoever you want, you aren’t hostage), and that there’s an agreement on how you proceed (who maintains, who develops the next piece, at what rhythm). An MVP delivered without thinking about day 91 — code that isn’t yours, no plan for afterwards — is a dead end even when it works. Day 91 has to be designed together with day 1.

A typical case: from the dream to a flow that runs

A typical profile, architectural, no names. A founder arrives with an ambitious idea — a platform with many functions, two types of user, payments, AI, integrations — and wants it “in 90 days to go to market”. They already had beautiful mockups made by a designer: careful screens that looked like a finished product. The misunderstanding was right there: they thought they were halfway, and they were at the start, because under those screens there was nothing.

What was done. First the uncomfortable but necessary conversation: what fits in 90 days and what doesn’t. The central flow was isolated — the action that solved the user’s real problem — and it was decided to build only that, complete and working, postponing everything else. The data question was faced immediately (where it came from, what state it was in), which was the real hidden risk. And work was done at a visible weekly rhythm: every week the founder saw something grow and could have their say.

On day 90 there wasn’t the dream platform: there was a real flow, with real users and real data, that the founder could put in front of the first real users. And there the value of the MVP happened: users used the thing, and they revealed that one part of the idea worked and another had to be rethought — a discovery that, without an MVP, would have cost two years and the whole budget. On day 91 the founder had their code, their data, and an informed decision on how to proceed. The honest note: the product delivered was much smaller than the initial dream, and that’s exactly what made it useful — a real flow beats ten fake flows.

It’s for you if / it isn’t for you if

It’s for you if: you’re a founder with an idea and you want to validate it with a real product, not with slides; you understand that an MVP is a working flow with real users and data, not the whole platform; you’re willing to cut (to decide what NOT to do in the 90 days); you want weekly visibility and your own code, to manage any outcome on day 91.

It isn’t for you if: you want “the whole platform” in 90 days and you aren’t willing to cut (then you either overrun, or they give you a fake version); you’re looking for pretty screens for investors more than a working product (then you need a mockup, not an MVP, and it costs and is worth something else); you don’t know where the data comes from and you don’t want to face it (without the data source, there is no MVP); you think on day 91 “we’ll see” — because without a plan for afterwards, even a successful MVP is a dead end.

Frequently asked questions

What is an MVP, really? A minimum working product: a central flow, complete, that a real person uses on real data, with login and roles. It isn’t the brand and three Figma screens (that’s a mockup), it isn’t a clickable prototype that looks like it works. The key word is “viable”, working: if it doesn’t actually work, it’s a presentation, not an MVP.

What fits in 90 days? One flow, done well, with real users and real data, and one or two essential integrations. Not the whole platform, not ten integrations, not “the AI that does everything”, not all the edge cases. The discipline of cutting — deciding what to leave out — is what distinguishes whoever delivers a real MVP from whoever makes you dream and then overruns.

Why can’t I have the whole platform immediately? Because a complete platform is months or years of work, and building it all before validating the idea is the way to spend a lot to discover late if it works. The MVP is there precisely to validate spending little: a real flow in front of real users tells you if it’s worth continuing, before you build the rest.

How do I recognise a frontend without a backend? Try to actually use it: does data save? do actions make something real happen? coming back tomorrow, do you find what you did? If “almost”, if “that button is the next step”, if data disappears, you have a shell: pretty screens without the logic underneath. An MVP has to actually work, not look like it works.

Why do you ask so much about the data? Because the data source is often the real bottleneck of an MVP, more than the screens. If the product needs data and you don’t know where it comes from, what state it’s in, who gives it to you, you have a hole in the centre. A serious partner faces the data before the design: building the façade without knowing if the foundations are there is an unaddressed risk.

What does an MVP cost? It depends on the complexity of the flow, the state of the data, the number of integrations and how defined the idea is: you talk in ranges, not with a magic number. A precise number given without having understood your case is a hook. The right range is the one that buys you a real, working, testable flow — enough to know whether to continue.

How do I check that it’s going well? By demanding weekly visibility: every week something to see and try, and an honest conversation about done/missing/to cut. Silence (“we’re working” for weeks, with nothing to show) is the warning signal. Visibility is how you notice in time if you need to correct course, instead of discovering it at delivery.

What happens after the 90 days? You put the MVP in front of users and you learn: it works and you grow, it works but needs correcting, or it doesn’t work (and you discovered it in 90 days instead of two years). For all outcomes to be manageable, on day 91 the code and the data have to be yours and there has to be an agreement on how you proceed. Day 91 has to be designed together with day 1.

In one line

A 90-day MVP is possible, but it isn’t the brand and three Figma screens: it’s a central flow, actually working, with real users and real data. One flow done well fits; the complete platform, ten integrations, magic AI and all the edge cases don’t — and the discipline of cutting is the competence that counts. Distrust the frontend without a backend (pretty empty screens) and face the data source immediately (without it, there is no MVP). Demand weekly visibility, budget in ranges and your own code, so day 91 — whatever the outcome — is manageable.

If you’re a founder and you want a real MVP, not slides, look at the projects I’ve built or drop me a line: we start from the flow that counts and from the source of your data, and I’ll tell you honestly what fits in 90 days and what you’re dreaming.