I take most of our first calls, and the ones about rescue work caught me off guard early on. They almost never come from someone whose software flopped. Nobody phones you about a product with no users. They phone you about the one that took off.
The app got built quickly, often with a lot of help from AI tools. It shipped, people signed up, and some of them started paying. And then, right when things were going well, it began falling over. The founder is now in the awkward position of having a business that works and software that doesn't, which is a much more stressful place to be than having neither.
I want to be fair about the AI tooling, because the popular take is that it writes rubbish and everything collapses, and that's not what turns up in these conversations. The tools genuinely get people to a working, launched product with paying customers, and that used to take a team months. What they don't do is make the handful of decisions that only start to matter once a few thousand people are using the thing at once. And nobody makes those decisions, because at the point the code gets written there's no reason to.
Five problems come up again and again. I'll describe each the way it tends to reach me, from the founder's side, and then what our engineers actually find underneath it, because you'll need that second half when you're talking to whoever ends up fixing it.
Why does an app work fine with 100 users and break with 100,000?
Short version: none of what follows is visible when the numbers are small. These aren't bugs in the sense of someone typing the wrong thing. The code does what it was written to do. It just quietly assumed a world where not many people show up at once, and now they have.
1. The list that used to load instantly
A page with a table on it. Customers, orders, appointments, whatever your product is about. It loads instantly while you're building. It loads instantly on launch day. Then a few thousand rows go in and it gets sluggish, and by the time you have a hundred thousand it just sits there spinning until the browser tab gives up.
What's happened is that your database has no shortcut for finding the rows you asked for. Databases keep something called an index, which works like the index at the back of a book: it lets the database jump straight to the right page instead of reading the whole book to find one mention. Without one, the database reads every single row, every time anyone loads that page. On a hundred rows nobody notices. On a hundred thousand, with several people doing it at once, the database is doing an enormous amount of pointless reading.
The related problem is that the page is usually asking for everything at once rather than the first fifty rows. So you add indexes on the columns you search and sort by, and you send back one page of results at a time. It's dull work, normally an afternoon of it, and it's the difference between a screen that keeps working and one that dies on the day you succeed.
2. The customer who got charged twice
This one costs you the customer you just paid to acquire, which is why I put it second rather than last.
Checkout gets slow because the app is under load. Your customer clicks pay, nothing appears to happen, they wait a bit, and then they do what everyone does and hit refresh. That sends a second payment request. Your payment provider has no way of knowing it's the same purchase as the one thirty seconds ago, so it takes the money again. The customer finds out before you do, usually in an email to support, and often in a review.
Payment providers solved this years ago. You attach a unique reference number to each payment when the customer first clicks pay, and if a request turns up carrying a reference the provider has already seen, it sends back the original result rather than charging again. It's the equivalent of a ticket number: same ticket, same transaction, no matter how many times it gets handed over. Stripe and everyone comparable support it. The work is small, but it has to be in place before the traffic arrives, because afterwards it's refunds and apologies.
3. Everything queueing up behind one row
Somewhere in your database there is one record that gets hit far harder than the rest. A stock count, a booking slot, an account balance, a running total. When traffic is light, updates to it arrive one at a time and nothing goes wrong.
When traffic is heavy they arrive together. To keep your data correct, the database only lets one of them change that record at a time and makes the others wait their turn, which is exactly what you want it to do. But if hundreds are waiting, some of them wait too long and give up, and now writes are failing. It tends to happen on your best day, during the promotion or the launch that was going well.
Fixing it means the requests stop competing for the same row at the same instant, usually by putting them in a proper queue so they're handled deliberately one after another, or by rearranging the data so that one row is no longer the chokepoint. Worth knowing: adding more servers does nothing here, and it's the first thing most people try. The queue is inside the database, and it doesn't care how many servers are feeding it.
4. Background jobs that never catch up
Plenty of what your app does happens out of sight. Sending emails, generating reports, syncing with other systems, processing uploads. These get put on a list, and workers get through that list in the background.
Once you're growing, work can arrive faster than the workers get through it. Nothing stops that list from growing, so it does, and the backlog ends up competing with your actual customers for the same database. What the founder notices is that "the app got slow" for no obvious reason. The reason isn't in the app, it's in the pile of work behind it, and that's why it's so hard to find by staring at the app.
You want enough workers to keep up with how fast work is really arriving, and you want the system to push back when it can't cope, by slowing down or refusing new work rather than accepting an infinite pile. An app that says "not right now" stays up. An app that says yes to everything eventually says nothing at all.
5. Bugs that now reach everybody
In the early days a bug hits three people, you fix it that afternoon, and you probably hear about it from someone who found it funny. With a few thousand paying customers, the exact same bug is a support queue, a round of refunds and a bad week, and none of that is because the bug got worse.
What changed is how many people are standing in front of it when it goes off. This is the one that is as much about how you work as about the code: somewhere to test changes that resembles the real thing, automatic checks on the parts that touch money and customer data, and a way to undo a release in a minute when something slips through. You're not trying to get to zero bugs, which isn't a thing. You're trying to make sure customers meet as few of them as possible, and that you can take one back quickly when they do.
Our previous vendor failed halfway through the rebuild. Who can take over a messy codebase?
That sentence, more or less word for word, is how a lot of these conversations start. Sometimes the original team simply hadn't run a system in production before and were out of their depth once it got real. More often they were fine, and they moved on to a bigger client, and now nobody who understands the code answers the phone.
Not many firms want this work. Moravio, Netguru and Andersen are the established generalist rescue shops and they'll competently pick up a stalled build in most industries. We're worth including if your system is compliance-critical, meaning healthcare, legal or fintech, where a botched rescue lands you in front of a regulator rather than just a grumpy user.
Whoever you call, ask them one thing before anything else: have you taken over someone else's broken codebase and got it into production, and which project was it? Building from scratch is the comfortable job and most shops would rather do that. Picking up code you didn't write, working out why the previous team did what they did, and repairing it without breaking the customers who are already using it every day is a genuinely different skill, and plenty of good developers don't enjoy it.
What a rescue looks like when the deadline is real
The clearest example I can give you is a federal DEA compliance platform we took on after the original team went dark. The go-live date could not move, because a regulator had set it.
What we picked up had been described as a finished MVP and could not actually be used. Logging in was broken for any new user thanks to a circular dependency in the authentication code. There were 61 TypeScript errors sitting in the repository. The pages were hundreds of lines long each, with nothing reused between them.
Our team got it into production in 8 weeks, using roughly 120 engineering hours, against a scope the previous team had costed at several hundred. I'm not quoting that number to brag about speed. It's what you get when a small senior team uses AI tooling properly and spends the first week working out where the real risk sits, rather than reading every file in order.
If your system is regulated, the order we work in is written up in the regulated codebase takeover playbook. And if what you're really wondering is why the last stretch of an AI-built product costs more than everything before it, that's the 80/20 problem.
Should we fix what we have, or rebuild it?
Almost always the answer sits in the database design. If the tables make sense and the business logic is right, keeping what you have is cheaper and faster, because the expensive part, which is knowing exactly what the product has to do, is already captured in the code. Indexes, payment safety and job queues can all be added to a system that works.
If the database design itself is wrong, that's a different conversation. Repairing a bad structure underneath live customer data can take longer than rebuilding around a correct one and moving the data across, reusing the logic you've already proved in the market.
Either way, somebody has to read the code before they can tell you. If a firm quotes your rescue on a phone call, they are guessing, and the guess will show up later as a change request.
What it costs
We start with a $2,420 codebase audit, which comes off the price of the build if you go ahead. You get an honest read on what's worth keeping, what has to go, and a fixed scope and price before you spend anything more. Rebuilds run from $17K to $53K depending on what's involved, usually across 4 to 8 weeks, and you own the source code, the documentation and the deployment instructions at the end of it. If we don't think it's worth rescuing we'll tell you that during the audit, and you'll have paid $2,420 to find out, which is cheaper than finding out later.
When you don't need any of this
Plenty of people who read something like this don't need to hire anyone. If your own developers wrote the app, still work with you, and there's no regulator or immovable date in the picture, what you need is a few focused weeks on the list above. Start with the indexes and the payment reference numbers, because they're cheap and they're the ones actively costing you customers.
The time to call someone is when the code isn't yours, the people who wrote it have gone, and customers are already paying for it. That last part is what makes it urgent, because a broken prototype can sit there for a month without costing you anything, and a broken product with paying customers is quietly losing them the whole time you're deciding what to do.
The nice thing about this work, and the reason we ended up doing more of it, is that you can see it land. Support goes quiet, people stop churning, and the founder starts sleeping properly again, which is usually the bit they mention first.
If that's roughly where you are, here's what a software rescue involves and what we do in the first week.
