You did the part nobody can outsource
Most software projects fail before a line of code is written. Nobody knows exactly what to build, who it’s for, or what customers will actually pay for. You worked that out yourself, by building it.
Your first version holds years of what you know about your customers, your industry and the workflow you’re fixing. Every screen is a decision you made. Every odd field in a form is there because a real customer needed it. That domain knowledge, and the drive that got a working product in front of people, is what a business is built on. I can’t supply it, and no engineer can.
So I don’t treat your app as a mess to be cleaned up. It’s the most complete spec I’ll ever be handed. You’ve already explored the product. Now it gets built properly.
What it usually needs, and why
Apps built quickly with AI tools tend to share a handful of gaps. None of them mean you did something wrong. They’re the parts an AI assistant doesn’t do unless an engineer asks for them, and that you’d only know to ask for after years of watching apps break.
- A data model that matches the business. AI tools invent tables as they go. A year in, the same customer exists in three places, a status lives in free text, and nothing stops two records from contradicting each other. Your code can be rewritten in weeks. Bad data can take years to untangle, so this comes first.
- Tests. Without them, every change is a gamble, which is why fixing one thing keeps breaking another. A test suite is what lets you (and an AI assistant) change the app without fear.
- Safe, repeatable deploys. One command, the same steps every time, with a way back if something goes wrong.
- Security and access. Who can see which records, secrets kept out of the code, logins and payments done the standard way.
- Speed as you grow. Pages that were instant with fifty records and crawl with fifty thousand. I measure before I change anything: query plans, missing indexes, work that belongs in a background job.
- Monitoring. You hear about an error from a dashboard, not from a customer.
Fix it or rebuild it?
That depends on what’s under the hood, and I’ll tell you plainly after reading it. Often the right answer is to keep most of what you have: firm up the data model, add tests around what matters, and fix the parts that are actually fragile. Sometimes a codebase has grown so tangled that every fix makes the next one harder. Then rebuilding on a clean, conventional base is faster and cheaper than patching. When it’s a rebuild, it goes quickly, because every product decision is already made and your version is the reference for each one.
Either way, you keep running your business on the current app while the work happens, and nothing switches over until it does everything the old version did.
Documentation, so you’re never stuck with me
The fear I hear most from founders is a developer who vanishes, or who becomes the only person who understands the system. I work the other way round. Leaving you in a position where any competent developer can pick up where I stopped is part of the job, not an extra:
- A plain-language system overview: what the parts are, where the data lives, what talks to what.
- Runbooks for the things that happen: deploying, restoring a backup, rotating a key, onboarding a new developer.
- Decision notes: why it’s built this way, what was considered and rejected, and what to watch as you grow.
- Performance notes: what was measured, what was changed, and the numbers before and after.
- Instructions for AI assistants too, so the next person who opens the code with an AI tool gets good help instead of confident guesses.
You own all of it: the code, the accounts, the hosting, the documents.
Take a business like this one
The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.
Picture a founder who spent twenty years running scheduling for home-care agencies and built a scheduling app over a few months with an AI tool. Eleven agencies pay for it. It works, mostly. But a change to the shift calendar broke invoicing last month, two agencies once saw each other’s caregivers for an afternoon, and the AI tool now goes in circles on every new feature.
What I’d do for a business shaped like this:
- Week one: read and report. A written assessment of what’s solid, what’s fragile and what’s risky, and whether to repair or rebuild, with reasons.
- Close the dangerous gaps first. Make sure each agency can only ever see its own data, back up the database somewhere separate, and add monitoring so errors show up before customers report them.
- Fix the data model. One record per caregiver, per client, per shift, with the rules enforced by the database instead of hoped for in the code. Existing data gets moved over and checked.
- Tests around the money and the schedule, the two things that must never quietly break.
- Deploys and performance. A repeatable deploy, then the slow pages, measured and fixed.
- The handoff pack. Overview, runbooks, decision notes and AI-assistant instructions, so the founder can bring on their next developer, or keep building with AI tools, on solid ground.
The founder keeps doing what only they can do: talking to agencies and deciding what the product should do next.
What it costs
Every engagement starts with a small fixed-price assessment, so you get an honest written read of your app before committing to anything bigger. The work after that is scoped and quoted from what the assessment finds. No retainer you can’t get out of, and no per-seat licences.
What I need from you
Access to the code and the hosting, an hour walking me through how your customers use it, and your list of what scares you most about it. Then someone (usually you) who will tell me when I’ve misunderstood how the business works, because you know it better than I do.