Why won't my MVP scale?

You built something. It works. Ten people used it and liked it, you showed it to an investor or a first customer, and now more people are arriving and it has started to feel slow, or fragile, or both.

The instinct is to assume the code is bad. Usually it is not. In almost every prototype we have been asked to take over, the code is fine and the database underneath it is the problem.

Here is why that happens, what breaks first, and how to tell whether you need a rebuild or just a repair.

The short answer

A prototype stores data in whatever shape was fastest to build. That is the correct decision when you are trying to find out whether anyone wants the thing. It stops being correct the moment people depend on it.

Nothing about that shape is wrong at ten users. All of it is wrong at a thousand.

What actually breaks, roughly in this order

1. Queries that read the whole table

At fifty rows, asking the database for everything and then filtering it in the app is invisible. At fifty thousand it is a two-second page load. The database has a tool for this, called an index, and a prototype almost never has any, because nothing tells you they are missing until the day they matter.

This is usually the first thing that goes, and it is also the cheapest to fix.

2. One request that becomes two hundred

You load a list of orders. Then, for each order, the app fetches the customer. Twenty orders on screen is twenty-one separate trips to the database instead of one.

It feels fine on your laptop with the database running locally. Over a network, with real latency and real concurrency, it is the difference between a fast page and a timeout.

3. Everyone’s data in one pile

If you are selling to businesses, this is the one that hurts. A prototype typically stores every company’s records in the same tables and keeps them apart by filtering in the app: show me the rows where company equals this one.

That works right up until a query is written without the filter. Then one customer sees another customer’s data, and no amount of apologising undoes it. Proper separation between tenants is a structural decision, not a filter you remember to apply, and retrofitting it later is genuinely expensive.

We run this in production ourselves. mibi is a field-service platform where every company’s data is isolated at the schema level, the tables are indexed for the queries the product actually runs, and adding the next customer is configuration rather than engineering work. That last part is the whole point. If onboarding a new customer needs a developer, you do not have a product yet.

4. No way to change anything safely

By this stage there is usually one environment, which is also the live one, and no tests. So every change is made directly against real customer data, and the only way to find out whether it worked is to watch and see.

This is the point where progress stops. Not because anything is broken, but because nobody dares touch it.

5. Login bolted on afterwards

Authentication tends to arrive early and permissions tend to arrive late, one special case at a time. Six months in, the rules about who can see what live in twenty different places in the code and nobody can say with confidence what an ordinary user can reach.

The question that decides how much work this is

Not “how many users”, but what those users do.

A platform serving a thousand people who read and write text is a very different piece of engineering from one serving a million who upload video. Storage, bandwidth, processing and cost all move differently, and the second one needs decisions the first one never has to make.

So before anyone can sensibly quote you, the honest questions are: how many users, doing what, with what kind of content, and by when. If someone gives you a price without asking those, they are guessing.

Do you actually need a rewrite?

Usually not, and we would rather say so.

Where the foundation is sound, the work is unglamorous and effective: add the missing indexes, fix the queries that read too much, put real separation between customers, get a test environment in place so changes stop being frightening. That is often weeks rather than months, and you keep everything you have built.

A rewrite earns its cost in narrower cases. The platform will not let you export your own code, so there is nothing to build on. Or the data model is wrong in a way that touches everything, and every fix fights it.

Lovable is worth calling out because it comes up constantly. It exports clean React, TypeScript and Supabase, so the code is a real starting point rather than a dead end, and their own documentation suggests validating with it and then building the production version. What the export does not give you is architecture. Bubble is the harder case: it does not let you export at all, so leaving it is a migration rather than a takeover, and that is a different piece of work at a different price.

When to act

Three signals, and one is usually enough:

• Paying customers now depend on it
• You are hitting limits the platform cannot lift
• You cannot hire anyone to work on it

A fourth worth watching: your cost per user is going up as you grow, when it should be going down.

Move before any of those and you are solving a problem you do not have. Move after all four and you are migrating under pressure, with customers watching, which is the most expensive version of this there is.

Where we come in

We take over prototypes and turn them into products, and we start by reviewing what you have built rather than by quoting a rebuild. That means a free 30-minute call, then a fixed-price analysis: we go through the code, the data and the architecture, and you get a written report with the findings, a recommended target architecture and a phased plan.

The report is yours whatever you decide. If the answer is that your foundation is fine and you need four weeks of unglamorous fixes, that is what it will say.