- Finishing
- AI-generated code
- Launch
How to finish an AI-built app that’s stuck at 80%.
The last 20% of an AI-built app is integrations, edge cases and deployment. Take an honest inventory, wire real payments and auth, and get it live.
Read
9 min read
v0 generates good-looking screens — and stops there. What it hands you is usually screens filled with placeholder data, no real connection to a database, and some code running in the wrong place (Next.js splits code between the server and the visitor’s browser, and v0 doesn’t always get that split right). The fixes are specific: connect real data, put the code where it belongs, and make the Vercel publish succeed for the right reasons.
Small mistakes the preview tolerated but the real publish doesn’t — often one wrong reference or a missing setting.
Next.js runs some code on the server and some in the browser. v0 often mixes them up, and the usual quick fix — adding ‘use client’ everywhere until the errors stop — quietly breaks how data loads.
Lists typed straight into the screen so the design looked right. There is no database behind them, and no ‘loading’ or ‘something went wrong’ state.
A beautifully styled form with no server action behind it, or one that succeeds visually and saves nothing.
Login screens and pricing pages that display, with no real accounts, no protected pages and no payment provider connected.
The screens v0 produced are usually the part worth keeping, so I keep them. I add what is missing underneath: a real connection to a database, logins that actually protect pages, payments wired to a real provider, and the loading and error states the placeholder data never needed.
Code gets put where Next.js expects it, rather than wherever the errors went quiet. You get a repository that publishes cleanly on Vercel and a note on what each fix was for.
Yes — all of them, plus Claude, Copilot and ChatGPT output. I don’t much care which tool generated the code. What matters is the application underneath it: the architecture, APIs, database, dependencies, and where things are breaking. Lovable and Bolt projects tend to need deployment and backend work; Cursor and Copilot projects more often need the seams between generated pieces checked.
Yes — mobile, web and AI-powered products. It's a different engagement from a rescue: we start with what the thing actually needs to do, and I'll usually push to get a small version in front of real users before building the rest. If your idea is better served by something simpler than what you're picturing, I'll say so.
Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.
It depends on the work, so I don’t publish a price list. After a first look I quote a fixed price for the diagnosis, and any fix is scoped from the findings — so you know the cost before any work begins, and nothing changes partway through.
The service
Most of it exists. The last stretch is the part where the AI stopped being useful — the integrations, the edge cases, the settings screen nobody wants to build, the deployment that never quite worked.
The last 20% of an AI-built app is integrations, edge cases and deployment. Take an honest inventory, wire real payments and auth, and get it live.
Read
9 min read
Nine differences between your machine and production, in the order they break: env vars, build output, ports, database, CORS, paths, time, memory and secrets.
Read
9 min read
It might need an engineer.
If you’ve spent hours asking AI to fix the same problem and you’re going in circles, stop fighting the code. Send me what you’ve got — I’ll figure out what’s wrong and tell you what I’d do next.
No cleanup. No judgment. The messy version is usually the useful version.