Project rescue
A stalled build.
A clear way forward.
Your software is live and something is wrong. We read the code and the running system, tell you what state it is really in, then fix the problems that put the business at risk.
For owners with a live build that needs an honest assessment and a practical fix.
What you get
Find the risk. Make a plan. Keep the system live.
The rescue starts with a read-only audit. Once the facts are clear, the stabilization work gets its own fixed price and order.
A straight read of the build
We review the code, the deployed environment, security boundaries, and the release path without changing anything.
A ranked exposure list
Everything that can hurt the business, in order, with the cost of leaving each item open.
A fixed-price stabilization plan
The audit is $4,000 flat and comes off the price of the fix work. You decide what is in and what waits.
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.
01 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.
02 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.
03 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.
04 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.
05 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.
06 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.
How we approach it
Read first. Stabilize second. Hand over cleanly.
The plan keeps the product available for customers while the important gaps close underneath it.
Our working processA 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.
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.
Do you have to rewrite it?
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.
My developer built this. Am I about to find out I was ripped off?
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.
It was mostly built with AI tools. Does that change your approach?
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.
Can you work on it without taking it offline?
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.
What do you need from me to start?
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.
What if I do not have the previous developer's cooperation?
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.
How long does the audit take?
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.