[01]
Two apps, one domain layer
Separate customer and operations deployments share auth, database and UI packages. Fifteen Mongoose models define the domain once.
[CASE STUDY 02]
Volumize Telehealth E-Commerce Platform
A telehealth commerce platform connecting medical intake, clinician approval, prescriptions, payments, despatch and subscriptions across customer and operations apps.
- Role
- Full-Stack Engineer
- Timeline
- Feb 2026 – Present
- Status
- Live
- Stack
- Next.js 16, React 19, TypeScript +10
* ONE ORDER, END TO END
[AT A GLANCE]
- OWNED
- The lifecycle end to end: intake and the RAG recommendation, checkout and subscriptions, despatch, the role-based back office, monitoring and the content admin
- ROLES
- Four in one back office — admin · pharmacist · doctor · marketing
- NOT MINE
- The clinical decision and the dispensing — prescribing is done by the clinicians, fulfilment by a GPhC-registered pharmacy
- PRODUCT
- £19/mo base on 3- and 6-month courses, despatched a cycle ahead
- SURFACES
- A customer app and an operational back office over three shared packages
[STACK]
- Next.js 16
- React 19
- TypeScript
- MongoDB
- Mongoose
- Socket.IO
- Stripe
- Royal Mail API
- AWS S3
- Turborepo
- RAG
- LLM
- Sentry
[01] The problem
Intake and checkout live in different systems
Medical intake, checkout, clinical approval and fulfilment often live in separate tools. That fragments the patient journey, slows prescription handoff and makes payments, subscriptions and refunds difficult to reconcile.
[02] The constraints
What medicine on a schedule rules out
A missed dose is the failure that matters
Treatment continuity made a late renewal more serious than an ordinary delivery delay. It drove early despatch, idempotent retries and monotonic order states.
The AI cannot be the prescriber
AI can summarise intake and suggest a plan, but a clinician must make the prescribing decision. The workflow speeds up review without removing that control.
Enough users that failures are not theoretical
Approvals, despatches and renewals are always in flight. Health checks and error tracking had to surface failures before patients reported them.
[03] The approach
How it was built
I built a customer app and role-based back office over shared auth, data models and UI packages. The subscription lifecycle was designed around treatment continuity rather than billing dates.
[KEY DECISIONS]
- [01]Modelled intake, review, prescription and fulfilment as one explicit order state machine.
- [02]Shared auth, data and UI packages across the customer app and back office.
- [03]Separated customer and staff sessions into distinct trust boundaries.
- [04]Executed refunds against the same Stripe environment as the original charge.
- [05]Integrated Royal Mail label generation and tracking with the order lifecycle.
[04] The trade-offs
Where continuity beat convention
[01]
Despatch the next cycle two weeks before the current one runs out
- Instead of
- Ship on the renewal date, the way a subscription normally works
- What it cost
- More stock stays in transit, and a late cancellation can arrive after despatch.
- What it bought
- Subscribers receive the next cycle before the current supply ends, reducing treatment gaps.
[02]
Retry despatch repeatedly rather than failing to a human
- Instead of
- Fail the job on the first error and raise it for someone to handle
- What it cost
- Retries must be idempotent to avoid duplicating physical orders.
- What it bought
- Transient carrier or pharmacy failures recover without creating a manual backlog.
[03]
The questionnaire recommends, a clinician decides
- Instead of
- Let the pipeline issue the plan directly for a doctor to rubber-stamp
- What it cost
- Throughput remains bounded by clinician review.
- What it bought
- Prescribers receive a reasoned recommendation without surrendering the regulated decision.
[04]
Health-check services and error tracking from the start
- Instead of
- Rely on customer reports and server logs, which is free
- What it cost
- Monitoring adds services and alert thresholds that require maintenance.
- What it bought
- Operational failures surface before they become missed deliveries.
[05] The build
The lifecycle, part by part
[02]
Intake to delivery, as one pipeline
Signup, medical intake, checkout, review, prescription and pharmacy handoff form one stateful pipeline. Royal Mail labels and tracking update the order directly; renewals and refunds are explicit branches.
[03]
A questionnaire that recommends, not just records
A retrieval-augmented pipeline compares intake answers with treatment indications and contraindications, then gives the clinician a suggested plan and reasoning. The prescriber still reviews and decides.
[04]
Four roles, one back office
Admin, pharmacist, doctor and marketing roles share one back office with server-enforced route permissions. Clinical data never depends on hidden interface controls for protection.
[05]
Content the marketing team owns
The marketing team manages blog and campaign content from the same admin without requiring an engineering release.
[06]
Security hardening pass
A phased dependency upgrade cleared every high and moderate finding across 1,127 packages. Query optimisation and edge caching also took 1.8 seconds off page load and 35% off API response time.
[06] The result
What Volumize measured
250+
Live subscriptions
* £19/mo base, 3- and 6-month plans
£31K+
Subscription revenue
* booked across those plans
-45%
Approval turnaround
* review to prescription, vs. manual handoff
-85%
Order despatch time
* after Royal Mail label + tracking sync
4
Back-office roles
* admin · pharmacist · doctor · marketing
[HOW THESE WERE MEASURED]
Subscriptions and revenue are booked platform figures. The −45% compares clinician review with reasoned recommendations against raw intake; the −85% compares integrated Royal Mail despatch with manual labels and tracking. Both are before-and-after averages on the same flow, not controlled experiments, and not a guarantee for any single order.
[07] What I’d do differently
Honestly
The dependency cleanup was reactive after 34 findings accumulated. I would enforce audit thresholds in CI so the graph cannot drift that far again.
Need something like this built?
Next case study [03]
Golegal
AI Legal Workspace
Read the case study →
