Repair and stabilize your application
Your app is failing, slowing down or becoming harder to change. We start with a focused assessment at a fixed price and a written list of findings. You decide which repairs to make, with their scope, price and checks agreed before we change the application.
Problems we look for
Most of these stay hidden while an app has a few test users. They show up with real customers, real data and the next round of features.
Anyone can read the database
Database access rules are off or too broad, so a visitor can read or change other people's records. On Supabase these rules are called Row Level Security, and they are among the first things we test.
Secret keys sit in the browser
Keys for payments, email or other paid services are shipped in the front-end code, where anyone can copy them and run up your bill.
Login only looks secure
Permission checks run in the browser and not on the server, admin pages open for anyone who knows the address, and one user can see another's data by changing a number in the URL.
It works in testing and breaks when deployed
The live host is missing environment variables or build settings that the test setup had, and login redirects or payment webhooks still point at the test address.
Test changes reach real data
Development and production share one database, so a test can change customer records. Backups exist, but nobody has restored one to check that it works.
Pages slow down as the data grows
Queries without indexes, whole tables loaded into the browser, and one request per row. All of it was fine with ten test records.
Every fix breaks something else
There are no tests, so each change repairs one screen and quietly breaks another. Nothing checks the flows that already worked.
Nobody can explain how it fits together
The same thing is done three different ways, data lives in several places, and the next feature feels risky to start.
How a repair works
We look before we promise. Repairs get a fixed price only after the assessment shows what is wrong.
1. You tell us what is going wrong
What the app does, who uses it, what breaks and what worries you. You don't need a technical description or to know how the app was built.
2. We agree the assessment in writing
What we will review, how long it takes, what you will receive, and one fixed price. Its length depends on the size of the app, and you know it before you agree.
3. The assessment
We read the code, the database rules, the hosting setup and where the secrets live, and we try what a curious or hostile user would try. We work from our production-readiness checklist. If we find something urgent, such as a payment key anyone can copy, we tell you straight away instead of waiting for the report.
4. A report you can read
Every problem we found, ranked by risk, with what it means for your users and what it takes to fix. It is written for the person who owns the app, and a developer can work from it too.
5. A repair plan with one price
You choose which repairs to make. We write them down with how each one will be checked, and one fixed price for that list. Anything outside the list is priced before we do it.
6. Repairs in weekly steps
The most serious problems first, each fix shipped to your live app with tests around it, and a demo every week. You pay each week in advance, and either side can stop with one week's notice.
7. A handover
The fixes, their tests and written notes on how the app works, in your repository, plus a runbook for deploying, rolling back and restoring a backup.
What we can and can't promise
An assessment finds what can be found by reading the code, the configuration and the running app in the time agreed. It lowers your risk. It doesn't prove that no other problem exists, and it is not a formal security audit. If your app needs a penetration test or a compliance audit, we say so and work alongside the specialist.
We don't promise a repair date before the assessment. Once we know what is wrong, the repair plan says what each week covers.
After the repairs
Monthly maintenance
Updates, backups that have been restored, monitoring that alerts a person, and someone who answers for the app every month. See software maintenance.
Keep building
Your own team, or whoever builds next, starts from tests and written notes in the repository, so new changes are less likely to undo the fixes.
Larger changes
If the app needs structural work, such as a new data model or a platform upgrade, we plan it in bounded steps. See software modernization.
Who this is for
A good fit
A founder or small business with a web app that has, or will soon have, real users and real data. It doesn't matter who built it: a freelancer, an agency, your own team, or you with an app builder.
Look elsewhere if
The app has no users and no plan for any, or you need it fixed by tomorrow with nobody responsible afterwards. If the people who built it are gone and you need someone to own it long term, see software takeover. Our guide to hiring help for an app that needs repair lists what to ask any provider, including us.
Questions about repairing an app
Can you fix my app without rebuilding it?
Usually, yes. We keep what works and repair what is broken or unsafe. A rebuild only makes sense if the assessment shows that repairing the app would cost more, and we tell you that before you pay for any repair work.
How do I know if my app is leaking data?
Often you can't tell from the outside. Data leaks when database access rules are off or too broad, or when the server trusts whatever the browser sends. The assessment tests the data as an anonymous visitor and as a signed-in user, and the report lists what each of them could read or change.
Why does my app work in testing but break when deployed?
Usually the live host is missing environment variables, build settings or redirect addresses that the test setup had. We compare the two setups and list every difference that matters.
What do I get from the assessment?
A written report of the problems we found, ranked by risk, with what each one means for your users and what it takes to fix. It proposes which repairs to make first. If we find something urgent, we tell you as soon as we find it.
How long will the repairs take?
That depends on what the assessment finds, so we don't promise a date before we have looked. The repair plan says what each week covers, and you see the fixes working on your app every week.
How is the work priced?
The assessment has one fixed price, agreed in writing before we start. The repairs you choose get one fixed price for that agreed list, and anything outside the list is priced before we do it. We don't quote on the first call, because we haven't seen the app yet.
Who owns the fixes?
You do. Every fix goes into your repository with its tests as we make it, and your hosting, database and other accounts stay in your company's name.
Do I need to send you passwords?
No, and please don't send passwords or customer data by email. We arrange access separately, usually by being invited as collaborators on your code, database and hosting accounts.
Related thoughts
-
Codebase takeover checklist: what to inspect before accepting a system
A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
-
Repair or rewrite?
A rewrite is a conclusion you reach after understanding a system, not a starting point. Most systems proposed for rewrite need an owner, a plan, and a few months of repair.
Does your app work for customers and still worry you?
Write a few sentences: what the app does, who uses it, where it runs, what is going wrong, and any deadline. You don't need to know how it was built. Please keep passwords and customer data out of the email.