01 / Confidential client · US · 2022-2026
Prototype to platform, without stopping the business
From a JotForm prototype to a four-app telehealth platform processing 85,000+ orders a year.
- Role
- Founding Engineer
- Timeline
- 4 years
- Type
- Telehealth & e-prescription platform
- Stack
- Laravel · Vue 3 · Inertia.js · TypeScript · MySQL · Redis · AWS · Stripe · Docker
At a glance
- First engineer on a telehealth platform: built the entire foundation solo for 1.5 years, then scaled it with a team of four.
- 85,000+ orders and 76,000+ new patient registrations in 2025; peak month of 12,324 orders.
- Four Laravel/Vue codebases over one shared MySQL schema, ~246 migrations, strict ownership rules.
- Automated prescription routing to two telemedicine networks and a pharmacy system; identity verification integrated with no sandbox environment.
01 / Context
A medical business running on a form builder
When I joined in June 2022, the medical platform sold emergency antibiotic kits through a checkout flow held together by JotForm and a handful of PHP scripts. It worked, barely. Orders arrived, but every medical intake, prescription, and pharmacy handoff was manual. Bugs were hard to trace because there was nothing to trace them with: no logging, no structure, no source of truth beyond an inbox.
The business was growing anyway. That's the founding-engineer setup in one sentence: the product had outrun its plumbing, and my job was to replace the plumbing while the water was running.
02 / Constraints
Live patients, solo engineer, no sandbox
- No downtime. Real patients were mid-encounter every day. The rebuild had to happen around a live business, not instead of one.
- One developer. For the first year and a half I was the entire engineering team. Architecture, code, AWS, deploys, and support.
- Protected health information. Medical histories, allergies, identity documents. Data handling had to be conservative by default.
- Production-only partners. The identity-verification vendor had no sandbox. Every integration test was a live API call.
- A moving target. One encounter type became seventeen: pediatric, travel, chronic care, each with its own intake logic and medication rules.
03 / Architecture
Four codebases, one schema, strict ownership
I split the platform into four projects along audience lines: a central REST API (central-api), the patient encounter portal (case), a pure-SPA patient dashboard (portal), and an internal operations dashboard (admin). They share one MySQL database, a deliberate choice, not an accident.
A shared schema across four codebases collapses without discipline, so it got one hard rule: only the admin project defines migrations. Roughly 246 of them by the end. The other three projects consume the schema; they never mutate it. That single convention prevented the classic multi-repo failure where two projects each "fix" the same table in different directions.
The encounter portal routes by subdomain. Each of the 17 clinical encounter types lives on its own subdomain with shared intake machinery underneath. Adding encounter type number twelve was configuration plus its specific medical rules, not a fork of the codebase.
04 / The patient journey
From Shopify click to pharmacy shelf
The product feels simple from outside: pick a kit, answer medical questions, a physician reviews, a pharmacy ships. Under it sits a pipeline where five external systems have to agree with each other.
The step I'm proudest of is invisible: during intake, a dynamic allergy-substitution engine reads the patient's reported allergies against staff-configurable contraindication rules and rewrites the medication list in real time, removing what's unsafe and substituting approved alternatives. Before it, allergy handling was a human reading a form. After it, clinical staff maintain the rules themselves; no deploy required for a new allergy-to-medication mapping.
Downstream, prescription handling became a set of Artisan commands (CreateBelugaVisit, CreateMdiCase, SubmitCaseOrder) that route completed orders to the right telemedicine network and on to the pharmacy. What used to be a person copying data between dashboards became an audited, retryable pipeline. Order status then syncs back to Shopify, so the store the customer bought from always tells them the truth about where their kit is.
05 / The hard parts
Three problems worth telling in an interview
Integrating identity verification with no sandbox
Vouched, a license upload and selfie matching service, offered no test environment. Every development iteration ran against production. The discipline that made this survivable: exhaustive structured logging around every call before writing the integration, idempotent retry paths, and treating every response shape as untrusted until proven. Slower to start, but when something failed at 2 a.m., the logs already knew why.
Rebuilding the foundation under a live product
The JotForm-to-Laravel migration ran as a parallel-tracks operation: new encounter flows launched on the new stack while existing ones kept running on the old one, with the shared database as the meeting point. No big-bang cutover, no downtime, just a shrinking legacy surface until there was nothing left to shrink.
Keeping four codebases honest against one schema
Beyond the migration-ownership rule, the API had to stay the single gateway for anything external: Stripe, Twilio, Vouched, the telemedicine networks, Shopify, Zendesk, Klaviyo. Integrations leak into every corner of a codebase if you let them; concentrating them in the central API kept the other three projects boring, which is exactly what patient-facing medical software should be.
06 / Tradeoffs
What I'd defend, and what I'd change
Shared database over service boundaries: defend. Four projects, one schema, one engineer. Microservices would have traded my biggest advantage (total context) for operational overhead nobody was staffed to carry.
Speed over test coverage: change. The founding phase prioritized shipping; automated tests stayed thin, and the cost showed up later as careful manual regression passes. My personal projects since (screen.io, 243 tests in two weeks) are partly me building the habit the client work never budgeted for.
Conventions after the team, not before: change. When the team grew from one to four, code style and process friction appeared exactly where no written conventions existed. Next time the conventions document exists on day one, even with one person.
- orders processed in 2025
- peak orders in one month
- clinical encounter types
- codebases, one shared schema
07 / Results
A platform a team could inherit
By 2025 the platform processed 85,000+ orders and registered 76,000+ new patients in a year, peaking at 12,324 orders in a single February. Seventeen encounter types ran on shared machinery. The prescription pipeline that had been a person was a process.
The result I actually measure is different: when the engineering team grew to four, they onboarded into the architecture rather than around it. A senior developer took over ticket management. I kept shipping features and mentoring one of the newer developers. The system I built alone stopped needing me specifically. That is the measure of building it right.
08 / Lessons
What four years here taught me
- When a partner API has no sandbox, logging is the integration itself, not observability. Build it first.
- Multi-project systems survive on ownership rules, not goodwill. One project owns the schema. Period.
- Founding-engineer speed is a loan. The prototype era was expensive to escape; a structured start would have cost weeks and saved months.
- Write the conventions before the team exists. The cheapest time to agree is when there's nobody to disagree with.