Skip to content

The Launch Path

Every Fanzoo engagement starts here. Two weeks, fixed price, and a set of decisions and documents your build can execute against without ambiguity. The output is not a prototype. It is the foundation a platform gets built on.

Measure twice, cut once.

Why This Exists

Most healthcare builds go wrong before any code is written. The EHR gets chosen for the wrong reasons. The billing model does not match the payment provider. A workflow nobody documented turns out to drive half the architecture. By the time those surfaces, they are expensive.

The Launch Path is two weeks spent resolving those questions deliberately, while they are still cheap to answer.

What You Get

Vendor selection report

A structured evaluation and recommendation for every open technology decision — EHR and telehealth platform, payments, CMS, CRM, scheduling — with rationale, trade-offs, and implementation notes.

Vendor pricing and contract terms

Real quotes from the vendors we recommend, not brochure prices — gathered through structured RFQs issued on your behalf. Alongside them, the contract terms to demand: data export rights, your own merchant account, and the exit provisions that keep you portable if you ever change platforms.

EHR platform evaluation

A technical assessment across clinical intake and API quality, order and prescription workflow, e-prescribing and pharmacy network, staff task management, scheduling and video, and patient messaging. One recommendation, with the integration patterns and the gaps named up front.

Platform architecture document

The confirmed stack, a system integration diagram with all data flows, authentication and authorization design, HIPAA compliance architecture including PHI boundaries and audit logging, API conventions, hosting and CI/CD design, and itemized monthly operating cost estimates.

Workflow documentation

Every major patient-facing and clinical workflow the platform must support, documented end to end. These become the functional specification for build and QA.

Feature specifications by portal

A prioritized, build-ready feature list for each application, each with a functional description and acceptance criteria.

Execution plan

A week-by-week build plan with sprint deliverables, a task dependency map across workstreams, design and content checkpoints, and a definition of done for launch.

How It Runs

Week 1 — Discovery and evaluation

Kickoff, mapping your business and billing model onto what it requires of the software, vendor research and interviews, EHR evaluation, and workflow documentation sessions.

Week 2 — Decisions and documentation

Vendor selections finalized, EHR recommendation delivered, workflow documents completed, feature specs drafted and reviewed, architecture document and execution plan produced.

We need about five working sessions of 60 to 90 minutes with you or your designee across the two weeks. Everything else runs in parallel.

Where our lane starts

Your business model, your billing model, and the regulatory posture around them are yours — usually shared between you, your ops lead, and your counsel. We work alongside whoever already owns them. What we own is what those decisions require of the architecture: whether your payment provider can actually support the model, what the EHR does to your order workflow, where PHI ends up. When the two are in conflict, you will hear it from us in week one rather than in month four.

What It Costs to Get This Wrong

The case for the Launch Path is not that two weeks of documents are worth $18,000 on their own. It is what the alternative costs.

A wrong EHR choice does not announce itself. It surfaces in month four, when the order workflow needs a capability the platform does not have and the integration you already paid for has to be rebuilt against a different API. Data migrates badly or not at all. Workflows your clinical team already trained on get redesigned. The launch slips a quarter, and the part of the build you thought was finished gets paid for a second time.

The same is true of a billing model the payment provider cannot support, a workflow nobody wrote down that turns out to drive half the architecture, and a vendor contract with no data export rights that turns leaving into a rebuild.

None of those are exotic. They are the normal failure modes of healthcare builds, and every one of them is cheaper to find in week one.

Price

$18,000 fixed.

Not an estimate, not hourly.

Credited in full

toward the build if you engage us within 90 days.

Yours to keep either way.

Every artifact — architecture, specs, workflows, estimates — is yours, whether you build with us, build in-house, or take it to another shop. No strings, no license, no clawback.

Why the Plan Only Contains What Pays

After years of operating virtual-care systems in production, we know which layers of a telehealth stack reward custom engineering and which are commodity plumbing best rented from a vendor. That line is not obvious from the outside, and getting it wrong is the most expensive mistake in healthcare builds.

So the build plan you get is opinionated about what not to build. EHRs, credentialing, e-prescribing rails, video infrastructure — if a vendor does it well, the plan says rent it and names the vendor, the price we were quoted, and the terms to demand. What we specify for custom build is the part that pays: the patient experience, the intake and funnel, the portal, and the integration work that ties it all together. You are paying for the judgment to tell the difference, and the plan is yours to keep whichever way you build.

AI gets the same treatment. Where it belongs in your product — intake triage, documentation, clinical summarization, support deflection — the plan says where, what it would take, and what it has to be supervised by. Where it is being added because it is expected rather than because it earns anything, the plan says that too.

What Happens After

Fixed-scope build.

The plan gets executed. Fixed scope, fixed price, milestone-based.

Integrate and launch.

EHR, payments, pharmacy, and the rest wired up and running in production.

Engineering operations.

We stay. Ongoing ownership of the platform, its integrations, and its roadmap.

Most of our engagements are still running years later. That is the intent, and it is why we would rather resolve the hard questions in week one than discover them in month four.

On How We Work Fast

We use AI-assisted tooling throughout delivery, and it is a meaningful part of why a two-week Launch Path produces this much. It accelerates research, vendor evaluation, and documentation, and it carries into the build itself — code generation, test coverage, migration work, and the review passes that catch what a tired human misses.

It does not change what we are willing to sign our name to. Architecture decisions, compliance boundaries, and clinical workflow judgment are made by senior engineers who have run these systems in production. Speed comes from the tooling. Judgment does not.

Questions We Get Asked

What if the Launch Path concludes we should not build yet?

Then that is what the plan says, and we will tell you why in plain language — the market timing is wrong, the clinical model is not settled enough to specify, the vendor you already have covers more than you think, or the money is better spent somewhere else this year. You keep every artifact, and you have paid $18,000 to avoid spending a great deal more on the wrong thing. We would rather be the firm that told you honestly than the one that took the build.

How is this different from hiring a fractional CTO?

A fractional CTO is one person's judgment, part-time, usually for months, and their output lives largely in their head and your Slack. The Launch Path is a team producing a fixed set of documents in two weeks, for a fixed price, that any engineering organization could execute against — including one that is not us. They are not really substitutes, and they work well together — a fractional CTO holding this plan has something concrete to hold a build accountable to, whoever ends up doing it.

We already have something running. Is this still for us?

Often it is the better fit. The evaluation is the same, but the questions change: what is worth keeping, what has to be replaced, what order to do it in, and how to migrate without a cutover weekend the whole company remembers. Replatforming an operating business is harder than a greenfield build, not easier, which is exactly why it is worth two weeks up front.

Can we skip the evaluation and just have you tell us which EHR to pick?

We could give you an answer in an hour, and it would be worth about what you paid for it. The recommendation depends on your order workflow, your prescribing model, your billing model, and what your clinical team actually does all day. Those are the two weeks. The recommendation is the easy part at the end.

What if we take the plan to another firm?

That is a legitimate outcome and the terms are written for it. Every artifact is yours with no license and no clawback, and the plan is deliberately written so someone else could execute it. We would rather compete on the build than lock you in at discovery.

Who needs to be in the room?

Whoever can make decisions — usually the founder or COO, plus your clinical lead and whoever owns billing. About five sessions of 60 to 90 minutes across the two weeks. If a decision-maker cannot make time in that window, the Launch Path is worth delaying until they can.

Start a Launch Path

Two weeks, fixed price, and a set of decisions and documents your build can execute against without ambiguity.

or call 1-800-870-9071