Stay
Thesis
Stay began as a way for us to rent out our apartment to friends and friends of friends in one of the most sought-after area codes in the world. It has evolved into a SaaS product: an invite-only booking platform that hosts run themselves, without high fees or unvetted guests.
Trust is the single most important factor when a homeowner opens their home to a guest. Stay leverages that trust by making the platform invite-only — homeowners rent to their own network, on their own terms.
Your network, your terms.
Under the hood
Rails 8 monolith on PostgreSQL with Hotwire, multi-tenant by row-level scoping — every property, booking, and calendar belongs to a host. Payments run on Stripe Connect: a destination charge collects the guest's payment and routes the host's share to their connected account, and a listing stays unpublishable until its host completes Connect onboarding. Background jobs and caching run on Solid Queue and Solid Cache — Postgres-backed, no Redis to operate. External platform calendars import one-way over iCal.
Decisions
- 01
Availability is enforced by the database, not the app.
A PostgreSQL exclusion constraint on each property's booking date range is the authoritative guard against double-booking — application checks are advisory under concurrency. A check-then-act across two statements is a race, always.
- 02
Payouts gate publishing.
A listing can't go live until its host finishes Stripe Connect onboarding — you can't accept a booking you have no way to pay out. The gate lives in the model, not the UI.
- 03
Fail closed on external calendar sync.
An HTTP 200 with a garbage body is not a valid calendar. An unparseable feed keeps the last-known-good blocks and records a sync failure — never wipes local state. Only a valid calendar with zero events clears.