In development · Product vision & interface design
CheckInn
One system for every stay, every property, and the work that connects them.
CheckInn is designed for owner-operators and small property-management teams to manage availability, reservations, guests, pricing, readiness, housekeeping, maintenance, and channel connections from one property to a growing portfolio.
Illustrative target-state interface composition—not a live customer account.
7core operating surfaces
1–5unit starting audience
3connectivity levels
1isolated operational database
0required HAVEN dependencies
Target product model—not production usage.
01 · The Product
A front door for the entire stay—not another channel dashboard.
Independent owners and small property teams often grow into a patchwork: one calendar for direct stays, separate Airbnb and Vrbo views, guest details in messages, cleaning notes in texts, and accounting in another system entirely.
CheckInn is the shared operational picture across that work. It gives the team one place to understand what is happening, what is ready, what is blocked, and what needs attention, without forcing a one-property operator into enterprise software.
Product question
What would property operations look like if every stay, task, and handoff lived in the same system, instead of five?
01
See the day
Arrivals, departures, readiness, exceptions, and upcoming work resolve into one legible operating picture.
02
Stay in context
Calendar, guest, reservation, and unit details open beside the work instead of sending the operator through disconnected screens.
03
Grow without a reset
The same mental model serves a single owner-managed home, a small portfolio, or a front office connected to specialized systems.
02 · The Stay Lifecycle
One continuous operating model from open night to ready home.
Each team sees the same stay from the perspective of the work they own.
01PlanAvailability, pricing, and restrictions
02PublishDirect inventory and approved channels
03ReserveGuest, stay, economics, and source
04PrepareReadiness, access, and housekeeping
05HostArrival, in-stay needs, and service
06TurnDeparture, inspection, and reset
The Operating Surface
Seven workspaces, one shared property model.
Every surface answers a different operational question while preserving the same units, dates, roles, and source lineage.
01
Today
Priorities, arrivals, departures, readiness, and exceptions.
02
Calendar
Wide unit-night planning across direct and connected inventory.
03
Reservations
The complete stay record, source, economics, and lifecycle.
04
Guests
Minimum necessary identity, communication, and stay context.
05
Arrivals
Readiness, access, handoffs, and day-of-arrival confidence.
06
Housekeeping
Turns, inspections, supplies, issues, and team ownership.
07
Operations
Maintenance, tasks, exceptions, and portfolio-level control.
03 · Channel Adoption
Useful before certification, extensible after approval.
Connectivity is designed as a graduated path so a property can begin simply without locking the product to one provider.
Level 01
Native portfolio
Direct inventory, reservations, units, guests, and daily operations are designed to live in CheckInn’s own operational model.
Level 02
Calendar interoperability
Availability-only calendar feeds are designed to provide a bounded bridge for sources that do not yet expose an approved native connection.
Level 03
Approved provider adapters
Airbnb, Vrbo, and future channels will connect through versioned adapters when official partner access and certification are available.
AirbnbVrboDirect
→CheckInn→
HAVENMessagingReporting
Integration boundaryAirbnb and Vrbo connections depend on approved provider access. HAVEN is an optional accounting consumer behind a versioned API seam; its database and CheckInn’s database remain entirely separate.
04 · Architecture
A provider-neutral core between channel activity and daily work.
The product is designed to own operational truth while every external system remains an explicit, replaceable connection.
A Next.js and TypeScript interface designed for the front desk, the owner’s laptop, and the phone used during a property turn.
Contracts
One explicit web-to-API seam
Versioned OpenAPI contracts are intended to keep interface behavior, authorization, errors, and provider adapters understandable as the product grows.
Operational data
A database with one job
PostgreSQL is intended to hold CheckInn’s property, stay, inventory, guest, and operations model without sharing tables or identifiers with HAVEN.
Integrations
Adapters around a stable core
Channel, accounting, messaging, and payment providers are designed to connect at controlled boundaries instead of defining the internal product model.
05 · Trust & Quality
A simple interface with serious operational boundaries.
Simple does not mean ambiguous authority, hidden automation, or loose handling of guest information.
Tenant boundary
Every portfolio stays scoped.
Organization and unit access are enforced before operational rows, counts, or identifiers are composed.
Minimum detail
Guest data appears only where needed.
Calendar and daily-operation surfaces expose the least information required for the work at hand.
Explicit state
Availability is never invented.
Freshness, source, hold, block, and reservation states stay visible, so uncertainty cannot masquerade as a confirmed night.
Safe connections
External systems stay outside the core.
Provider failures, retries, and approvals stay isolated from local operational commitments, and are recorded through auditable seams.
Role-scoped accessIdempotent commandsSource lineageSeparate databasesTested against real workflows
06 · Reflection
A small operator should not need a small idea of what software can be.
CheckInn is the product expression of a simple belief: the systems around a stay should feel coherent to the people doing the work. A beautiful calendar matters, but only because it can become the shared language between reservations, guests, readiness, housekeeping, maintenance, and the financial systems downstream.
The architecture is intentionally portable. CheckInn can stand alone for a single owner, coordinate a small portfolio, or sit beside specialized systems without collapsing their responsibilities into one database.