Fix my AI app — 48-hour triage.

Symptoms that send founders to fix-my-AI-app

Fix my AI app — which builder shipped which break.

How we fix AI apps

Step 1: The free Rescue Diagnostic

Every engagement starts with a 48-hour async codebase audit that costs nothing. You send us read access to the repo, the hosting provider, and ideally the database. We map every production blocker we can find and categorise them by severity. We don't run the app in front of you and we don't ask you to narrate what's broken — you already tried that with the AI and it didn't work. Instead, we read the code the way a senior engineer would review a pull request: skeptically, end-to-end, looking for the patterns that AI builders consistently miss.

The gaps almost always fall into three categories. Security gaps — Supabase row-level security disabled on tables that hold user data, auth edge cases around expired sessions and password resets, secrets accidentally checked into client bundles, CORS wide open on internal endpoints. Reliability gaps — Stripe webhooks that handle one event type and ignore five others, missing error handling on async flows, no retry logic on network calls, race conditions in state updates. Devops gaps — no CI/CD pipeline, environment variables that only exist on one developer's laptop, the wrong database URL in production, no staging environment to test migrations against. At the end of the 48 hours you get a written report with a prioritised fix list and a recommended scope. The diagnostic costs $0. You owe us nothing if you decide not to move forward.

Step 2: Fix the right things first

We don't fix everything at once. The diagnostic usually surfaces eight to twelve issues, and attacking all of them in parallel is how you end up in the exact regression loop that got the AI stuck. Instead, we sequence the work by blast radius. Security issues — data leaks, auth bypasses, anything that lets one user read another user's records — come first. They're the most dangerous and the least visible; the app can look perfectly fine while it's quietly leaking PII to anyone who knows how to open the network tab. Then reliability issues that block revenue — payment flows that silently fail, deploys that ship half the changes, webhooks that drop events. Those are the ones the CEO notices. Then code quality issues — architecture, typing, test coverage, dependency hygiene — that slow future development but don't affect users today.

We match the work to the smallest fixed-price scope that solves your blockers. $299 Emergency Triage for a single production bug with a 48-hour turnaround. $499 Security Audit when the diagnostic turns up RLS gaps, exposed secrets, or webhook verification holes. $799 Integration Fix when Stripe, auth, or a third-party API is the problem. $3,999 Break-the-Fix-Loop when the AI has been chasing the same bug for a week and something fundamental is wrong with the architecture. $7,499 Finish My MVP when the app is close to launch but needs production hardening across the board. You pay a fixed price up front, we deliver against a written scope, and nothing turns into an hourly meter running in the background.

What we preserve and what we change

We don't rewrite working code. If the UI ships and users can navigate it, we leave the UI alone. If the data model holds the right shapes and the app reads and writes them correctly, we don't refactor the schema. If the user flow — sign up, onboard, convert, return — is the one the founders designed, we don't redesign it. The parts of the app that work are the parts that survived the AI's happy-path generation, and throwing them away because they weren't built the way we'd build them is the kind of scope creep that turns a 10-day rescue into a 3-month rebuild.

We add what's missing. RLS policies on every table that holds user-scoped data. Webhook handlers for every Stripe event your billing model actually depends on. A CI/CD pipeline that runs type checks, lints, and tests before anything ships. Auth edge case handling for expired sessions, stale tokens, and OAuth callback loops. Environment configuration that's consistent between local, staging, and production. Error boundaries that catch the crashes the AI didn't anticipate. The goal is a production-safe codebase that any developer can open and maintain six months from now — not a showcase of how it could have been built from scratch if we'd started on day one. We ship you something you can keep running.

Why AI apps fail in the same ways

AI tools are optimised to generate working demos, not production systems. That's not a criticism — it's the job they were built for, and they do it better than anything else in the industry right now. They handle the happy path with impressive fidelity: user signs up, the session persists, the dashboard loads, they click a button, something useful happens, they leave happy. If your app does that on the first try, it's because the model has seen ten thousand variations of the same flow in its training data and can stitch together a credible version in minutes. The screen recordings look great. The demo lands.

What the AI misses is everything that happens off the happy path. What happens when the user's session expires mid-transaction and the client has stale credentials but the optimistic UI already rendered success. What happens when Stripe fires a webhook at 3am and the handler crashes because a dependent record hasn't been created yet. What happens when a database migration fails halfway through and leaves the schema in a state neither the old code nor the new code expects. What happens when two users modify the same record simultaneously and the last write wins silently, clobbering the first user's change without any feedback to either of them. What happens when a third-party API returns a 500 and the retry logic retries forever with no backoff and no dead-letter queue. What happens when the OAuth provider changes its callback URL format and the redirect loop starts sending users to a 404.

This isn't a failure of the AI — it's a different job. Writing code that handles a known flow is a pattern-matching problem, and models are excellent at it. Writing code that anticipates failure modes across a distributed system is a reasoning problem, and it requires context the AI doesn't have: which of these endpoints faces the public internet, which database rows are hot and contended, what's your tolerance for eventual consistency, which failure modes are acceptable degradation versus customer-visible bugs, what does your observability story look like when things go wrong at 3am. The AI ships the prototype. We ship the product. That division of labour is exactly what we're built around: you get to move fast with the AI to find product-market fit, and when you have something worth keeping, we come in and turn it into something you can actually keep running.

What a typical diagnostic actually finds

To make this concrete: a recent rescue came from a founder who had a Lovable-built SaaS going to YC demo day in nine days. Paying customers, fifteen of them, on Stripe subscriptions. The audit surfaced eleven issues in 36 hours. Supabase RLS was off on every single table, including the one that stored credit card last-four digits. The Stripe webhook only handled checkout.session.completed, which meant that the moment a customer's card expired and Stripe marked the subscription past due, nothing happened — the user kept getting the paid tier because the database never learned about the change. The OAuth redirect URLs still pointed at the Lovable preview subdomain, so login worked for the founder (who had a cached session) but not for any new signup. The staging environment didn't exist. Environment variables were inconsistent between Vercel and the local .env file. There was no error monitoring, so the 40% of page loads that were throwing uncaught promise rejections were invisible.

None of those issues were exotic. Every single one appears in roughly every other rescue we do. The pattern is consistent because the cause is consistent: AI builders are trained to satisfy the prompt, and the prompt almost never includes “and make sure the subscription state stays in sync if the customer's card is declined on renewal” because the founder didn't know to ask. The builder delivers exactly what was asked for. The gap between what was asked for and what production actually requires is the gap we exist to close.

How we work during the fix

Once scope is agreed, we branch from your main and work in a feature branch that opens as a pull request on day one. You can see every commit as it lands. We write a short note at the start of each day saying what we're touching and why, and we write a short note at the end of each day saying what shipped and what's left. No Slack channel, no daily standup, no project management overhead — just a PR description that stays current and a changelog that tells you what the state of the world is. If something unexpected comes up mid-fix — a hidden dependency, a missing credential, a schema the diagnostic didn't catch — you hear about it the same day, in writing, with options and a recommendation.

We ship behind a merge, not behind a deploy. Every fix lands on main only after it's passed type checks, tests, and a staging deploy. We don't hotfix production directly and we don't push commits without review, even on emergency work — because the most common way to turn a bad week into a catastrophic one is to skip the checks “just this once” under pressure. If you need a rollback, it's one click on your hosting provider. If you need to audit what we did months later, the PR is your paper trail. And when we hand the codebase back, you get a written summary of what was changed, what was added, what was left alone, and what to watch for next — so the developer you hire after us can pick up exactly where we left off without reverse-engineering our work.