When a bespoke build wants to become a product
Three joint-venture partners asked for the same core capability. That's when we knew RE.OS needed to exist as a product, not just another one-off.
The pattern that matters
Three different real-estate firms, three separate conversations, same request: "We need to ingest unstructured property data, structure it with LLMs, and push it into our CRM without manual review."
Not similar. Identical.
That's the signal. When you build something bespoke three times and the delta between implementations is configuration, not code, you're sitting on a product that doesn't know it yet.
We'd built the first version for a commercial property group. Scraped listings, extracted fields, matched to their taxonomy, wrote to Salesforce. Took six weeks. The second build was faster — four weeks, different CRM, similar logic. By the third enquiry, we had 80% of the system parameterised. We weren't building; we were filling in a template.
That repetition is expensive for us and annoying for clients who know they're paying for code we've already written. Productisation stops that.
What we look at
Before we committed to building RE.OS as a product, we checked five things.
Convergent demand. Not just volume. Three clients wanting property ingestion matters more than ten clients wanting ten different things. We need requests that collapse to a shared core with variable edges.
Stable interface. Could the inputs and outputs stay consistent across customers? In our case: yes. Unstructured property data in, structured records out. CRMs and taxonomies vary, but the transformation shape doesn't.
Viable standalone economics. Would the product pay for itself without services attached? We modelled recurring revenue at £2k–5k/month per customer against build and maintenance cost. Worked. Barely, but worked.
Defensible abstraction. Could we build something generic enough to reuse but specific enough to stay useful? Real-estate ingestion is narrow. Narrowness helps. "AI data pipeline" is too broad. "Property listing structuring for CRMs" is a box we can own.
Our own tolerance for support. Products create support load. Bespoke work doesn't — you build it, you leave. With RE.OS, we'd be on the hook for uptime, edge cases, customer questions. We sized the team assuming 20% of dev time would shift to support. That changed what we could commit to elsewhere.
All five checked out. We productised.
What you give up
Productisation is a trade. You gain leverage and recurring revenue. You lose margin and control.
Margin compression. A bespoke build might net 60–70% margin. A product sold at £3k/month with hosting, support, and updates might net 40%. You make it up in volume, but only if volume arrives. Early on, it feels like a downgrade.
Feature veto power. When a client pays £80k for a bespoke system, they get what they want. When they pay £3k/month for a product, they get what the product does. You have to say no to custom requests that don't generalise. That's uncomfortable, especially with early customers who remember when you said yes to everything.
Operational load. Bespoke work ends. Products don't. You're now responsible for uptime, versioning, migrations, and bug fixes across every customer simultaneously. Your calendar fills with maintenance. Your roadmap fills with incremental improvements instead of new projects.
Speed of iteration. Bespoke builds move fast because you control the entire stack and the customer sees progress weekly. Products move slower because changes propagate to everyone. You add gates: staging environments, regression tests, rollback plans. Necessary, but slower.
We still do bespoke work. RE.OS exists alongside it, not instead of it. Some problems need a product. Some need a build. The skill is knowing which is which before you start.
What this means
If you've built the same thing twice and someone just asked for it again, start counting. Three is the number. After that, you're choosing to stay bespoke — which is fine, but it should be a choice, not inertia.