Software project rescue
Your app is live and something is wrong with it
Maybe the developer stopped replying. Maybe every new feature breaks two old ones. Or maybe you cannot tell whether the code you paid for is any good. We read the whole thing, tell you what state it is actually in, and then fix the parts that put you at risk.
Symptoms
What this usually sounds like
Founders describe this in more or less the same handful of sentences. If one of them is yours, you are in a more common situation than it feels like from the inside.
I cannot tell if my developer is doing a good job.
Every update sounds reasonable and the demo works. You have no way to check whether what sits underneath is solid or held together with tape, and asking harder questions has not produced clearer answers.
Every file looks fine but the system does not hold together.
Read any single piece and it seems okay. Put the pieces together and there is no shape to it. There are strange abstractions in places that never needed them, and basic things left out where they actually mattered.
The developer is gone and I have the repo.
You have access and no idea what you are looking at. The README does not match reality, and there is nobody left to ask.
It works fine when I use it.
You click through it and everything behaves. That is the part that should worry you. You are the friendly user, asking only for your own data, at a normal pace, through the screens it was built for.
I have already promised investors a date.
Most of the money is spent and the date is in a deck. You need to know today what is shippable and what is not, without another month of finding out.
It is in production and I cannot take it down.
Real customers are using it right now. Whatever gets fixed has to get fixed while the thing stays up and keeps working for them.
The work
What a software project rescue actually is
Messy code is not the emergency. Plenty of software earns money every day with code no engineer would put in a portfolio. Structure you would not have chosen costs you slowly, a month at a time.
A missing guard is the actual emergency. That means a record any logged-in person can read, a secret key sitting in the browser, a payment message nobody verifies, or an expensive action nobody counts. Any one of those is a bad afternoon away from becoming your whole quarter.
A rescue is two things, in this order. Find out what is actually true about the software. Then close the gaps that can hurt you, worst first.
We do not open with a rewrite. A rewrite costs the most and takes the longest to show you anything working, which is the wrong shape of answer when paying customers are on the current version. Keeping the business running comes first, so we make real fixes on the live system instead of a parallel build you have to wait for.
Self-check
Six things you can check before you talk to anyone
The tool wrote the feature and never wrote the guard around the feature. That is the pattern in nearly every quickly assembled build, whether a person typed it or a model did. None of this means the product is bad or that you did something wrong. It means nobody was ever asked to check.
It also explains why the exposure is invisible from the inside. The app behaves perfectly when you are the one using it, because you only ask it for your own data, at a human pace, through the screens it was designed for. The gap only shows when somebody asks it something it was never asked before.
Change the number in the address bar
Open one of your own records. The address probably ends in a number or an id. Change it to a different one and reload. If another customer's record appears, the backend is trusting the id in the address instead of checking who is asking. This is called IDOR, and it means anyone with an account can read anyone else's data. You can check it yourself in about a minute.
Row Level Security switched off, or a policy of USING (true)
On Supabase or Firebase, each table is either locked down or open, and the lock often gets switched off during development and never switched back. A policy of USING (true) is the same as off. The public key that lets your frontend talk to the database ships inside the app your users download, so anyone can read it out. Off means every row in those tables is readable by anyone holding that key, and in some setups writable too.
Reading is locked down but writing is not
This one hides well, because the obvious test passes. You try to read a record you do not own and you cannot. But updates and deletes were never restricted, so somebody who guesses an id can overwrite or destroy the row they were never allowed to read.
A service key or API token in the frontend
Some keys are meant to be public. Service keys and API tokens are not. If one got pasted into the frontend to make a feature work, it is sitting in the JavaScript every visitor downloads, and it is still sitting in every version you shipped before this one.
Expensive actions that can be repeated without limit
This covers password reset emails, file uploads, signups, and anything that calls a paid service. If a request can be repeated as fast as a script can send it, eventually someone sends it that fast, and you find out from the invoice.
Webhooks accepted without checking the signature
Your app very likely accepts messages from a payment provider or a mail service. Those messages carry a webhook signature that proves they came from who they claim. If nothing verifies the signature, anyone who learns the address can send a message of their own. The common one is a message saying a payment succeeded when no payment happened.
Finding one of these says nothing about you or about the person who built it. A missing guard is a bounded, fixable piece of work, and knowing about it is the whole difference between a scheduled fix and a bad surprise.
How the audit worksEngagement
How a rescue runs
A read-only pass first
We start with repo access, the deployed environment, and whatever documentation exists. Nothing changes during this phase. Working out what is true is impossible while you are also moving things around.
A written report you can hand to anyone
The report leads with plain language and keeps the technical detail behind it. Every finding is ranked by what leaving it open can cost you and what closing it takes. It is written so you can forward it to an investor, a new engineer, or the developer who built it.
A fixed price and an order of work
You see the full list with a price attached before anybody touches anything. You decide what is in and what waits.
Stabilization on the live system
Guards go in first, because those are the findings with a bad day attached to them. After that come the changes that make the next six months of building cost less. Your customers keep being served the whole time.
Handover written for a stranger
You get the source code, the access, and notes aimed at whoever maintains this next, including you or a developer you have not hired yet.
Pricing
What it costs
The audit is $4,000, flat. The price is the same whatever we find in there. If you go ahead with the fix work afterwards, that $4,000 comes off the price of it, so the audit costs you nothing if you continue.
Stabilization gets a fixed price once the audit is done. We will not put a number on code we have not read, because a quote given sight unseen is a guess. Our engagements are fixed price between $15,000 and $60,000 depending on how much is open and how much of it you want closed now. You get that number in writing with the list of what it covers, and then you decide.
If the audit finds the software is in better shape than you feared, the report says so and there is nothing further for you to buy. That outcome is a good use of $4,000.
Deliverables
What you end up holding
The written report
A plain language summary comes first, with the detail underneath it. You can read it, and an engineer can work from it.
The ranked exposure list
Everything that can actually hurt you, in order, with the cost of leaving each one open.
A straight answer on the developer question
We tell you whether the work you paid for is sound, without softening it and without making it sound worse than it is.
A fixed price to close the gaps
The number is scoped from code we have read rather than from a conversation about it.
Guards in place on the running system
The gaps close while your customers keep using the product, and any change that requires a window gets scheduled around you.
Notes for whoever comes next
The notes are written for someone who has never seen this code, because eventually somebody will not have.
FAQ
Questions founders ask us first
Almost never. A rewrite is the most expensive option on the table and the slowest to show you anything working. When there are paying customers on the current version, the right move is nearly always to fix that version. If a rewrite does turn out to cost you less we will tell you, but that is an unusual finding rather than our default recommendation.
Probably not, and that is not the question we set out to answer. Gaps like these are usually missing scope rather than bad faith. Nobody asked for the guard, so nobody built the guard. We report what is there and leave the conclusions about people to you.
No. Quickly assembled code tends to have the same shape of gap regardless of who or what typed it, because the part that gets skipped is the part nobody thought to ask for. We look for the same list either way, and the code being AI-assisted is not something we hold against it.
Yes, and that is the normal case. Most of the early work is additive, guards and checks that go in without changing how the product behaves for anyone using it. If something does need a window, we agree the timing with you first.
We need repo access, access to the deployed environment, and a short description of what the product does and who uses it. Send any documentation you have. If there is none, that is the common case and it does not slow us down much.
That is a normal starting position and it does not block the work. We read the code and the running system. If they are willing to answer a few questions it shortens the audit, and if they are not, we manage without.
One to two weeks, depending on the size of the codebase. The stabilization timeline comes attached to the fixed price, so you see both before you commit.
Get an honest read on what you own.
Thirty minutes. Bring what you know and what you are worried about. If a rescue is not what you need, we will tell you that instead of selling you one.
Book a free 30-minute callThe audit is $4,000 flat and comes off the price of the fix work. Projects start there.
Prefer email? [email protected]