Guest-facing products, and an Apaleo operational stack.

Product 01 · in build for Phase 02

The sleep report.

A personalised sleep report delivered to every programme guest at departure, generated directly from the Orion data collected across their stay — heart-rate variability, sleep stages, breathing rate, snoring, all measured contact-free from sensors woven into the cover. Guests who already wear an Oura ring, an Apple Watch, a Garmin, a WHOOP or a Fitbit can connect it before arrival via the Terra health-data platform; their day-time activity and habitual baseline then merges into the report alongside the on-property nights. Guests who don't track themselves still get a complete report from the Orion alone.

The product matters because it is auto-generated rather than hand-written. Every programme guest receives a report of the same quality, regardless of Health Coach availability that week. Weekend guests get a two-night report; Pause guests a five-night report; Week and View guests a continuously-updated report across the full stay, reviewed with the Health Coach at each coaching session. Without the auto-generated layer, sleep reporting becomes a Health Coach time-cost that scales linearly with bookings; with it, the marginal report costs nothing to produce.

Build status. Already scoped, costed, and budgeted as a Phase 02 launch capex line at £5,000 for the MVP build. Built on top of Terra as the data integration layer — Terra handles the wearable connectors, our software produces the reporting layer on top. Iterative refinement after launch sits within the operational software team's retainer rather than carrying its own ongoing cost.

Product 02 · existing app, refurbishment in scope

FITVO — the free fitness app.

FITVO (fitvoapp.com) is a built-but-unlaunched fitness app that the family owns. The product is essentially finished — including a library of around 200 exercise videos already produced — but it never went to market. The proposal is to refurbish it and launch it as a free, branded marketing surface for the Long Hotel, keeping the FITVO name and visual identity intact rather than rebranding it as a Long Hotel app. The brand has further commercial opportunities of its own, and folding it into the hotel identity would foreclose those rather than add to them.

The starting position matters. Because the core build and the content library already exist as sunk costs, the hotel is not funding a fitness app from scratch — it is funding the modernisation needed to ship an asset that's already been paid for. That changes the economics of the decision considerably.

What the refurbishment covers. Three buckets of work. First, package modernisation — removing dependencies that are no longer maintained, upgrading what stays, and re-establishing a current build pipeline. Second, screen-size and form-factor work — adapting layouts for the iPhone 16/17 generation, the larger Pro Max displays, the Dynamic Island, and current Android device variants. Third, design tidy — particularly the icon set, plus a small number of UX changes targeted at reducing friction at the highest-drop-off points (sign-in, first session, recurring engagement). This is refurbishment, not a rebuild.

Marketing role. A free fitness app puts the FITVO brand in front of an audience interested in fitness and wellness — broadly the same demographic the Long Hotel programmes target. The hotel benefits in three ways: brand presence with a relevant audience at no per-impression cost; a soft funnel into the programme proposition through occasional in-app content, links, and seasonal promotion; and a content surface that gives the hotel's content team a place to publish short-form fitness pieces that wouldn't fit elsewhere. None of this depends on FITVO becoming commercially significant in its own right — the marketing effect operates regardless.

Indicative build estimate. Approximately 2–3 developer-months of work at the same effective loaded rate as the operational team below — £2,900 per productive developer-month, totalling £8,000–£12,000 all-in including contingency. Could trend higher if the package debt is severe; the two-week paid trial pattern proposed elsewhere on this page applies cleanly here as a way to validate scope before committing the full budget. Best done by the same remote development team that handles the operational stack, sequenced after the first one or two operational modules ship to confirm the team's productivity. Given that the core product and the 200-video library are already built, the £8,000–£12,000 figure represents the full marginal cost of bringing this asset to market.

Product 03 · Phase 02 in-stay MVP, Phase 03 Medilab extension

The companion app.

One app, downloaded by the guest at booking confirmation, used continuously from then onwards — across the stay, into the post-stay window, and as a long-term home for their health record. The product evolves in two phases. Phase 02 ships the in-stay MVP: itinerary, push notifications, wayfinding, and a results inbox where bloodwork, scans, and the sleep report land as they come through during the stay. Phase 03 extends the same app with the post-stay layer — retest schedules, nutrition and supplement guidance grounded in the actual bloodwork, longitudinal tracking of results across visits, HealthKit and Android-equivalent integration. Same login, same data, same product. The in-stay surface delivers the experience; the post-stay extension keeps the relationship alive.

Phase 02 — in-stay MVP

What ships at Phase 02. Three jobs, all of them practical rather than ambitious. First, the app holds the guest's full personalised itinerary — every consultation, treatment, class, coaching session, meal sitting, and free-time block scheduled across their stay, pulled live from the operational booking system. Second, it sends push notifications a sensible interval before each appointment with the time, the location on the property, and brief directions for getting there from wherever they were last. Third, it acts as the place where their results land — bloodwork as Medilab returns it during the stay, DEXA scans, the in-progress sleep report, any imaging or clinical write-ups generated as the programme runs. The guest leaves with everything in one place rather than scattered across emails, paper printouts, and reception's filing cabinet.

Why this matters operationally. A Long View guest has fifty to seventy scheduled touchpoints across their fourteen-night stay — clinical consultations, Ayurvedic treatments, fitness sessions, coaching, meals, group activities, free blocks. A Long Reset guest has thirty to forty. Without a structured itinerary in their hand, the guest experience is a continuous low-level scramble: paper schedules, reception phone calls to confirm timings, missed sessions, late arrivals, awkward "where am I supposed to be?" interactions with staff. The current Hotel de France experience already runs this way; the Long Hotel programme experience cannot. Push reminders shift the burden of remembering from guest-and-staff to software, and ten or fifteen avoided "I'm sorry, where is the consultation room?" reception phone calls a day across a busy season is a meaningful operational saving.

Why this matters experientially. The companion app is the single most-used piece of software the guest interacts with across their visit. Every appointment they remember on time, every treatment room they find without asking, every result they see arrive in real-time, builds the impression of a programme that is operationally serious — that the property is a place where things are tracked carefully and delivered intentionally rather than improvised. The app is therefore brand-grade rather than utility-grade: the visual identity, the tone of the push notifications, the typography and animation of the itinerary view all matter, because they are the product the guest holds in their hand most often.

Wayfinding, specifically. The Hotel de France site has roughly thirty named spaces a guest might be sent to across a programme — the clinical wing's consultation rooms, the Healthhaus gym and treatment rooms, the spa, the restaurant, the gardens, the Ayurvedic suite, group-class spaces, the lobby and reception. New guests cannot navigate that from memory in the first three days, and the property is large enough that "go through reception, past the bar, second door on the left after the courtyard" doesn't read on a paper schedule. The app carries simple floor plans with each booking — an arrow from the guest's current location to the destination, a brief written direction, and a fallback "tap to call reception" if they get genuinely lost. Not Google Maps; something closer to the way airport apps show you the gate.

The Stay Channel — guest connection within the app

What it is. A private group messaging channel built into the companion app, connecting guests who have overlapping reservations during a shared stay window. Access is provisioned automatically at check-in and revoked at check-out — tied directly to the reservation database, with no separate sign-up or account creation required. Identity within the channel is first name only: no profile photos, no persistent profile pages, no member directory. Guests are not visible in the channel until they choose to post; lurking is the default and the correct default.

How it works in practice. A single channel per stay window, not split by programme type — the intention is cross-pollination between longevity guests, Ayurvedic guests, and general wellness guests rather than siloed groups. Staff post optional activity invitations through lightweight polls: a kitchen herb walk at 10 a.m., three spots on the sunset breathwork session, the morning sea swim group departing at 6:45. The voice is conversational rather than programmatic — "Chef is doing a kitchen herbs walk tomorrow at 10 — three spots open, tap to join" rather than a formal activity listing. Guests can post their own informal invitations with the same ease ("anyone want to do morning yoga?"), which simultaneously reduces social friction for solo guests and gives the team a live read of what the current group wants more of. A pre-arrival post from the hotel lands in the channel the day before the earliest check-in in a given window, so no guest opens the app to an empty channel on day one.

What it deliberately is not. Not a matching algorithm. Not a long-term community platform. Not a profile-based social network. No likes, no reactions, no read receipts, no active-now indicators. No message history persists beyond the stay. No direct messaging between guests — if two people want to continue a conversation privately, they exchange contact details in person. Default notifications are digest-style (one or two summaries per day) to protect signal-to-noise ratio and prevent the channel being muted within 24 hours; real-time alerts are opt-in for activity posts only. The feature exists to reduce the friction of casual in-person encounters during a stay — particularly for solo guests and those on differing schedules — and nothing more. Post-stay community, if it develops, is addressed separately and manually in early stages.

Moderation. A lightweight in-app reporting flow routes to the duty manager. The staff account holds moderator privileges. No elaborate infrastructure is needed given the small, vetted, reservation-authenticated user base — the population is never anonymous.

Build approach. The channel is built natively within the companion app, sharing the same backend as reservation data. Real-time messaging infrastructure is provided via an established third-party service — Stream, Sendbird, or PubNub — embedded into the app. Authentication, identity logic, channel provisioning, and access control are handled by the hotel's own systems and tied directly to the reservation database. This avoids the reconciliation problems of a third-party chat tool while keeping build scope manageable. Guest behaviour and the staff voice are validated during a soft-launch period with early guests before press visits begin. Ongoing messaging-service cost is low — at the volumes this hotel runs, Stream or equivalent sits at approximately £1,000–£2,000 per year — and is absorbed into the operational running cost rather than carrying its own capital line.

Phase 02 build cost and timing. Built as a React Native cross-platform app (iOS and Android from one codebase) with a thin server layer reading from Apaleo's REST API and webhook stream. The MVP scope is itinerary view, push notification engine, simple wayfinding with floor plans, results inbox with PDF and image rendering, basic profile and preferences. At the operational team's effective loaded rate of £2,900 per productive developer-month, the MVP scope — itinerary, push notifications, wayfinding, results inbox, and the Stay Channel with its messaging-service integration — is approximately 4–5 productive developer-months — £15,000–£20,000 all-in including contingency. Apaleo's API is designed exactly for this pattern (guest schedule, reservation events, folio state, all available cleanly), so integration friction on the companion-app side is materially lower than it would be against a legacy PMS. The Stay Channel integration (Stream or equivalent embedded into the app, provisioning tied to the reservation database) adds roughly one developer-month to the base MVP scope but does not require its own capex line beyond that — the ongoing messaging-service subscription (£1,000–£2,000 per year) is an operational rather than capital cost. Timing runs in parallel with the Apaleo + marketplace deployment and the custom layer 3 build described in Story Two below; the practical sequence is Apaleo goes live at the 6-8 week mark, layer 3 builds across the following months, the companion app builds against Apaleo's API from the start, and everything goes live at Phase 02 opening. The two-week paid trial pattern applies here cleanly to validate developer fit.

Phase 03 — Medilab post-stay extension

What Phase 03 adds. The Phase 03 extension layers the post-stay clinical surface onto the existing app. Bloodwork results held alongside DEXA scan data; HealthKit (and the Android equivalents) integration to pull in activity and sleep continuously after the stay; nutrition guidance and supplement recommendations grounded in what the actual bloodwork shows; retest schedules calibrated per marker — ferritin moves over months and warrants different cadence to ApoB or Lp(a). Same app the guest has been using throughout their stay, with new tabs and new functionality enabled when they engage Medilab as their post-stay clinical provider. No second download, no migration of data, no friction at the moment of checkout where retention matters most.

Why combining the two phases in one app matters. Splitting the in-stay and post-stay products into two separate apps would mean two App Store entries, two builds, two sets of push notification certificates, and a moment at checkout where the guest is asked to download a different app to keep using the thing they have been using all week. Every download step loses users, and the post-stay retention case is precisely the moment the proposition can least afford the friction. One app, one login, one data layer, two phases of functionality is the right architecture both for the guest experience and for the partnership conversation with Medilab — one product, one regulatory wrapper, one IP question.

Why the post-stay layer matters strategically. Bloodwork-at-every-tier is the structural credibility anchor of the longevity proposition (see the Market page for context). A guest who returns home with results sitting in a notes app loses most of the value within a few weeks; a guest who returns home with their results inside an app they are already using daily — recommendations attached, retest schedule visible, longitudinal trends accumulating — keeps the proposition's value compounding past the stay. The same logic that drives the Long View's posted three-month follow-up panel applies here at lower clinical complexity: the relationship has to extend past the stay or the proposition is half-delivered.

How Phase 03 works. Phase 03 is a straight extension of the same in-stay MVP built in Phase 02 — same login, same data, same product — with the post-stay layer bolted on: retest reminders, guest-facing surfacing of their own longitudinal bloodwork / DEXA / movement-quality trend across visits, HealthKit and Android Health Connect integration for the wearable side, and a rolling protocol view (nutrition guidance, supplement timing, sleep and training prescriptions) grounded in what the guest actually did in-stay. Built by the same remote development team that ships the operational stack and the Phase 02 in-stay MVP — no third-party build partner needed. Positioned deliberately as an informational tracking and reminder surface, not medical advice — clinical interpretation of results and any protocol adjustments happen through the guest's own GP or through the Sama Clinic Medical Director referral pathway, not through the app. That framing keeps the product outside the MHRA / FDA-equivalent regulated-device tent by design, and is achievable because the app is a record and reminder tool — the medical judgement layer lives in the human clinical relationship, not the software.

Phase 03 build cost. At the same loaded rate (£2,900 per productive developer-month) the Phase 03 extension is roughly 12–20 developer-months for the full scope of retest-scheduling, longitudinal-data surfacing, HealthKit / Android Health Connect integration, notification engine, and the content-rendering layer that pulls in the guest's home-protocol material — £50,000–£90,000 including contingency. Built by the same remote team that ships Phase 02, sequenced after the in-stay MVP has been live long enough to iterate against real guest usage (typically 3–6 months post-Phase 02 launch). The data-ownership question is handled cleanly by the hotel operating the app as system-of-record for what the guest did in-stay, with the guest able to export their own record into their own GP relationship or HealthKit / Health Connect at will — the guest owns their data, the app is the surface that presents it.

Recommended treatment. Phase 02 ships the in-stay MVP as a committed hotel-built product on the timeline above. Phase 03 ships the post-stay extension on the same app, built by the same remote team, 3–6 months after the Phase 02 launch — long enough to iterate the in-stay MVP against real guest usage before building the post-stay layer on top. Both are committed hotel product spends alongside the sleep-report build and the FITVO refurbishment; no third-party build partner and no partnership-definition workstream to sequence against.

Phase 03 — the longitudinal health record as a moat

The compounding-data structural advantage. A guest who books Weekend → Pause → Reset → Reset → View over three-to-five years accumulates something no competitor has ever been able to hold in one place: a longitudinal record of their own biomarkers, movement quality, sleep architecture, body composition, and intervention-response data across every stay. The Phase 03 companion-app extension turns this into a first-class product surface — the guest sees their own trend arcs across visits (VO₂max, DEXA lean mass, HbA1c, HRV, sleep-quality index), the Sama Clinic team reads the same arcs on the clinician side, and every subsequent stay is calibrated against the guest's own historical baseline rather than a generic reference range. This is the mechanism that turns The Long Hotel from a wellness hotel into a longevity practice: the guest's clinical relationship is with the data and the team, not the property.

Why this becomes defensible over time. Competitors can copy any single element of the current offer — the Focus architecture, the Sama Clinic staffing, the aromatherapy ritual, the WiFi + IoT foundation. What they cannot copy is a guest's own three-year data arc held in a single system with continuous clinical interpretation. Every returning guest deepens the moat; guest lifetime value moves from a per-stay calculation to a per-relationship calculation. The right industry analogue is Peloton or Whoop-tier customer LTV, not hotel-tier repeat-guest revenue.

Phase 03 second stage — AI health concierge

What it is. A guest-facing AI conversational surface built into the same companion app, trained on the guest's own accumulated health record (bloodwork, DEXA, sleep, wearable data, Focus programme protocols, clinician notes where the guest has consented to include them). The guest can ask questions about their own numbers ("what's driving my elevated apoB?"), their protocol ("why am I doing zone-2 four times a week?"), or general longevity-medicine reasoning grounded in their own data ("if I stayed on this training block for another 8 weeks, what would you expect to change?"). Trained on the Sama Clinic's own clinical protocols and evidence base so answers reflect the operation's clinical position rather than generic LLM training data.

Deliberately scoped — informational, not medical advice. The AI concierge is positioned as an interpretive layer over the guest's own data, not a clinical decision-support tool. Any protocol change, medication question, or symptom-based conversation is routed to the Sama Clinic clinician team through the existing messaging channel — the AI's job is to help the guest read and reason about their own record, not to replace the clinical relationship. Same regulatory framing as the Phase 03 post-stay extension: the app is a record + interpretation + reminder surface, the medical judgement layer lives in the human clinical relationship. This keeps the product outside the MHRA / FDA-equivalent regulated-device tent by design.

Why this matters commercially. By 2027-2028, every peer-tier operation will have some form of guest-facing AI assistant — the current gap between "no assistant" and "some assistant" will close fast, and the operations that ship a substantive one on top of a guest's own data will hold the differentiator. Building this on top of the longitudinal-record foundation (rather than as a bolt-on) is what makes it useful rather than gimmicky: the AI is worth talking to because it knows the guest's specific case, not because it can regurgitate PubMed. Foundation for the medium-term positioning question of whether The Long Hotel operates as a place guests visit or as an ongoing longevity practice guests belong to.

Phase 03 second-stage build cost. Additional £40,000–£80,000 on top of the Phase 03 post-stay extension. Built by the same remote team, sequenced 6-12 months after the Phase 03 post-stay extension goes live (so the guest data infrastructure is proven and populated before the AI layer is added on top). Ongoing running cost: LLM API calls (via Anthropic Claude or OpenAI enterprise tier, with data-processing agreements in place) at ~£15,000–£30,000/year at planning-stage guest volumes — scales linearly with active-guest count. Total Phase 03 committed product capex including the AI layer: £90,000–£170,000.

What the app deliberately is not. Not a full guest experience platform, not a content surface, not a persistent community platform, not a chat-with-the-clinician channel. The temptation with an app the guest opens fifteen times a day during their stay — and continues opening weekly afterwards — is to load it with adjacent features. The discipline is to keep it focused on the jobs that earn its place: in-stay, schedule and reminders and results; post-stay, bloodwork tracking and retest schedules and grounded recommendations; Phase 03 second-stage, an AI concierge over the guest's own data. Resist scope expansion beyond that until each core stage has been live for at least one full season.