On-Demand Therapy Platform — Three-Audience Landing Layer

An on-demand therapy platform needed a public face for three different audiences: the patient looking for a session tonight, the practitioner deciding whether to take the platform seriously, and the corporate HR buyer evaluating it as a staff benefit. Three landing pages, three different arguments, one product behind all of them.

Agency work at Spaceapps. The client relationship belonged to the agency and I delivered as staff, joining after the product design was already finished. The app itself — its screens, its role surfaces, and the discovery that produced them — is the tech lead's work. My stage was the landing layer, and this case study is about that layer only.

Three audiences, three arguments

The temptation on a project like this is one landing page with three tabs. It does not work, because the three readers do not share a question. A patient wants to know how fast someone can talk to them and whether it will be someone real. A practitioner wants to know about caseload, payment and whether the platform will compete with their own practice. An HR buyer wants coverage, reporting and a number they can defend in a budget meeting. Those are not three tones of one page; they are three pages.

👥3

audience landing pages

📐3

built breakpoints — 1440, 1280, 375

🖼️6

designed page states — at 1280 and 375

🔁2

builds — Vite, then Next.js

• Patient — the shortest path from arriving to talking to someone, with the reassurance load carried by the page rather than by a form.
• Practitioner — the supply side, which is a recruitment page pretending to be a marketing page and has to answer money and autonomy before anything else.
• Corporate HR — the buyer who is not the user, evaluating on behalf of staff who will never see this page.

Wireframed, designed, then built by the same person

Each page went wireframe first, then design, then code: six designed states across three audiences, at 1280 and 375, and then a built layer that reflows across 1440, 1280 and 375. This is the strongest responsive evidence in my portfolio and it is worth being precise about why: not because three breakpoints is a large number, but because the same person carried every one of them from wireframe through to shipped markup, so there is no handoff at which the responsive intent could have been lost.

Built twice: Vite, then Next.js

The landing layer was first built in Vite with React Router, then migrated to Next.js in August 2025. Both repositories are still public, and I keep both deliberately — the pair is the only honest record of what the migration actually changed. It is also the thing most often stated wrongly about this project: the earlier repository is Vite, not Next.js, and a tooling scan that reports otherwise has been fooled by a theming package whose name begins with the same four letters.

The file that proved a claim by not containing anything

There is a design-file detail here that matters more than it looks. Across the agency's projects I had propagated a heavily tokenised starter file, and the obvious question about any such claim is whether the file follows the person or the employer. This project is the control: it is the one project of that era whose product I did not design, and it is the one file with no starter file in it — a handful of variables, no colour variables, none of the primitive layers the others all carry. The file tracks me, not the agency. An absence is doing the evidentiary work.

What this is not

• Not the product. The application, its screens and its role model are another designer's work, and I will not claim any of them.
• Not the mobile apps. The product shipped to both app stores under the agency's bundle identifier; those listings are proof that the system went live, and they are evidence about the agency, not about me.
• Not the discovery. The tech lead ran it on every project of that era and handed me the board.
• Not the agency's delivery process. Fifteen phases were theirs; I executed one stage inside them.
• Not a completion claim from the project schedule. The snapshot in the design file is a mid-project view and cannot be cited as a status.
• Not evidence that I shipped the system. My shipped artifact is the landing-page layer — that exact sentence, and no shorter one.
• Not my client. The relationship was the agency's; I delivered as staff.

Durability

For most of this project's life there was no snapshot of it anywhere. That is a real risk for a portfolio built on client work: the domain lapses, the host changes hands, and the evidence for a year of your work disappears without anyone doing anything wrong. In August 2026 I submitted the site to the Wayback Machine and confirmed, by reading the archive index rather than trusting the save, that all six routes were captured — including all three audience pages, which is what makes the three-audience claim survive the domain.

Evidence

The three pages were wireframed, designed at 1280 and 375, built in Vite, migrated to Next.js and shipped. They are still serving at the project's domain, which I host today — I took the hosting over in 2026, roughly ten months after the build ended, for reasons that have nothing to do with the engagement, and serving the files now says nothing about what I was hired to do then. In August 2026 all six routes were captured by the Wayback Machine, so the work no longer depends on the domain surviving. No performance metric exists for this project, or for any project in this portfolio; that is a confirmed absence rather than an uncollected one.