It was fast in the demo. Then the data grew.

At launch the app flew; six months later every screen crawls. It is almost never a server problem, it is code that talks to the database the wrong way. What a senior squad checks before you throw money at bigger infrastructure.

There is a sentence I hear almost every week, always in the same surprised tone: "at launch the app flew, now it hangs." The last time, it came from a niche e-commerce shop, a team of about 40, that came to Revin for a second opinion on a product another vendor had built. The orders screen, which used to open in a blink when the site went live, was taking 14 seconds to load. Nobody had touched the code in months. The only thing that changed was the size of the database.

The easy read is to blame the infrastructure. "We need a bigger server," "Postgres can't keep up." It almost never is. Most times Revin pops the hood on an app like this, the server is bored, sitting at 12% CPU, waiting on code that talks to the database the wrong way.

And the nasty part is that this defect is invisible exactly when you would most want to catch it: on delivery day, with test data, everything runs beautifully.

A chart on a laptop screen: queries that were flat at launch turn into spikes as the data grows.

Why the demo never shows this

In the demo, the database has 200 rows. Maybe 500. With 500 rows, everything is fast. You can write the laziest query in the world, without a single index, and the database scans the whole table in under a millisecond and nobody notices.

The classic case is what the Revin engineers call the N+1 problem. A screen lists 50 orders and, for each order, the code fires a fresh query to fetch the customer. Then another for the line items. Your 50 orders become 101 round trips to the database, sometimes 150. With the test seed it happens too fast to notice. In production, with a full table and the network in the middle, every round trip costs you. Multiply.

The ORM helps hide the crime. An innocent line that reads like "grab this order's customer" is, in reality, a database query fired inside a loop. The dev who wrote it never sees the query. The founder who approved the demo, even less so.

The bill that grows with your success

Here is the cruel part. While the product has not taken off, nobody feels a thing. The database is small, the bad queries slip by unnoticed, and the vendor hands everything over "on time, working." The bill for the bad design only arrives once the product starts to succeed.

At that e-commerce shop I mentioned, the orders screen was firing more than 1,200 queries to render a single page. With 300 orders early on, nobody complained. Once the catalog grew and they crossed 38,000 orders, that same screen turned into the 14-second nightmare and support started hearing "the site is down" all day long. An honest caveat about that number: the people who call me are already having their worst day, so my sample is biased toward disaster. Even so, the pattern repeats so often it reads like a script.

In other words: the real test of your software is not the launch. It is month six, when it succeeded enough to get slow.

A data-center aisle: most of the time the problem is not here, it is in how the code asks for the data.

If your busiest screen started dragging as the data grew, it is worth a technical diagnosis before you buy a bigger server. A Revin Diagnostic Sprint is a good place to start.

What a senior squad checks before you even complain

I asked the engineers at Revin what they look for in these cases, and the answer was almost disappointing in how basic it is. No magic. Just the discipline most teams skip because it takes effort and never shows up in a demo.

• Run EXPLAIN ANALYZE on the queries behind your busiest screens. It is the command that shows, with no guesswork, whether the database is scanning the whole table or using an index.
• Turn on query logging in development to hunt for N+1. If a screen fires 80 queries to render one list, something is wrong right there.
• Add an index where the lookup hurts, and only where it hurts. Too many indexes also cost you on writes and storage.
• Test with production-scale volume, not the 200-row seed. Fill the database with a million fake records and see what breaks before your customer does.
• Set a budget: no critical screen goes over X queries or Y milliseconds. And measure it every release, not once.

None of this is rocket science. But notice that all of it costs effort today to head off a problem that only shows up six months from now, long after the cheap vendor cashed the check and vanished. That is why, at Revin, database performance goes into the definition of done from the first sprint. A senior embedded squad pays that bill while it is still cheap.

Want to see how this looks in a real project? Some of our cases show the before and after of exactly this kind of bottleneck.

The index that was worth 9 seconds

Back to the e-commerce shop. The most impactful fix Revin made in the first week was almost embarrassingly simple: a missing index on a date column. A query that took 9 seconds started answering in 40 milliseconds. There was no rewrite and no new server. There was someone reading the EXPLAIN nobody had bothered to read.

To be fair to the other side: if you have a three-screen MVP still hunting for its first ten customers, tuning indexes now is a waste. At that stage your challenge is finding someone who will pay; scaling a database is a problem for much later. Hire someone fast, ship it ugly, keep moving. The index becomes urgent the day the product starts working, and that is exactly the day the cheap vendor never planned for.

If your system is already past that stage and has started to drag, do not swap servers in the dark. Book a call with Revin and we will look at what the database is trying to tell you.