Handing Over Something Half-Built (Without Paying Twice)

When you take a half-built product to a new team, you get one of two sentences.

"Yeah, we can work with this."

Or: "Honestly, we'd have to start again."

Here's the uncomfortable part. Both of those can be completely honest, and both can be a sales position, and from where you're sitting they sound identical. So this last article in the series is about how to tell the difference, and how to hand over what you've got in a way that means you only pay once for the thinking you've already done.

What are you actually handing over?

More than the code, and the code is usually the least interesting part of it.

The code, in a repository you can access. Not a zip file emailed on a Friday. A repository, with its history, in an account with your business name on it.

The database and a copy of the real data. Structure and contents. If there are already customers in there, that data has legal weight and commercial value, and it needs to move deliberately rather than get exported at the last minute.

The accounts. Domain, hosting, email service, payment provider, anything with a login and a bill. If you haven't run the ownership audit, do it before you start any handover conversation, because it's a much easier request while everyone's still friendly.

The decisions, and why. This is the one nobody packages and the one that saves the most money. Why the booking flow works the way it does. Which thing you tried that customers hated. What the two failed pricing experiments taught you. A new team that has to rediscover all of that will rediscover it slowly, on your invoice.

The list of what's broken. Every builder knows the soft spots. Ask for them in writing, plainly, with no blame attached. Someone who'll write that list honestly is someone worth staying in touch with.

What customers said. Screenshots of messages, the questions people asked twice, the bit where everyone got stuck. Your prototype's real output isn't the software, it's this.

Bundle those six things and you have a handover pack. It fits in a shared folder and it is genuinely worth more than the code.

What a good team keeps, and what they bin

Predictable, once you know the pattern.

Usually kept: the shape of your data, if it's sane. The screens and the flow through them. Your copy. The product decisions you've already tested on real people. Configuration of the things you've connected up, like your payment provider or your email sender.

Usually replaced: hand-rolled logins and passwords, because there are boring, well-tested ways to do that and hand-built ones are where the nasty security problems live. Anything touching money, unless it was done with a mainstream provider properly. Whatever was written to work around a limitation of the tool it was built in. Anything nobody can explain.

The honest grey area: the design. Sometimes the look survives and the code under it doesn't, which sounds like a rebuild to you and is closer to reupholstering to us. Ask which one they mean, because "we're rebuilding the front end" and "your product is wrong" are very different sentences.

How do you read "we'd have to start again"?

Ask three questions, and the answers sort the honest version from the lazy one quickly.

"Which specific parts, and why those?" An honest assessment is specific and mixed. "We'd keep your data structure and the booking flow, we'd replace the login system and how payments are recorded, and we'd redo the admin screens because they weren't finished." Vagueness is the tell. Nobody who has genuinely read your code struggles to name what's wrong with it.

"What would you keep?" If the answer is nothing, be suspicious. There's always something. Even a badly built prototype contains a working answer to what the product should do, and a team that can't see that is telling you they haven't looked, or that they'd rather not.

"Is this a technical problem or a taste problem?" Developers have preferences about tools the way tradies have preferences about brands, and both will occasionally dress up a preference as a necessity. "It's not built the way I'd build it" is not a reason to spend your money. "The way it stores customer records means we can't add a second location without redoing it" is.

There are real cases where starting again is the right call. Nothing runs outside one person's laptop. The data model can't express what your business actually does. It's built on a platform that's been abandoned. Security problems run through it rather than sitting in one corner. In those situations a good team will say so and still keep your screens, your copy and your decisions, because those aren't the problem.

The version to walk away from is the one delivered before anyone looked properly, with no specifics, followed by a quote for the full thing.

Don't pay twice for the thinking

This is the bit I'd underline if I could only keep one paragraph.

Everything you learned building that prototype is worth money. You know what the thing does, who wants it, what they ignore, where they get stuck and what they'll pay for. A team starting from a blank page has to buy that knowledge with your budget, in workshops, over weeks, and they still end up guessing. You already have it, and unlike a written brief you can show it rather than describe it.

So make the prototype part of the brief on purpose. Give the new team a login and let them use it before they quote. Ask them to tell you what they think it does. If they come back with a clear description that matches what's in your head, that's the strongest signal you'll get all process, and it costs nothing to run.

That's the whole argument of this series, really. Your demo working isn't the same as your product working. Stalling isn't failing. Production ready is a checklist, not a feeling. And the last ten per cent is real work with a real cost, but it's finishing work, not starting-over work, far more often than anyone will tell you while quoting on the rebuild.

If you're sitting on something half-built and you'd like a straight read on which half you've got, that's a conversation we're happy to have. Bring the login, not a summary.