Guest- and marketing-facing software. Programme deliverables, guest companion, and acquisition tools, sitting alongside the operational stack story below.
The hotel needs a small product layer alongside the operational stack. Three products, each playing a different role in the funnel and the guest relationship. FITVO sits at the top of the funnel as a free fitness app the hotel uses as a soft marketing surface. The sleep report sits inside the programme as a substantiating deliverable, generated automatically from the Eight Sleep data collected across the stay. The companion app sits in the guest's hand from the moment they book through to long after they leave — itinerary and push reminders during the stay, wayfinding, results delivery, and at Phase 03 the addition of a Medilab-partnered post-stay layer that keeps the bloodwork, the retest schedules, and the ongoing nutrition guidance alive in one place rather than two.
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, built in partnership with Medilab, 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, Styku body composition images, 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 Week 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 the operational booking system. 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, assuming the operational booking system exposes the schedule and reservation data cleanly (which the Phase 1 SaaS replacement build below would do natively). 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 is sequenced behind the operational stack's booking module so the app has something to read from; the practical sequence is operational booking module ships first, the companion app builds against it across the following two to three months, both go live at Phase 02 opening. The two-week paid trial pattern proposed elsewhere on this page applies here cleanly to validate developer fit. If the operational stack story is deferred and the bespoke booking module is not built, the cost shifts materially upward — the app then needs to integrate against whatever SaaS booking systems are kept (each with its own API, some without one), and a realistic range becomes £28,000–£36,000 with some recurring integration maintenance whenever a vendor changes their API.
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 and Styku 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.
The Medilab partnership shape. The intended structure for the Phase 03 extension is a partnership with Medilab — already the hotel's bloodwork provider through their four-tier panel offering and an established regulated lab in Jersey. Medilab brings the clinical credentials, the regulatory framework that the post-stay clinical surface needs to sit inside, and the existing patient-data infrastructure that already handles bloodwork results securely. The hotel brings the guest data flow (programme participants are already Medilab patients via the bloodwork tiers), the in-stay product surface that the Phase 03 extension layers onto, and the ongoing relationship that turns episodic test results into a continuous companion. The partnership terms are still to be agreed; the working assumption is that the regulatory burden — what defines the product as informational versus medical advice, and what the appropriate UK MHRA / FDA-equivalent posture looks like — sits on Medilab's side of the partnership rather than the hotel's. That is the single most important practical reason to do the post-stay extension as a partnership rather than a hotel-led build, and it materially de-risks the product compared to the hotel attempting it alone.
Open questions, honestly. Three things remain to be defined for the Phase 03 extension. First — the commercial structure of the partnership. Three plausible shapes: hotel pays Medilab to build with Medilab owning the IP (lowest hotel exposure, lowest upside); hotel and Medilab co-build and co-own with shared capex by skill contribution (medium exposure, shared upside); Medilab builds and owns, hotel licenses access for guests (lowest hotel capex, no IP upside). The right shape depends partly on Medilab's appetite — whether they see this as a Medilab product with the hotel as a launch customer, or as a genuinely shared venture. Second — the 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 clinical-content, retest-scheduling, longitudinal-data and regulatory-wrapper scope — £50,000–£90,000 at full Phase 03 build cost, including contingency. How that is split between the partners depends on the structure agreed; a hotel-pays-Medilab-builds shape puts the full figure on the hotel side, a co-build shape splits it by skill contribution, and a Medilab-led shape puts most of it on Medilab. Third — the data ownership question. Whose system of record holds the guest's bloodwork in five years? The cleanest answer for the guest is "one place, that I trust" — and Medilab's existing patient-data infrastructure is the natural home, with the companion app as the guest-facing surface on top.
Recommended treatment. Phase 02 ships the in-stay MVP as a committed hotel-built product on the timeline above. Phase 02 also runs the partnership-definition workstream alongside the build — six to twelve months of negotiating and contractualising the Phase 03 extension terms with Medilab (commercial structure, build allocation, IP ownership, data architecture, the regulatory wrapper). Once those are agreed, the Phase 03 build itself can proceed with the regulatory and clinical-sign-off costs sitting where they should — on the regulated party. The in-stay MVP and the FITVO refurbishment, alongside the sleep-report build, are the three committed Phase 02 product spends; the Phase 03 Medilab extension is committed once the partnership shape is defined.
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. Resist scope expansion until the core has been live for at least one full season. The app's quality is judged on whether the guest never misses a session, always knows where they're going, and continues to find their bloodwork useful six months after they leave — not on feature breadth.
