Double bookings across seven channels

Delicious Homes rents furnished apartments in Nairobi. Nights sell through the website, WhatsApp payment links, company and agent invoices, overflow from other hosts, Airbnb and Booking.com. Each channel used to be its own source of truth.

I delivered the whole product: public site, booking and checkout, card payments at the day’s exchange rate, M-Pesa and invoice payments in the same ledger, Airbnb and Booking.com calendar sync, an owner admin, guest reviews and Telegram alerts. Coding agents wrote nearly all of it. My work was the guardrails they operate inside.

Guardrails

Every agent session starts from the project’s rules, each one checkable against a diff:

• One availability table, keyed by apartment and night. The primary key rejects a second claim.
• Every booking state change goes through one module as a single database batch.
• A payment counts when the provider’s API confirms it. Webhooks only trigger that check.
• A calendar feed that fails to load keeps its last known nights.
• No invented facts. Prices, amenities and distances come from the owner, and a missing one stays a marked placeholder. A written list names what never appears on the site.

A design system and the skill that reads it keep new screens on the recorded patterns.

Verification

More than 260 tests run in the Workers runtime against a real D1 database, with outside calls stubbed. Every branch deploys to a preview with its own database. Several agents work in parallel on separate branches.

Timeline

First commit on the morning of 24 October. Fifteen hours later the public site was launch-ready. 46 pull requests merged in the first eight days.