When a custom build becomes a product

The question lands the same way every time

We built a reasoning engine for a client in late 2023. It ran their entire property acquisition workflow — intake, feasibility, negotiation tracking, contract assembly. Three months later, a JV partner asked if they could license it. Then another. Then a competitor who'd heard about it second-hand.

The ask was identical each time: "Can we run this for our deals?"

That repetition is the first signal. One inquiry is a compliment. Three is a pattern. Five means you've accidentally built something people will pay for.

What we look for before we productise

We don't productise every repeated request. The decision comes down to four things:

1. The problem is structurally similar across users.

RE.OS worked because property acquisition has the same shape everywhere. You collect documents. You model scenarios. You track milestones. You assemble contracts. The variables change — building type, jurisdiction, deal structure — but the process doesn't.

If every new user needs a different workflow, you're building services, not a product.

2. Configuration beats customisation.

Can you express the differences between users as settings? RE.OS has 140 configuration points. Deal stage definitions. Document types. Approval thresholds. Risk scoring weights. That's enough to cover most acquisition strategies without touching code.

If you're rewriting logic for each deployment, you're still in bespoke mode.

3. The commercial model scales.

Bespoke work bills by the day. Products bill by the seat, the transaction, the outcome. We moved RE.OS to per-deal pricing because acquisition volume varies wildly — some firms close two deals a year, others close fifty.

The economics have to work at both ends of that range.

4. You can handle the support load.

Products create ongoing support obligations. With bespoke, you hand off and walk away. With a product, every user expects answers within hours. We staffed for that before we took the first product sale — two engineers on rotation, documentation that covers 80% of questions, a public status page.

If you can't commit to that, stay bespoke.

What you give up

Productisation isn't an upgrade. It's a trade.

You lose margin. Bespoke work bills at £1,200–£1,800 per day. A product sale might be £15k annually. You need volume to make that math work, which means sales, marketing, and customer success — none of which you were doing before.

You lose control over the roadmap. With bespoke, the client in front of you sets priorities. With a product, you're balancing requests from twelve clients, three of whom are threatening to churn if you don't ship their feature next quarter.

You lose flexibility. Every change has to work for everyone. We turned down a £40k customisation request last year because it would've forked the codebase. In bespoke mode, we'd have taken it.

You lose the ability to walk away. A bespoke project ends. A product doesn't. You're signing up for years of maintenance, updates, compliance changes, and legacy support.

How we made the call

We productised RE.OS because the signals lined up. Seven inbound requests in four months. Identical workflows across four sectors. A configuration layer that handled 90% of variance. A pricing model that worked at 5 deals and 500 deals. And a team willing to commit to multi-year support.

It's been eighteen months. We've deployed to eleven clients. Revenue is predictable. Margin is lower. Engineering is harder — we're managing schema migrations, backward compatibility, and a feature backlog that never shrinks.

We'd do it again. But we wouldn't do it for everything.

If you're getting the same request three times, start asking whether it's a product. If it's not, say no and stay bespoke. If it is, commit fully — half-productised is the worst of both worlds.