Why we didn't build Recal on top of an existing channel manager

When we started building Recal, the rational thing to do was to wrap an existing channel manager and put our interface on top. The channel-sync layer is a solved problem; the integrations are messy but documented; we could have shipped in six months instead of two years. Several people we respect told us we'd regret not doing it.

We didn't, and this is the reason.

A channel manager is built around a particular assumption: that a booking is a row in a calendar, created and confirmed within minutes, against a property that exists as a fixed unit in inventory. That assumption is true for short-term apartment lets in city centres. It's false, in practice, for the villas we work with.

A booking on a €30,000 villa is a conversation. It starts as an enquiry, becomes a hold, moves through a contract, gets a deposit, gets balance-paid, and then becomes a guest. Owners block weeks for their own use, sometimes years in advance, sometimes the morning of arrival. Properties get reconfigured — the four-bedroom that becomes a five-bedroom for a single peak month with the annexe opened, the villa that drops a bedroom mid-season for renovation. Bookings are not rows. They are objects with lifecycles.

If we'd built on a channel manager, we'd have spent the next five years adapting the workflow around the underlying data model — patching, working around, hiding limitations behind interface tricks. Every feature we shipped would have been negotiated against the channel manager's primitives. We've watched several competitors take that route. The product surface gets gradually more elaborate; the underlying model stays inflexible; and the agencies they sell to spend their lives in workarounds.

The version of Recal we ended up with looks different. The booking object knows about its own lifecycle. The property object can be reconfigured without invalidating its history. The owner statement is a first-class artefact built from the source data, not a report generated by reverse-engineering it. None of this is a feature you can see in a demo. It shows up in the absence of friction six months in — the thing you don't have to work around because the model accounted for it.

The cost of building this way is real. We launched later than we would have. The first version was less feature-complete than a wrapped channel manager would have been. We've spent more time on infrastructure that doesn't show up in marketing.

The benefit, the one that justifies the cost: the boutique villa agencies who use Recal don't have to twist their operation to fit our tool. They get to run their business the way the business actually works, and the software follows. That's the product we set out to build, and it wasn't available as a feature on top of someone else's foundation.

We're a small team. We will get a lot wrong. But we won't get this part wrong, because we already paid for it.