Traction is the moment your shortcuts come due. The good news: they come due in a predictable order, the fixes have a correct sequence, and most of what the internet tells you to be afraid of you will never need.
The database, always. Prototype queries were written against ten rows and now meet a hundred thousand. Lookups with no index scan entire tables. The N+1 pattern, where rendering a list of 50 things fires 51 separate queries, was invisible at demo scale and now takes four seconds. This is the source of almost every "the app got slow" story, and it is the most fixable thing on this page.
Everything synchronous, second. The prototype sends the welcome email, resizes the upload and calls the third-party API inside the request, while the user waits. At traction, one slow external call stalls the whole endpoint, timeouts cascade, and the app feels broken even though nothing is down.
Everything you cannot see, third and worst. No error tracking, no slow-query log, no uptime check. Users hit bugs you learn about from a churn email two weeks later. The prototype phase forgives this. The traction phase bills for it, with interest, in users you never knew you lost.
1. See reality. Error tracking, slow-query monitoring, an uptime check. An afternoon of setup, and every later decision switches from guessing to reading. This goes first because everything after it depends on knowing what is actually slow, not what feels slow.
2. Fix the queries. Add the missing indexes, kill the N+1 patterns, paginate the unbounded lists. Days of work, and usually the single largest performance win the product will ever get.
3. Move slow work off the request. Email, media processing, external APIs, reports: into background jobs with retries. The user gets an instant response, failures retry quietly, and one slow vendor stops stalling your whole product.
4. Cache what repeats. The same homepage data, the same profile, the same search results, served from Redis instead of recomputed per request. Caching rewards the reads you measured in step one, which is why it does not come first.
5. Protect the edges. Rate limits on anything a stranger can hit, idempotency on anything that moves money, so a retry or an abuser cannot become an outage or a double charge.
6. Architecture, last, maybe never. Read replicas, regions, sharding, event pipelines: real tools for real scale, and a well-indexed Postgres with a cache carries most products past a hundred thousand users before any of them earn a place. Adopting them early is how startups buy big-company problems at startup scale.
The sequence above assumes a structure worth fixing. Whether you have one shows in a simple tell: do fixes stay fixed? In a sound codebase, an index added is a problem gone. In a codebase that grew by prompt, every fix disturbs something else, because there was never an architecture holding the parts apart. That loop does not converge, and working harder inside it buys nothing.
Traction changes the arithmetic in your favor. You now know what the product is, which features earned their place, and where the load actually lands, knowledge no greenfield project has. A rebuild with that knowledge, re-architected for the load you measured rather than the load you imagined, is a week of work for two senior engineers. It is one of the strongest uses of our week, and the follow-up to the question this page answers is what makes an app hard to build in the first place.
Almost always the database. Prototype queries are written against ten rows and meet ten thousand. The classic culprits are missing indexes, so every lookup scans the whole table, and the N+1 pattern, where showing a list of 50 items quietly fires 51 queries. Both are invisible in a demo and crushing under load, and both are usually fixable in days once someone actually looks.
Visibility, before anything. Error tracking and slow-query monitoring take an afternoon to set up and turn guessing into reading. Then fix in this order: indexes and query patterns, then move slow work like email and file processing into background jobs, then cache the reads that repeat, then rate-limit the endpoints strangers can hit. Architecture changes come last, and most products never need them.
Depends where the debt lives. Feature debt, meaning missing indexes, synchronous jobs and absent monitoring, patches fine inside a decent structure. Architecture debt does not: if the codebase grew by prompt with no coherent structure, every patch fights the last one and the honest move is a rebuild around the data you now have. The tell is whether fixes stay fixed.
Later than the internet says. A well-indexed Postgres with a cache in front of it carries most products past a hundred thousand users. Kafka earns its place when you have real event pipelines, sharding when a single database physically cannot hold the write load, microservices when multiple teams step on each other. Adopting them early buys big-company problems at startup scale.
Yes. Overhauls are one of the strongest uses of our week: we take a half-built, slow or messy project with real traction, re-architect what needs it, redesign what shows, and hand back a product set up to scale, on your accounts, all code yours, $5,000. Traction is precisely the moment that work pays for itself.
Related: what makes an app hard to build, the stack for an MVP, and all articles.
A free 20 minute call. We will tell you honestly whether your codebase needs three indexes or a week.
Or see how the week works.