How to commission custom software without getting burned

Every operator who has commissioned a custom build and regretted it tells a version of the same story. The developer seemed capable. The demo looked right. Then somewhere around week six the invoices kept arriving and the thing they were paying for kept not quite existing. Nobody lied to them, usually. The engagement was just never built to protect them if it drifted, and drift is the default state of any software project that isn't actively fought.

You don't need to learn to code to commission well. You need three things in place before you sign anything: a brief that does actual work, milestones you can walk away from cleanly, and an exit ramp that was agreed while everyone was still being reasonable with each other.

The brief is the actual product

Most commissioning failures start here, not in the build. A brief that says "a booking system for our villa business" is not a brief — it's a category. It tells a developer nothing about what happens when two guests want the same date, whether deposits are refundable, what currency the fee shows in, or who gets notified when a booking falls through. Every one of those gaps gets filled by someone's assumption during the build, and assumptions made under deadline pressure are rarely the ones you'd have chosen.

A brief that does actual work reads more like a specification than a pitch. It names the edge cases, not just the happy path. It says what "done" looks like in terms you could verify without asking the developer to explain it to you. If your prospective build partner is willing to sign a one-page agreement built from a 30-minute call, that's a signal — just not the one they want it to be.

Ask for the brief to be written back to you before work starts, in your language, not theirs. If you can't tell whether it's been understood correctly, the eventual build won't be either.

Milestones you can walk away from

The standard structure for a commissioned build is deposit, progress payment, final payment on delivery. That structure protects the developer far more than it protects you, because by the time you'd want to walk away — the point where the work clearly isn't tracking — you've usually already paid the deposit and the first progress instalment, and the incentive to keep going rather than start again elsewhere is strong even when it shouldn't be.

The fix isn't complicated. Milestones should be small enough, and frequent enough, that a bad one costs you a fraction of the project rather than half of it. Each milestone should have a named, checkable deliverable — a staging URL, a working flow, a specific page — not a status update. And critically, each milestone should be a genuine decision point: you should be able to stop after any of them without penalty beyond the work already paid for.

• Small enough to fail cheaply. If any single milestone represents more than roughly a quarter of the total fee, it's too coarse.
• Checkable, not describable. "The booking flow works" should mean you can click through it yourself, not take someone's word for it.
• Genuinely optional to continue. If stopping after milestone two costs you the same as finishing the project, the milestone structure is decorative.

What an exit ramp actually looks like in a contract

Most commercial disputes over software builds aren't really about the code — they're about who owns what happens next. If you want to leave, does the code come with you? Do you get the design files, the credentials, the documentation, or just the live site with no way to change it? A contract that's silent on this isn't neutral; it defaults to favouring whoever built the thing, because possession is most of the argument.

An exit ramp negotiated after the relationship has soured is not an exit ramp. It's a dispute. The only version worth having is the one you agree to while everyone still likes each other.

Before you sign, get explicit answers to: who owns the repository and when does it transfer to you; what happens to hosting, domain and analytics accounts if you part ways; is there a defined handover process if either party wants to end the engagement early; and does the fee structure assume ongoing retainer income, such that ending early creates friction the developer is incentivised to resist.

The stage most operators skip: the reference conversation

Before a brief is signed, ask to speak to someone who has been through a similar-sized engagement with the same partner — not a curated testimonial, an actual short call. What you're listening for isn't "were they happy," which almost everyone will say. It's whether the milestones held, whether the final invoice matched the quote, and whether the handover happened the way it was promised at the start. A partner confident in their own process will arrange this without friction. One who hesitates, or only offers written quotes rather than a conversation, is telling you something worth hearing before you sign rather than after.

This costs you twenty minutes and almost nothing else, and it catches a category of problem that a well-written contract can't: the gap between what a partner promises on paper and what they actually deliver under pressure. Contracts protect you from bad faith. A reference call protects you from good faith paired with an execution problem, which is the more common failure mode.

The questions worth asking before you sign anything

A short list, but each one filters out a meaningful share of engagements that would otherwise go wrong:

• Who specifically is doing the work, and will I speak to them directly during the build?
• What does the brief say about the situations that aren't the happy path?
• What do I get if I stop after the first milestone — code, documentation, nothing?
• Is the fixed-scope agreement actually fixed, or does "reasonable additional work" get absorbed silently?
• What does handover look like on day one of a successful project, in writing, before it starts?

None of this requires distrust of the people you're hiring. It requires treating a software commission the way you'd treat any other commercial commitment of similar size — with the paperwork doing the protecting, so the relationship doesn't have to.