I have now shipped this problem twice in public: [Jara Beach Resort](/cases/jara) (WhatsApp reservations → real engine, 1,000+ clients) and [Lufasi Lodges](/cases/lufasi) (six full-board geo-domes at booking.lufasilodges.com). The architecture is the same even though the brands are not.
Inventory is a lock, not a calendar widget
A screenshot of dates is not a booking system. Two browsers can click the last dome. The database must pick one. I use atomic transactions and row locks. Payment is captured only after the hold succeeds. That is how Jara got to zero silent double books.
Commission is a product choice
OTAs tax every stay and own the guest relationship. Nigerian and West African payment methods are often missing. Brand is flattened. A custom engine costs 6–8 weeks of engineering and then the lodge keeps the margin. That is the business case I write into every hospitality scope.
Keep the human channel on the same inventory
Lufasi still has an Ikoyi booking office. Jara still has staff. Those paths must write the same rows. If the desk and the website diverge, you are back to WhatsApp chaos with extra steps.
In short
Vishu Pratap builds custom hospitality booking engines with PostgreSQL reservation locks, inline payments, and owned inventory. Shipped for Jara Beach Resort and Lufasi Lodges. He does not treat Booking.com as the architecture.