The AI Handoff

I've now watched the same thing happen in two large organisations. A director, a marketing manager, or someone in operations sits down with Claude or Lovable and, over a few focused afternoons, builds something genuinely useful. A pipeline. An internal tool. A workflow that saves their team real time. They iterate on it, they get it working, and they can clearly see the value it would bring to the company.

This is great, and I mean that. Those people are unblocked. They didn't wait six months for a developer's calendar to clear. They got to feel what so many of us in software take for granted: the joy of making something that works. I'm a huge fan of people building things, and I want more of it, not less.

Then comes the moment I've started calling the AI handoff. The prototype works. Leadership likes it. Now it needs to be handed to the right team, or to the technical staff, so it can "get implemented."

That's where the trouble quietly begins.

Why This Keeps Happening

It isn't a failure of the people involved. It's a predictable result of what these tools are good at.

AI tools are extraordinary at getting you from nothing to a working demo. They are far less helpful at the things that come after: deciding where the thing runs, who can log in, what happens to the data, and who gets the call at 2am when it stops. None of those questions come up while you're prompting. The app works, the screen looks right, and everything about the experience says done.

So the builder, quite reasonably, believes the hard part is behind them. They've done the thinking, proven the idea, and built the thing. What's left sounds like admin: "just get IT to put it live."

But the thing that's left isn't admin. It's most of the work.

What Actually Gets Handed Over

Here's the gap, side by side. On the left is what the builder sees. On the right is what a business needs before it can rely on the thing.

What the prototype shows	What production needs
It works for the person who built it	Proper sign-in, roles, and permissions tied to your company's identity system
It connects to the data	Controls on who can see which data, encryption, backups, and a retention policy
API keys pasted in to make it run	Secrets stored and rotated properly, never sitting in code or a chat history
It runs on a hosting platform and backend someone signed up for	Environments, deployments, and hosting that your IT team can run and audit, under a company-owned account
It worked when the demo was recorded	Automated tests, so the next change doesn't silently break something else
A pile of packages, installed once	Someone watching for vulnerabilities and updating dependencies, indefinitely
It runs	Logging, monitoring, and alerts, so you find out it's broken before your users do
It does what it was prompted to do	Documentation, so someone other than the author (or the AI that wrote it) can safely change it
It uses an AI API	A budget, usage limits, and a plan for when the model or its pricing changes

None of this is exotic. It's what any piece of business software needs. But very little of it exists in a prototype, and almost none of it is visible to someone who isn't a developer. You can't see a missing backup. You can't see an expired certificate coming, or a dependency with a known vulnerability.

If the tool touches customer data, or anything covered by regulation, that last column isn't optional. And if the pipeline calls a language model, there's a whole extra layer of design to think about, which I covered in how to design human-in-the-loop AI workflows.

Ownership Is Where It Really Falls Apart

The first question is the simplest: who owns this now?

I wrote about this in the SaaS-apocalypse post, from the point of view of the person who builds a tool to save a subscription fee. The handoff is the same problem seen from the other side of the desk. It has two versions, and both are uncomfortable.

If the builder keeps it, they've quietly taken on a second job. Every bug report, every dependency update, every "can it also do this?" lands on someone whose actual role is something else, and who may not be able to judge how much they've signed up for. It works for a few months. Then they get busy, as they should be, and the tool slowly rots in the background.

If IT takes it, they've inherited something they didn't ask for, didn't design, and have never seen the inside of. They're accountable for its security and uptime from day one, without having chosen the stack, the architecture, or the hosting. A good engineering team will, rightly, hesitate to put their name on that.

Either way, ownership gets decided by default rather than by decision. Defaults are how important systems end up with nobody's name on them.

Two Stories

I've seen this land in two different ways, and they fail in different places.

The Python tool

The first was a pipeline that a team inside a large organisation built in Python. It worked, and it worked well. The catch was that the company's engineering team doesn't use Python.

That leaves three options, none of them painless:

1. Adopt it. The technical team learns enough Python, and enough about this specific codebase, to run it in production. That means training, new tooling, and a new language added to the list of things the team supports for as long as the tool lives. It's also the right call when the tool is going to be a core, long-lived system, because a team can't support something it doesn't understand.
2. Rebuild it. Rewrite it in the stack the company already knows and already knows how to deploy, monitor, and secure. You pay the cost once, upfront, and end up with something the team can own. The prototype becomes the specification.
3. Fence it. Run it as a small, isolated service with clearly defined inputs and outputs, and treat it as a black box someone owns. This can work for narrow, stable jobs, but only if there's a named owner and a plan for when it needs to change.

The hidden cost in all three is the same. The "we built it ourselves" win turns into either a retraining programme or a rewrite. That's not necessarily a bad outcome, but it's a very different project from the one everybody thought was nearly done.

The Lovable tool

The second was built in Lovable. These tools are quick, and the demo looks great. But the result is rarely a single thing. It's a React front end, plus a hosted backend that provides the database, user sign-in, file storage, server-side functions, and secrets. Lovable's built-in backend, Lovable Cloud, is built on Supabase, and a project can alternatively be connected to your own Supabase account. Underneath both sits a long list of third-party packages.

The front-end code can be synced to GitHub, and Lovable is clear that you can deploy outside its platform from there. That's a genuine strength. But the code is only part of the system. Your users, your data, your files, and your secrets live in the backend, and moving them somewhere else is not a copy-and-paste job. Lovable's own documentation describes moving to your own Supabase as a migration: exporting and restoring the database, moving the stored files, and setting up authentication and secrets again. It also warns that permanently removing a project's database deletes its backups, user accounts, and stored files along with it.

That makes the handoff questions harder, not easier. Who's watching those packages for vulnerabilities? Who fixes the bug that appears when a dependency ships a breaking update? Who understands the data model well enough to change it without losing data? And who owns the account everything is hosted under? If it's the builder's, what happens when they change roles or leave the company?

Once the director or manager gets back to the work they were actually hired to do, the honest answer is often: nobody. Not out of negligence. Simply because nobody was ever asked.

The Code Nobody Fully Understands

There's one more problem that's specific to this era, and it's worth saying plainly.

When a developer writes a system, there's at least one person who understands why it looks the way it does. When someone builds a system by prompting an AI, there often isn't. The builder knows what they asked for, but not necessarily what was built. The AI that produced it has no memory of the decisions it made along the way.

That doesn't make AI-generated code bad. Much of it is perfectly reasonable, and the tools are getting better quickly. But it does mean the usual safety net, "ask the person who wrote it," is missing. Anyone taking on the system has to work backwards from the code to the intent. That's slower, and it's why a handoff without proper documentation and tests is so much riskier than it looks.

Let's Be Honest: It's a Prototype

The common thread in all of this is that what gets handed over is rarely production software. It's a prototype.

I don't say that to diminish it. A working prototype is worth a lot. It proves the idea. It wins buy-in. And it captures what someone actually wants better than any requirements document I've ever read, because you can click on it.

The most valuable thing in the handoff usually isn't the code. It's what the code proves:

• The workflow is real, and someone has already tested it against the way the business works.
• The inputs, outputs, and edge cases have been discovered by actually using it.
• There's an engaged, knowledgeable sponsor who understands the problem deeply.

Those are the hardest things to get at the start of a software project, and the builder has already done them. What's missing is the engineering that lets it run quietly and securely for years. That gap is real, and it's bigger than it looks, but it's also entirely closable.

What a Good Handoff Looks Like

If you're about to hand over something built with AI, or about to receive one, these are the questions to settle before anyone says "go live":

1. Who is the named owner, today and in two years? A person, not a team alias.
2. Where does it run, and can your IT team access, audit, and redeploy it without the builder?
3. What data does it touch, and are you allowed to put that data into it? Is it stored anywhere you didn't intend?
4. What credentials does it use, and where are they kept? Who can rotate them?
5. How will you know when it breaks? Is there logging, monitoring, anything that alerts a human?
6. Can the technical team support it in the languages and tools they already use? If not, what's the plan?
7. What happens when it needs to change? Is there a test suite, a way to review changes, and a way to roll back?
8. What does it cost to run every month, including hosting, services, and AI usage? What stops that bill from growing unnoticed?
9. Is it worth owning? Or is there a product that already does this, which someone else would maintain for you?

That last question matters most. Sometimes the right outcome of a successful prototype is realising you should buy something. The prototype did its job. It showed you precisely what you need, and now you can evaluate real products against it. That's the build-or-buy judgement I keep coming back to, and a good prototype makes it far easier to get right.

Where Happen Software Fits In

This is the gap we sit in. We've spent more than fifteen years building software for other organisations, which means we've spent a long time on the unglamorous end of this problem: the part after the demo. There are two ways we work with people at this point, and they map onto the two situations above.

Path one: turn the prototype into production software

You hand us what you've built. We treat it for what it is, a very good specification that happens to run.

We start by working out what's worth keeping. Sometimes the existing code is a sound base and we harden it. Sometimes the right move is to rebuild it cleanly, in a stack your technical team already knows, using the prototype as the blueprint. Either way, we handle the work that never made it into the demo: authentication and permissions, secrets, data protection, tests, deployment pipelines, hosting, monitoring, and documentation. You end up with something your own team can run, and which doesn't depend on any of us being around.

That last part is deliberate. Our goal isn't to leave you reliant on us. It's to hand back something your team genuinely owns.

Path two: work with the person building it

This one is the more interesting path, and honestly my favourite. If a manager has a clear vision and is enjoying building it, there's no reason to take that away from them. Let them keep building.

What changes is the foundation. We work with them, setting up the structure that makes AI-assisted building sustainable: a proper repository and deployment pipeline, tests that catch breakage, a stack the company can support, and the habits that get far better results from tools like Claude. Small, reviewable steps. Clear specifications up front. Context the AI can rely on rather than guess at. Every change checked before it reaches real users.

The result is that the manager keeps the momentum and the ownership of the idea, and the thing that gets built is something that can actually go live. It's the difference between prompting and hoping, and building with discipline, and it changes what these tools are capable of.

And sometimes the answer is "don't"

I'd rather say this than not: not every prototype should become a product. Some should stay prototypes, used by a small team who understand the limits. Some should be replaced by software you can simply buy. We'll tell you if that's the case, because it's cheaper to find out early than after it's gone live.

Build, Then Hand Over Properly

I said it at the end of the SaaS-apocalypse post, and it applies here just as much: choose wisely what you build, and choose wisely what you buy.

The AI handoff is simply where that choice catches up with you. The tools have genuinely lowered the barrier to building, and that's something to celebrate. But the people who've done the hard work of understanding the problem shouldn't then be left holding the bag for running it, and the technical teams who receive these tools shouldn't be set up to fail.

If you've got something built with AI that's heading for production, or one is about to land on your desk, let's talk about it before it becomes somebody's problem. You can see how we take AI-built prototypes to production, or read more about how we approach custom software and how our AI Concierge works, or about what a software firm is still for in the age of AI.