App audit and rescue · Assessment
What to fix first in an app that now has real users
An app built fast with Lovable, Bolt or Cursor, or by a team that has left, gets a two-week written assessment: what to fix first and what to keep.
FormatWritten assessment
Timeline2 weeks
PricingFixed-price assessment · hourly work
Proof3 case studies
The assessment in 4 parts
01 · Signs you need it
If two of these apply, this is a good fit.
- Built in Lovable, Bolt or Cursor, or by a team that has left
- It worked until real users arrived
- Nobody on the team reads the code that goes to production
- Every change breaks something else, and data access has never been checked
- Supabase holds the data, and the tool that wrote the app also wrote its RLS policies
02 · What you get
In two weeks you get a document that covers:
- The urgent problems: who can access which data, how users sign in and which secrets ended up in the client. They come first because they are the only ones that can’t wait.
- Which problems are expensive and which are only ugly. The two usually get mixed up, and they are fixed in very different ways.
- A recommendation to rescue or rewrite each part of the app, so you never have to decide for the whole app at once.
- The rules to add before the next feature, so that new code, whether a person or a tool writes it, doesn’t bring the same problems back.
03 · How we decide
STEP 01We start with data access.We check who can see data that belongs to someone else and what stops them. In apps built fast this is the most common gap and the most expensive one, and it produces no error.
STEP 02Next comes the data model.If the model is incoherent, that part gets rewritten. If it is sound, almost everything else can be rescued.
STEP 03Stabilize before rewriting.Users keep the working version while we fix the risky parts. If a rewrite is needed, it comes later, one part at a time.
STEP 04New code meets the same rules.We turn the rules into checks that fail the build. Generated code then goes through the same checks as code a person wrote, and reviewing it takes less time.
04 · If we find nothing
Then the document explains why the app is sound enough to keep building on. It still lists the rules for new code that should go in before the next feature.
Proof
Where we’ve done this before
Case study 04 · MarketplaceZero outagesA US marketplace that went down regularly, running PHP on hosting that couldn’t scale, with SQL injection in production. In the two months we spent stabilizing it, before any code was rewritten, we made its twenty slowest queries 90% faster and closed the security holes. The rebuild took the two years after that.Read the case study →Case study 03 · Platforms~50%On a team that writes code with Claude Code, the pre-commit hook and CI enforce rules such as these: no component over 200 lines, no TypeScript any, and a request and response type on every API call.Read the case study →Case study 15 · Business systemsSoldFor a healthcare and finance meetings platform, the server works out who may open each file by following the links between people, meetings, documents and signatures.Read the case study →
FAQ
Questions about this service
Access to the repository and a description of how people use the app. The two weeks start when we have access to the code, and we work without production data.
Not necessarily. The document recommends rescue or rewrite for each part separately, and if the data model is sound, most of the app can stay.
Yes. We start with whatever the document marks as urgent, and that work is paid by the hour.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.