The trust comes first. Then the door opens.
This is a working prototype of Oka — not a slide deck and not a set of screens. Pods, membership, credits, a credit-backed stay, the host’s human decision, the gift nudge, mutual reviews, Circles and the admin back office all run on one shared state model, with real transitions you can click through in about ten minutes.
Liran — everything below is clickable. Open the app, press Prototype demo in the bottom-right corner, and walk the seven chapters in order; or jump straight to any moment from the links on this page. You will also find yourself in the community — a member of the family with a room in Tel Aviv.
Each chapter is a deep link. The presenter can open any one of them directly, in any order.
Seven chapters, one continuous state
Nothing here is a static mock-up. Enrolling in a Pod really changes what the account can do; a booking request really moves credits from available into locked; the host’s decision really settles them at check-in. Reset the demo at any point and the world returns to its starting state.
Trust before access
A free member can read the whole family — people, homes, Pods — but booking and messaging stay closed, and the gate explains why instead of selling.
Pod as the gateway
Three sessions, four to eight people, $500. Safe simulated checkout, then an admin marks the Pod complete and the $999/yr membership — $0 with the 2026 coupon — brings the first three credits.
A credit-backed stay
Identity check, calendar with a two-day notice rule, transparent credit math, and a request that locks three of five credits the moment it is sent.
A human host decision
Switch to Elena. She reads Maya’s Pod, verification, intentions and gift offering, asks a question, and presses Welcome Maya — not Approve.
From transaction to relationship
The gift nudge, a real conversation, host settlement at check-in, checkout, and reviews that stay hidden until both sides answer — or open on their own after fourteen days.
Community between stays
Circles you can join and leave, posts and threaded replies that land in the feed, 1:1 skill sessions, and a workshop proposal that enters the approval queue.
Operational depth
Pods, approvals, member drawer, a credit adjustment that refuses to proceed without a reason, support escalations, moderation, and an audit trail that records all of it.
The hard moments, one click away — no need to replay the happy path first.
The states most demos skip
A product is judged by what it does when things go wrong. Each of these is a live state with its own copy, its own arithmetic and its own way out.
Every number on screen comes from one ledger. Change it anywhere and it changes everywhere.
Credits are explainable, not abstract
The wallet separates available, locked and lifetime earned, and every movement writes a ledger line with a reason attached. These are the rules the prototype actually enforces.
Switching role changes permissions, tasks and navigation — not just the name in the corner.
Four people, four products
Reading the family
Browse people, homes and Pods. Booking, messaging and offerings are closed, and the sidebar carries an access state instead of a balance.
Maya Chen
Credits, identity verification, the calendar, the request, the gift note and the review. Lisbon, 44, founder and somatic coach.
Elena Márquez
The request queue, the guest’s trust profile, a question before the answer, settlement at check-in and her own listing in My Offerings.
Operations
A denser environment in the same design system: Pods, approvals, members, credit adjustments, escalations, moderation and the audit trail.
What runs for real in this build, and what is deliberately simulated.
What is real here, and what is not
A prototype that pretends to be production is worse than useless in a build conversation. Here is the exact line.
Really running
- A single state model behind every screen — role, timeline, credits, bookings, threads, ledger and audit trail
- Persistence in local storage, so a walkthrough survives a reload, plus a full reset
- Deep links to every chapter and edge state, so a presentation never depends on the previous click
- Loading, empty, gated, success, validation and failure states on the main path
- Responsive from 1440×900 to 390×844, with no horizontal overflow and 44px touch targets
- Keyboard focus, ARIA labels,
prefers-reduced-motion, and modals that return focus on close - Every photograph and script served from this origin — the demo does not depend on any third party
Deliberately simulated
- Payments. Both checkouts are marked as prototype surfaces. No Stripe call is made and no card data leaves the page
- Identity. The Stripe Identity flow is imitated end to end, including the failure and retry path. No document is ever requested or sent
- Map. A stylised world map with real coordinates rather than a Google Places bill
- Email and push. Represented in-app through the notification bell
- People. A consistent, seeded demo world — no real member data anywhere
- Assumptions we flagged rather than invented: the exact moment credits are granted, the definition of a complete profile, and coupon eligibility are shown as demo behaviour, not as settled rules
How this build is put together, and where it goes from here.
Built to become the real thing
The prototype is one declarative component tree over one state class, served by a small Node application. That is a deliberate choice: the same component and state boundaries survive the move to a real backend and, later, to React Native.
This deployment
- Node and Express behind a CDN-free origin, gzip on, cache headers split between immutable assets and revalidated pages
- Three surfaces: the overview, /app for the product, /mobile for the same product in a device frame
- React runtime and all 43 photographs hosted locally; nothing on the demo path calls out to the internet
- A build step that compiles the product template into the page shell, and a Playwright pass that walks the whole demo path checking for console errors, failed requests and layout overflow
The production path
- API and database behind the same entity model: members, pods, listings, bookings, credits, offerings, circles, threads, audit
- Stripe for Pod fees and membership, Stripe Identity for verification, both already shaped in the UI
- Transactional email and push against the notification events the prototype already emits
- Phase 2 React Native reusing this component and state model — the reason the prototype is structured this way rather than as flat screens
- Admin, moderation and audit are first-class here because they are what makes a trust network operable at scale
Ten minutes in the app will say more than any deck.
Start at chapter one and let it run. If anything reads differently from how you imagined Oka — the credit timing, the tone of the host’s decision, the shape of the admin queue — that difference is exactly the conversation worth having next.