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 invitation 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 invitation 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, multitenant 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, both Postgres backed, with 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. Checking then acting 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. It never wipes local state. Only a valid calendar with zero events clears.