Resources · Delivery Planning

Delivery Timeline & Staffing Model

A deliberately conservative, staffing-aware delivery plan for REV.health. The Gantt below schedules every module with generous estimates that already include testing, then re-computes the whole plan when you change how many senior developers work on it and when they join. It bakes in two truths most plans ignore: adding people does not speed things up linearly (communication overhead is real), and the further out you forecast, the wider the error bars get.

Read this first — the benchmark If a single senior developer can ship a viable P1 product in about a year, that is an excellent outcome that exceeds reasonable expectations for a platform this broad. The numbers here are intentionally generous so that the plan ages well. Treat earlier dates as upside, not the commitment.

Staffing controls

Senior developers Target headcount on the build.

When they're added New hires ramp up (reduced output for their first month).

Communication overhead How fast coordination cost grows per added person.

Estimate confidence Near-term error; it widens the further out we look.

Gantt — phased delivery

The timeline starts May 1, 2026. Only the competitive analysis is finished (~2.5 weeks); the PRD, architecture spike, security review, and the JIG prototype are still in progress (lighter bars). P1 is the pencil-and-paper core — schedule a patient, document the visit, code it, bill it, get paid — with conveniences (ambient scribe, portal, eligibility, full eRx) deferred to later phases. Everything to the right of the red today line is forecast. Each module also carries a faint ongoing-touches line (we keep working every section a little all the time) and thin links show the connective tissue between dependent modules. Hatched tails are the margin-of-error window; they widen as the schedule extends.

Done (competitive analysis) In progress P1 — Run the clinic, get paid P2 — Conveniences & automation P3 — Full platform Ongoing touches Dependency link Margin of error Single dev — no independent QA Today

Why the math is not linear

Two developers are not twice as fast. Three are not three times. Every person you add creates communication links with everyone already there (n×(n−1)÷2 of them). That coordination tax means effective output scales sub-linearly. A new hire also needs roughly a month to reach full speed. And no single module can usefully absorb more than about two senior developers at once — past that they trip over each other. The model caps per-task parallelism and applies a communication-overhead discount, so the Gantt shows realistic compression, not fantasy speed-ups.

Margin of error grows with distance

The PRD is detailed, but a PRD is not running code. Each module still carries real uncertainty — integration surprises, payer quirks, certification feedback, scope discovery. Near-term work is estimated tightly; work that lands a year or two out inherits a much wider band. That is why each bar has a hatched tail and each phase milestone is shown as a range, not a single date. This is the “cone of uncertainty”: it is honest to widen it the further out we forecast.

Per-module estimates (generous, testing included)

Estimates are in engineer-weeks for one senior developer and bundle design, build, automated + manual testing, and code review. The two regulatory long poles — EPCS (DEA) and ONC HTI-1 certification — are largely calendar-bound and do not compress with extra headcount.

Assumptions & method

Timeline epoch is May 1, 2026; “today” is June 4, 2026. Only the competitive analysis (~2.5 weeks) is complete; the PRD, architecture spike, security review, and JIG prototype are in progress.
Estimates are solo senior-dev engineer-weeks, testing included, then scheduled against effective capacity.
Effective capacity = (sum of each developer's ramped output) ÷ (1 + k × (headcount − 1)), where k is the communication-overhead setting.
A new hire contributes 40% in weeks 1–2 and 70% in weeks 3–4 before reaching full output.
No single task absorbs more than 2 senior developers concurrently.
Modules depend on the platform core (AMI runtime, auth, audit, FHIR store) landing first; phases are scheduled in priority order P1 → P2 → P3, with spare capacity spilling forward.
Margin of error starts at the selected near-term value and grows ~0.75 percentage points per week, capped at ±60%.
This page is a planning aid, not a financial commitment or a contract.

Sub-page

Original Gantt roadmap

The earlier static delivery roadmap — Mermaid Gantt diagrams for platform phases, per-module delivery, regulatory deadlines, and integration readiness.

View the original Mermaid Gantt roadmap →