You had an idea, an assistant that writes code, and a reason to move fast. It worked. There is a product, there are users, and some of them are paying. That is further than most people get, and it is worth saying out loud before the rest of this page.
Here is what happened next. Changes started taking longer than they used to. A fix in one place broke something unrelated. Someone found a bug that had been live for weeks. And when you asked how a particular part works, the honest answer was that nobody knows, because nobody wrote it — it was generated, it passed a quick test, and it went out.
This is a specific condition with specific fixes. It is not a verdict on the decision to build it this way.
Why this code fails differently
Old systems and AI-assisted ones arrive at the same place from opposite directions, and the difference matters for what you do about it.
It was never read. In a hand-written system, somebody at some point held the whole thing in their head. That person may be gone, but the shape of their thinking is in the code and can be recovered. In a generated system there may never have been such a person. Each piece was correct in isolation, reviewed for about as long as it took to see it work, and then accepted.
The same problem is solved four ways. Ask for the same thing on four different days and you get four reasonable implementations. None of them is wrong. But now there are four places that check whether a user is allowed to do something, three of them agree, and the fourth is the one on your busiest screen.
It is confident about things that are not true. Generated code is fluent. It reads like code somebody thought about, which is exactly what makes the gaps hard to spot. A permission check that looks right and checks the wrong field is much harder to notice than a permission check that is missing.
The debt arrived early. A ten-year-old system accumulated its shortcuts over ten years, which gave everyone time to learn where they are. Yours accumulated them in four months. The volume is comparable; the institutional memory is not.
What we find, almost every time
Not a prediction about your system. This is the recurring list.
Permission checks in the screen, not in the request. The button is hidden from users who should not see it, and the request behind the button is not checked at all. Anyone who can open a browser’s network tab can call it directly. This is the single most common serious finding, and it usually means one customer can read another’s records.
Credentials in the code. API keys, database passwords, payment provider secrets, sitting in files that are in your repository, in its history, and in every copy anyone has ever made. Moving them out takes about a day. Reissuing them so the old ones stop working takes longer and is the part people skip.
The same question asked hundreds of times. A screen that lists fifty items asks the database about each one separately. Fifty small delays become one long one. This is a well-known pattern with a well-known fix, and it is usually a day or two per screen.
No tests, or tests that assert nothing. Often there is a test folder. Often the tests confirm that a function returns something, not that it returns the right thing. That is worse than no tests, because it produces a green result that nobody trusts and nobody deletes.
Nothing recorded and nothing watching. When a payment fails or a message to another service is lost, there is no record of the attempt. The failure is discovered by a customer, days later, and cannot be reconstructed.
No way back. No backup that anyone has restored, no copy of the system where a change can be tried first. This is why changes feel dangerous — they are.
What we do, in order
The order matters more than the list. Each step makes the next one cheaper.
Read it and rank it. Five business days. You get a written report in plain language: what is there, what is dangerous, what each fix costs, sorted by what it is costing you now rather than by how interesting it is. You own the document and can hand it to any developer, including one who is not us.
Close the ways in. Permission checks moved to where the request is handled. Credentials out of the code and into a store, then reissued. This is done first because it is the finding that turns into a phone call from a customer.
Make it safe to change. Backups that have actually been restored, alarms that reach somebody before a customer does, and a copy of the system where changes can be tried without users seeing them. Then tests — not everywhere, which is a waste, but around the paths that take money and touch personal data.
Then the cleanup. Four implementations of the same rule become one. The slow screens get fixed. This is the part that looks like the whole job from the outside and is actually the last quarter of it.
What this costs
Reading the system properly is $2,400 and five business days, and the fee comes off later work if you go ahead. Making a system safe to touch runs from $6,000 and takes two to three weeks. Anything after that is quoted from the audit as one fixed number. The full price list is here, including the parts that are free.
What we will not do
We do not take over your product backlog and we do not build your features. You or your team keep building the product; we make it a thing that can be built on. That distinction is the whole point — a system nobody can change safely is not a slow system, it is a stopped one, and getting it moving again is a different job from driving it.
If the honest answer after reading it is that the system should be replaced rather than repaired, you get that in writing, with the reasoning. That is cheaper to learn now than a year from now.