The Same Work, Sold Two Very Different Ways
A services team builds a healthcare AI documentation tool for a clinic. The clinic pays, the project ships, everyone is pleased — and then it ends. The invoice is settled, the code is handed over, and the team goes looking for the next client. That is the fundamental rhythm of a services business: every month starts at zero, and revenue is only ever as good as the pipeline.
Now imagine the same tool, built once and sold to a hundred clinics as a subscription. The work of building it was roughly comparable. What changed is what happens afterwards. The revenue does not stop when the build stops — it arrives every month, from every clinic, whether or not a new deal closes. That is the whole argument for turning a proven services workflow into a product, and in healthcare specifically it is a stronger argument than in most sectors, because the workflows are painful, expensive, and repeat identically across thousands of near-identical clinics.
This guide is about making that transition deliberately: which workflow to productise first, the genuinely hard engineering jump from single-tenant builds to multi-tenant HIPAA architecture, how to price it, and the parts of healthcare go-to-market that are slower and less forgiving than software founders expect. It builds on the healthcare AI development pillar, which maps the workflows themselves; this piece is about the business you become when you stop selling hours and start selling seats.
The Economics, Made Concrete
The clearest way to see why recurring revenue changes the business is to put the two models side by side. The figures below are illustrative examples, not promises or projections — real numbers depend entirely on your workflow, your market, and your ability to sell. They exist only to show the shape of the difference.
| Custom build (services) | Multi-tenant SaaS (product) | |
|---|---|---|
| Revenue event | One-off, e.g. $50,000 per project | Recurring, e.g. $500/month per clinic |
| At 100 customers | $50,000 once, then it ends | 100 × $500 = $50,000 MRR, every month |
| Annualised at that scale | Depends on next project closing | ~$600,000 ARR that renews |
| What drives growth | Winning the next bespoke deal | Adding clinics to an existing product |
| Cost of serving one more | Nearly a full new build | Marginal — onboarding, support, compute |
| Business valuation | Multiple of profit, if any | Multiple of recurring revenue |
The line that matters is the second one. A $50,000 project and a product doing $50,000 in monthly recurring revenue look similar in a single month and are worlds apart over a year. The product also compounds: the hundred-and-first clinic costs far less to serve than the first, because the platform already exists. The services team sells its capacity; the product team sells something that keeps earning while the team sleeps.
None of this makes services bad. Services fund the transition, prove the workflow, and generate the case studies that make the product credible. The point is not to abandon the services business — it is to let it pay for a product that eventually outgrows it.
Choosing Which Workflow to Productise First
The temptation is to productise everything at once — a platform on day one. That is almost always a mistake. The right first product is a single workflow you have already built for real clients, that hurt enough to pay for, and that is close to identical across the clinics you would sell to.
Three tests help you pick:
Have you built it more than once? If you have delivered the same documentation workflow for three separate clients and each time it looked broadly the same, that repetition is the signal. You are already re-selling the same solution as bespoke work — productising it just stops you rebuilding it each time.
Is the pain sharp and universal? An AI medical scribe qualifies because every clinician in every clinic loses hours to documentation, and the value is obvious in the first week. A voice receptionist qualifies for the same reason — front-desk load is universal. Niche workflows that only apply to one specialty make weaker first products.
Does it survive standardisation? Bespoke work can bend to each client. A product cannot — it has to be opinionated. The best first workflows are ones where 80% of clinics want roughly the same thing, so your configuration surface stays small. If every customer needs deep customisation, you are still doing services with a subscription bolted on.
An AI scribe and a voice receptionist are the two most common first products for exactly these reasons: high, universal pain; a clear standardisable core; and pricing that maps naturally onto a monthly subscription.
The Hard Part: From Single-Tenant to Multi-Tenant HIPAA
This is where most services-to-product transitions underestimate the work. A custom build is single-tenant by nature — one clinic, one deployment, one dataset, walls around everything. A SaaS product is multi-tenant: many clinics share the same running system, and the entire burden of keeping their data apart moves from physical separation into your architecture.
In healthcare, that is not merely a scaling problem. It is a compliance problem with legal teeth. Every tenant's protected health information has to be isolated so completely that one clinic can never, under any circumstance, see another's records — and you have to be able to prove it. The HIPAA-compliant AI architecture that was demanding for a single client becomes an order of magnitude more demanding when tenants share infrastructure. The specific jumps:
Tenant isolation becomes the core design decision, not a detail. Every database query, every retrieval call, every cache lookup must be scoped to the authenticated tenant — not filtered after a broad fetch, but scoped at the query. The same session-isolation discipline that governs any AI agent handling sensitive data applies here across tenants, with a Business Associate Agreement behind each one.
Audit logging has to be per-tenant and complete. A single clinic will accept "we log everything." A hundred clinics, each with their own compliance officer, need to see their own audit trail and only their own — who accessed what PHI, when, and why.
BAAs multiply, and so does your exposure. Each clinic signs a Business Associate Agreement with you; if you pass PHI to a third-party model API, that provider needs a BAA too, and your data must be excluded from training. One misconfiguration is no longer one client's problem — it is potentially every tenant's.
Onboarding and offboarding become product features. Provisioning a new tenant, migrating their data in, and cleanly deleting it when they leave all have to be repeatable and safe. In services you did this by hand once. In SaaS it happens constantly and cannot go wrong.
The honest summary: the AI is the easy part. The multi-tenant HIPAA architecture is where the real engineering and the real risk live, and it is worth building slowly and correctly, because a data-isolation failure in a healthcare product is close to fatal for trust.
Pricing the Product
Healthcare SaaS pricing generally follows the unit that best tracks the value delivered. Three models dominate, and the right one depends on your workflow:
Per provider (per seat). Natural for a scribe or any tool a clinician uses directly, because the value scales with the number of clinicians whose time you give back. Ten physicians, ten seats. This is the most common model for documentation products and the easiest for buyers to reason about.
Per clinic (flat site licence). Suits workflows that serve the whole practice rather than an individual — a voice receptionist, a scheduling engine, patient communications. The clinic pays one predictable monthly fee regardless of headcount, which appeals to smaller practices that dislike per-seat maths.
Per volume (usage-based). Fits workflows where cost tracks activity — calls handled, messages processed, claims checked. It aligns your revenue with the customer's actual usage but makes their bill less predictable, which some healthcare buyers dislike.
Many products blend these: a per-provider base with usage tiers on top, or custom enterprise pricing for multi-clinic groups. The illustrative $500/month-per-clinic figure earlier is a flat site-licence example; a per-provider product at, say, an illustrative $150 per clinician lands in a similar place for a mid-sized practice. Whatever you choose, keep it simple enough that a practice manager can understand the bill without a spreadsheet — complexity in pricing is friction in sales.
Healthcare Go-to-Market Is Slower Than You Think
Here is the caveat that catches most technical founders. Building the product is hard but knowable. Selling it into healthcare is slow, relationship-driven, and full of gatekeepers, and no amount of engineering excellence shortens that.
Enterprise healthcare sales cycles are long — often six to eighteen months for a hospital or multi-clinic group, because the buying decision touches clinical leadership, IT, compliance, security review, and procurement, any of whom can stall it. A brilliant demo does not close a deal; a completed security questionnaire and a signed BAA move it forward. Budget realistically for this. A product that is technically ready in month six may not have meaningful revenue until month twelve or later, and your runway has to survive that gap.
Two channels shorten the path without shortening the cycle:
EHR marketplaces. Epic, Athenahealth and others run app marketplaces where clinics discover and install integrated tools. Getting listed involves certification and integration work, but it puts your product in front of buyers at the moment they are already looking — a genuine distribution channel rather than pure outbound sales. The FHIR and EHR integration that makes your product work is also what makes this channel available.
Partnerships. Compliance firms, healthcare consultants, and EHR implementation partners already have the trust and the relationships you are trying to build from scratch. A single partnership with a group that serves fifty clinics can outperform months of direct outreach.
None of this is fast. The upside is that the same friction that slows you down — compliance, integration, procurement — becomes a moat once you are through it. A competitor faces the same eighteen-month climb you did.
What Good Looks Like
A healthy services-to-product transition tends to look like a three-year arc rather than a leap.
Year one — earn the right. Become a recognised healthcare AI engineering partner. Ship real client work, publish case studies, technical writing and demos, and build the reusable modules every healthcare product needs anyway: FHIR handling, HIPAA-grade authentication, audit logging, and the AI workflow scaffolding. Target ten to twenty long-term US clients whose repeated needs reveal which workflow to productise. The services revenue funds everything else.
Year two — launch one flagship. Take the single most-proven workflow — an AI scribe or voice receptionist — and turn it into a genuine multi-tenant SaaS. Stand up a US sales function, begin partnering with EHR vendors, consultants and compliance firms, and add subscription pricing alongside the custom development that still pays the bills. The product and the services coexist deliberately.
Year three — tilt toward product. Shift the centre of gravity from services to product-led growth. Expand the single workflow into a multi-module platform — documentation, scheduling, patient communications, analytics — and pursue partnerships with hospitals, multi-clinic groups and insurers. The goal is a rising share of revenue that is recurring, until the product, not the pipeline, is what the business runs on.
Questions to Ask Before You Start
Which workflow have we already built more than once? If nothing repeats, you are not ready to productise — you are still discovering the product.
Can we prove tenant isolation, not just claim it? If your team cannot describe exactly how one clinic's PHI is kept from another at the query level, the multi-tenant architecture is not ready.
What is our BAA and compliance story for a shared platform? Every tenant needs one; every third-party API touching PHI needs one. Who owns that process?
How long is our runway against a twelve-to-eighteen-month sales cycle? If the answer is "six months," the go-to-market plan and the funding plan are misaligned.
Are we willing to keep services running while the product finds its feet? The transitions that fail are usually the ones that abandoned the funding source too early.
What It Costs and How Long It Takes
Turning one proven workflow into a multi-tenant HIPAA SaaS is a multi-quarter effort, not a sprint — the compliance and isolation architecture alone is substantial, and it has to be built before the first paying tenant, not retrofitted after. Expect the engineering to be front-loaded and the revenue to lag well behind it, because healthcare sales cycles are long and the early customers each take real effort to close and onboard.
The honest caveat is that this is a harder path than shipping another custom build, and slower to pay off. The services business rewards you every time you close a deal; the product business asks you to invest ahead of revenue and wait through a long sales cycle before the recurring revenue compounds. That is precisely why so few services teams make the jump — and why the ones that clear the compliance, integration and go-to-market bar end up with something far more valuable than a busy pipeline.
Related guides
- Healthcare AI development: the workflows worth building
- AI medical scribe: speech to SOAP notes to EHR
- HIPAA-compliant AI architecture
- AI remote patient monitoring
- AI agents for healthcare: reducing admin burden
- Our AI development services
We Help Services Teams Build Products That Recur
We build healthcare AI that clears the compliance bar — and we understand the specific engineering and business work of turning a proven services workflow into a multi-tenant SaaS. From choosing the right first product to designing tenant isolation that stands up to a hundred compliance officers, we treat the hard parts as the whole point, not an afterthought.
If you have a workflow you have already built more than once and you are wondering whether it could become a product with recurring revenue, that is exactly the conversation worth having.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
Why is recurring revenue so much better than project revenue?
A custom project pays once and ends; a subscription product pays every month for as long as the customer stays. At a hundred customers, an illustrative $500-per-month product generates the same $50,000 as a one-off project — but it does so every single month, and it compounds as you add customers. It also makes the business more valuable, because recurring revenue is worth a multiple that project income rarely commands. The figures here are illustrative examples, not promises; real numbers depend on your workflow and your ability to sell it.
Which healthcare workflow should we productise first?
The one you have already built more than once, where the pain is sharp and universal, and where roughly 80% of clinics want the same thing. In practice that usually points to an AI medical scribe or a voice receptionist — both address pain every clinic feels, both have a standardisable core, and both price naturally as a monthly subscription. Avoid niche, specialty-specific workflows as a first product, because they force per-customer customisation that keeps you in the services model.
What is the hardest part of building a healthcare SaaS?
Multi-tenant HIPAA architecture. Moving from a single-client build to a shared platform means every tenant's protected health information has to be isolated so completely that one clinic can never see another's data — and you have to be able to prove it, per tenant, with complete audit logging. This is a compliance problem with legal consequences, not just a scaling problem, and it is where the real engineering effort and risk live. It should be built before the first paying tenant, never retrofitted.
How should we price a healthcare AI product?
By the unit that best tracks the value you deliver. Per provider (per seat) suits tools a clinician uses directly, like a scribe. Per clinic (a flat site licence) suits whole-practice tools like a voice receptionist or scheduler. Per volume (usage-based) suits workflows where cost tracks activity, like calls handled or claims checked. Many products blend a base fee with usage tiers. Whatever you choose, keep it simple enough that a practice manager understands the bill at a glance — pricing complexity is sales friction.
How long are healthcare sales cycles really?
Long — often six to eighteen months for a hospital or multi-clinic group, because the decision touches clinical leadership, IT, compliance, security review and procurement, any of whom can stall it. A great demo does not close the deal; a completed security questionnaire and a signed Business Associate Agreement move it forward. Plan your runway around this reality: a product that is technically ready in month six may not produce meaningful recurring revenue until month twelve or later.
Should we stop doing services work to focus on the product?
Not early on. Services work funds the transition, proves which workflow is worth productising, and produces the case studies that make the product credible to cautious healthcare buyers. The transitions that fail are usually the ones that cut off the funding source before the product could stand on its own. The healthy pattern is to run both in parallel — services paying the bills while the product finds its feet — and only shift the centre of gravity toward product once the recurring revenue is real and growing.