Meet the Data Where It Lives

The easiest way to build a new operational tool is to give it its own database and ask people to type their world into it a second time. It is also usually the wrong call. If a customer already runs their bookings through a property management system, asking their team to duplicate that data by hand is not a small workflow tax. It is a bet that two copies of the same facts will never drift apart, and they always do.

I hit this building a cleaning-operations platform for short-term rental operators. Bookings already lived in the PMS each host had chosen, so the question was never whether to integrate, only how early. We ended up syncing properties and bookings in from three of them, because "which PMS do you use" is a question with more than one answer and picking a favourite would have meant picking which customers to turn away.

The decision shapes the data model long before any integration code exists. Once you accept that the source of truth lives outside your system, you stop designing forms and start designing reconciliation: what happens when a booking changes upstream, what your product is allowed to overwrite, which records are yours and which are borrowed. Those are hard questions, and they do not get easier by deferring them. A product that assumes it owns its data and later discovers it does not is a rewrite, not a refactor.

The part worth keeping is that this was never really an API question. Three integrations is an implementation detail. The decision underneath was about who pays the cost of re-entry, and for how long — and that one gets made in the first week, whether or not anyone notices they are making it.