Nurx · 2020 – 2023
Making a new service line a one-month problem
Cut the time to launch a new telehealth service line from three or four months to under one — then grew the team that used it from three engineers to eleven.
Sanitized- 3–4mo → <1mo
- to launch a service line
- 4
- service lines in one year
- 3 → 11
- engineers on the team
The situation
A service line is everything needed to treat one condition over telehealth: an intake questionnaire, a clinical review workflow, prescribing rules, pharmacy routing, subscriptions and refills. Each new one was being built close to from scratch.
Every line looked similar enough to feel like duplicated effort and different enough that nobody trusted a shared abstraction. So the duplication kept winning, and three or four months per line was the accepted price.
The constraints
- Telehealth is regulated per state, and what a clinician may prescribe varies by state and by condition. That variation is real and cannot be abstracted away.
- Clinical safety sets a hard floor. A wrong shared default in a prescribing rule is not a bug report, it is a patient harm.
- The team was three engineers at the start, so whatever we built had to be usable by people who had not built it.
The call
Separate the parts that are genuinely common from the parts that only look common. Intake → clinical review → prescribe → fulfil is the same shape everywhere; the questions asked, the rules applied, and what counts as a red flag are not.
Make the workflow configurable and leave the clinical specifics explicit per line. The tempting move is to abstract the clinical logic too, because it is the most repetitive-looking part. That is the one place where a shared default is dangerous rather than convenient — so it stayed written out, per line, readable.
As the team grew, spend the structure on boundaries rather than process: OKRs so people could tell whether their work mattered, and clear ownership so a new engineer could ship a service line without a tour of the whole system.
What happened
Four new service lines launched in a single year, each in under a month instead of three or four.
The team grew from three engineers to between eight and eleven, and delivery got more predictable as it grew rather than less.
What I'd do differently
I let the configuration surface grow for too long before pruning it. Every line that did not quite fit added an option, and options are cheap to add and expensive to remove — by the end there were settings nobody could explain the original reason for. I would schedule the pruning rather than waiting for it to hurt.