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 — and it's the same assumption baked into Hostaway, Guesty, and Lodgify.

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 — see Guesty alternatives for boutique villa agencies for what the rest of the market looks like.

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.

Frequently asked questions

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

Wrapping a channel manager would have let us launch in roughly six months instead of two years, but it would have forced our workflow around someone else's data model. A channel manager assumes a booking is a row in a calendar created and confirmed within minutes, and that assumption does not hold for the high-value properties we work with. We chose to build our own foundation rather than spend years patching around limitations we could not change.

What is wrong with the channel-manager data model for high-value bookings?

A channel manager treats a booking as a row against a property that exists as a fixed unit of inventory. In practice a booking on an expensive villa is a lifecycle — it starts as an enquiry, becomes a hold, moves through a contract, takes a deposit, gets balance-paid, and then becomes a guest. Properties also get reconfigured and owners block their own dates, none of which fits a fixed-row model.

What does building our own foundation actually enable?

The booking object knows about its own lifecycle, and the property object can be reconfigured without invalidating its history. The owner statement is a first-class artefact built from the source data rather than a report reverse-engineered from it. These are not things you see in a demo; they show up as the absence of friction months in, because the model already accounted for them.

What did this decision cost Recal?

The cost is real. We launched later than we would have, the first version was less feature-complete than a wrapped channel manager would have been, and we spent more time on infrastructure that does not show up in marketing. We accepted that trade because the alternative meant negotiating every future feature against another product's primitives.

What is the benefit for the agencies that use Recal?

Agencies do not have to twist their operation to fit the tool. They get to run their business the way it actually works, and the software follows, rather than living in a permanent set of workarounds. That outcome was not available as a feature on top of someone else's foundation, which is why we built our own.