Wellness Hub Recovery is a recovery-focused wellness platform. I built the MVP during 2020, the year remote-first care delivery became urgent for everyone in this space. Clients needed to engage with the practice from home; the practice needed to maintain continuity with people whose lives had been disrupted.
I shipped the MVP solo end-to-end. The web (React) and native mobile (React Native) clients sat on an AWS backend I designed and deployed myself: DynamoDB for storage, AppSync for the realtime data layer, Lambda + API Gateway for the rest. The constraint that shaped every screen was respect for the user. Recovery clients are not a market to be optimized; they're people in a vulnerable phase, and the software has to be careful with attention, with notifications, with the language of every interaction.
Solo end-to-end on a one-person team
A one-person team means owning every part of the engagement, not just the engineering:
- Discovery and requirements gathering directly with the founder. Translating "we need a recovery wellness platform" into a concrete scope across two clients, an EMR layer, and an AWS backend. No PM, no spec doc handed down. The requirements came out of working sessions with the customer.
- Surfacing tradeoffs back to the customer in plain language. When a request would blow the timeline or the budget, the conversation about which version was actually worth shipping was mine to drive.
- Owning the architecture decisions that don't get revisited. DynamoDB vs. Postgres, AppSync vs. polling, where the boundary between web and mobile lived, what the EMR data model would have to support a year out.
This is the same shape product-engineer roles at AI-applied teams ask for: sit close to a customer's problem, do the discovery work, decide the right tool for the job, ship something that holds up, alone if you have to.
A wellness program that spans mobile and web
Clients did their wellness check-ins on the native mobile app: structured prompts about how they were doing, what they were experiencing, what was helping. That data flowed into the provider portal on the web app, where clinicians saw each client's history rendered as graphs and charts. A clinician could open a client's record and see the trajectory at a glance instead of paging through individual entries.
The two surfaces are halves of the same thing: the mobile app is what clients touched, the web app is what the people supporting them touched, and the data layer connecting them is what made the platform useful as a recovery tool rather than a logging app.
EMR intake: robust digital forms
Onboarding a recovery client into the system required a substantial amount of structured data. I built the EMR intake layer with:
- Many distinct intake questions and data points across the onboarding flow, structured so the form could grow as the practice added new questions without a rebuild.
- Advanced form behavior (conditional fields, validation, progressive disclosure, save-and-resume). The affordances a long intake needs to feel manageable rather than punishing for a vulnerable client.
Digital signatures for insurance billing
Insurance companies require signed documentation for billing. I built a digital signature feature into the platform so the practice could capture client signatures during onboarding without printing, scanning, or routing paper.
The integration is the part that matters: signed artifacts had to attach to the right place in the client record with the right metadata so billing actually cleared. The signature itself is a solved problem; the place it lives in the EMR is the work that makes it useful.
The trade-offs
Building a clinical-adjacent platform end-to-end as a solo freelance engineer means early architecture decisions stick, both on the frontend surfaces and on the AWS infrastructure underneath. The startup ultimately didn't continue past the MVP, but the platform shipped (clinician portal, client portal, native mobile, EMR intake, insurance signatures, the AWS backend tying them together) at the scope and quality the practice would have needed if they had continued. The job was to ship something honest enough to operate on, fast enough to matter while remote-first care was still finding its shape.