A client built a working web app with Lovable in two weeks: screens, features, interactions, all of it. Then he asked me to take a look, and my honest first thought was: it's done, so what's left for me to do? Quite a lot, it turns out. AI tools haven't made consultants less useful. They've moved where the value sits, from building features to building the guardrails that let a non-technical owner keep building safely.
What two weeks got right, and what it missed
The app looked great and mostly worked. The problems were all in places the owner couldn't see:
Issue | What the owner sees | What's actually happening |
|---|---|---|
Permissions not set up | Everything works | Users can reach data that isn't theirs |
Three login pages | A login screen | Nobody's identity is actually verified |
System invite emails | "Sent" | Gmail files them as spam |
Browser tab icon | Nothing | Still the tool's default icon |
None of these throw an error. The site just keeps quietly looking good, and that's exactly why the owner had no way of knowing any of them were on the list.
Lock-in is mostly a solved problem
Another technical partner on the project took the opposite view: AI-generated code isn't usable, it's full of security holes, and migrating off it later will be painful.
I don't see it that way. Lovable's Git Sync pushes the full codebase to the client's own GitHub, so it can be moved whenever they want. Vendor lock-in, the biggest risk of building on a platform like this, is already handled.
The security concerns are real. But the conclusion shouldn't be "so don't use it". It should be "so here's what we add after".
From features to guardrails
This changed how I think about client work.
Before | Now | |
|---|---|---|
Who builds features | The consultant | The client, with Lovable, v0 and similar tools |
What the consultant delivers | A finished app | The guardrails around an app that keeps growing |
When the engagement ends | At handover | When the client can safely build on their own |
The guardrails are the boring layer: a permission model, tests, CI, a migration path, email infrastructure. Get them right and nobody notices. Get them wrong and it blows up months later, usually at the worst time. That's precisely the layer a non-technical owner is least likely to think about.
It also runs against the old consulting instinct. You used to want clients to depend on you. Now, the more capable the client is of building on their own, the more those guardrails are worth.
The hard part: none of this is a feature
Clients measure work in features: "how long will this take to build?" Testing and migrations don't appear on their to-do list at all.
So my conversations now sound different. Instead of "here's what I'll build", it's: "It already works. Let's look at what's between this and being ready to open for business." And every item gets paired with a way it breaks that the owner actually understands:
Permissions: when a staff member leaves, can they still see client files?
Login: could someone reach the admin page just by guessing the URL?
Email: a new client never sees your invite and thinks you didn't follow up.
Framed that way, guardrails stop sounding like technical overhead and start sounding like risk the business is carrying right now.
The takeaway
If your team has already built something with AI, the hard part isn't behind you, it's just moved. The question isn't whether the app works. It's what's missing before you can trust it.
That's the work we do at FlyCoder. We build systems that fit how professional services firms actually work, connect them to the tools you already use, and maintain them on retainer so they don't quietly fail.
Built something with AI and not sure what it's missing? Reply to this email, or book a 30-minute discovery call.
Or learn more at flycoder.io.