Stop paying.
Start owning.
Most operators do not have one software problem. They have five or six subscriptions clustered around a system they cannot leave, a bill that goes up every renewal, and nothing on the balance sheet after a decade of paying it. We build the system you own instead. AI tooling is why an owned build now costs less than it used to. Senior judgment is why it is still built properly.
Rent for five more years, or own it.
Same money, different ending.
Renting is not the cheap option. It is the option with no end. Pick what you currently spend on software you will never own, pick the retainer band, and the page solves for the build fee at which the two cost exactly the same over five years. Every number below is your arithmetic, not our quote.
Renting, five years at $500k a year$2.5M
In year six you own nothing, and the renewal arrives again.
Owning, the same five years, the same total$2.5M
In year six you own the software. The retainer continues, because regulations and integrations do.
Break-even build fee$1.11M
Plus $278k a year, every year, at a 25% retainer band.
A fixed build price below the break-even figure costs less than five more years of renting, and leaves you holding the software. Above it, renting wins on cash over this window, and we will say so in the first conversation rather than after you have signed something.
Illustrative arithmetic on figures you choose. It is not a price, an estimate, a proposal or a saving we are claiming. We have not seen your systems. The five-year window is a convention, not a prediction, and it deliberately ignores inflation on your side and ours, the cost of your own people's time during a build, and the fact that a subscription price you do not control tends to move in one direction. Your real number comes out of a scoping conversation and is fixed in writing before anyone writes code.
You are not buying software. You are paying a percentage of your own revenue.
Healthcare is the sharpest version of the problem, which is why we start there. Practice management and revenue cycle vendors do not usually charge per seat. They charge a share of what you collect, which means the invoice grows every time your clinicians get busier, and it grows whether or not the vendor did anything differently that year.
This is not a rumour about one company. It is disclosed in filings. We have put the citation on this page so you can read the primary source rather than take our word for it.
- The bill scales with your success, not with the work. Growth in collections is growth in the fee, with no matching growth in what the vendor delivers.
- The bolt-ons multiply. Analytics, scheduling, referral tracking, patient messaging, forms, dashboards. Each is a separate contract, a separate login and a separate renewal.
- Your own operating data sits behind someone else's export button. Reporting across locations turns into a quarterly manual assembly job because no single product sees the whole picture.
- The company you signed with may not be the company you renew with. Ownership changes, roadmaps change, and the renewal conversation is rarely the conversation you had when you bought.
- Leaving gets more expensive every year you stay. Not because the software is good, but because more of your process has been bent around it.
2% to 8% of collections
athenahealth's own Form S-1 registration statement, filed with the SEC in June 2007, states that its business services fees "are typically 2% to 8% of a practice's total collections". The filing is linked at the foot of this page.
30 providers · $15M collected
A thirty-provider group collecting fifteen million dollars a year. The group size and the collections figure are ours, chosen to be legible, not taken from any real client.
$750,000 a year
Five percent of fifteen million dollars, to one vendor, every year, before a single bolt-on product is added to it. That is the number worth comparing against owning something.
The 2% to 8% band is one vendor's own disclosure, made at its 2007 IPO, and it is quoted here because it is a primary source rather than a market estimate. What any vendor charges you today is set per contract and is not published anywhere. The provider count, the collections figure and the 5% mid-point are ours, stated so you can replace all three and redo the arithmetic against your own remittance reports.
We are engineers, not lawyers, and nothing here is legal advice. These are questions we would want answered before signing a percentage-of-collections agreement, and they are the kind of question your own counsel can settle quickly.
First, does a federal payment rule reach your arrangement? For Medicare, 42 CFR 424.73(b)(3) permits payment to an agent furnishing billing and collection services only where, among other conditions, "the agent's compensation is not related in any way to the dollar amounts billed or collected". The Medicaid equivalent, 42 CFR 447.10(f), requires that a business agent's compensation is "not related on a percentage or other basis to the amount that is billed or collected". HHS OIG's compliance guidance for third-party medical billing companies states its "longstanding concern that percentage billing arrangements may increase the risk of upcoding and similar abusive billing practices". All three are linked at the foot of this page.
Second, does your state add its own restriction? New York's rules for billing services, 18 NYCRR 504.9, carry the same percentage prohibition. In Illinois, an appellate court held in 2008 that a 4.5 percent-of-reimbursements medical billing agreement violated the Medical Practice Act's fee-splitting provision and was "void as against Illinois law". Whether any of that reaches your own contract depends on the contract, the payer mix and the state, and that is a question for a lawyer who has read it, not for a marketing page.
The obvious pitch here would be "replace your EHR". We will not make it, because it is the wrong advice and because the firms that make it have mostly not had to live with the result.
The pitch we refuseRip out the clinical system of record.
What we actually doKeep the EHR. Replace the six things bolted around it.
Your clinical record stays where it is. The operating layer becomes yours.
The same arithmetic runs in any company renting six products to do one job.
Healthcare is where we are starting, not where this stops. Nothing in the argument is clinical. If your software sits close to how the business actually makes money, and you are paying per seat for something that only ever gets most of the way there, the ownership case is the same one.
Multi-location operations
One view across every site, when scheduling, intake and operational data live in a different system at each one. Reporting leadership can act on, with access controls that match who should see what, instead of a spreadsheet somebody rebuilds every Monday.
Internal tools and workflow software
The process you actually run, built as software, rather than your team reshaping itself around somebody else's product. This is where per-seat sprawl usually hides: four tools, three integrations and a manual step between each pair.
Customer and partner portals
The surface your customers, clients or franchisees touch. Owning it means you can change it the week you decide to, rather than filing a feature request with a vendor whose roadmap is set by somebody else's contract.
Data consolidation after acquisitions
Roll-ups inherit systems, not just revenue. A warehouse beside the systems you acquired, with one definition of a customer, an order and a location, is usually the cheapest thing you can build and the fastest to pay for itself.
Replacing per-seat sprawl with one owned system
When several subscriptions are each doing a fraction of one job, the seat count is not the real cost. The integration tax between them is, and it is paid in your team's time rather than on an invoice, which is why it never shows up in the software budget.
We do not replace a genuine commodity. Payroll, accounting, email and the category leaders that already fit you well should stay bought.
What we build, and
what we will never build.
The right-hand column is the more useful one. Anything clinical, time critical or life safety adjacent is a category where the cost of being wrong is not measured in money, and a firm that will not say that out loud has not thought about it. Knowing where the line is, is the qualification.
- Multi-location operations dashboards that read across every site you run
- Revenue and denial analytics, so the pattern behind the write-offs is visible
- A data warehouse beside the system of record, not in place of it
- Referral management and relationship tooling built for how referrals actually arrive
- Inventory, supply and asset tracking
- Internal workflow tooling, approvals and the operational steps that live in email today
- Post-acquisition data consolidation for roll-ups
- Customer, patient-facing and partner portals that sit alongside the record system
- An EHR or clinical system of record. Not a smaller one, not a simpler one, not as a phase two.
- E-prescribing, controlled substance prescribing or EPCS.
- Claims clearinghouse connectivity.
- Pharmacy dispensing, medication administration or anything in the medication path.
- Clinical decision support, triage, dosing or anything that influences a care decision.
- Any system where a few minutes of downtime is a patient safety event rather than an operational inconvenience.
- Device integration in a monitoring or alarm path.
Everything in the left column can be down for an afternoon and cost you a bad afternoon. Everything in the right column cannot, and each of those categories carries regulatory obligations and certification regimes that a build like ours has no business walking into. Admitting where the line is, is not modesty. It is the whole reason the left column is safe to hand to us.
One of these is an asset. The other is a cost, forever.
There is an accounting difference between renting software and owning it, and it is not a rhetorical one. Under US GAAP, qualifying costs of software developed for internal use are capitalised once management has committed funding and completion is probable, which means the build shows up as an asset and is written down across its useful life. A cloud arrangement that does not include a software licence is a service contract instead, and FASB's own words for the hosting element are that the fees "are expensed as incurred". It is an operating expense in the period you pay it, and an operating expense again next period.
We are engineers, not your auditors, and the treatment of your specific facts is their call and your CFO's. The standard itself is also moving: FASB's 2025 update removes the old sequential project-stage language from the internal-use software subtopic for annual periods beginning after 15 December 2027. But the shape of the question survives the amendment, and it is worth putting to your finance team before the next renewal, because the two paths do not look the same on a balance sheet even when they cost the same in cash.
@@ the subscription @@
Balance sheetno asset
Income statementopex
Ends when you stop payingyes
@@ the owned build @@
Balance sheetasset
Income statementdepreciation
Ends when you stop payingno
@@ either way @@
Someone still maintains itretainer
A simplification of the two treatments, not an accounting opinion. Your auditor decides the treatment of your facts.
Capitalising a build does not make it free, and an owned asset is not a maintenance-free one. Depreciation is still a charge against earnings. An internally developed system still needs a budget line for the people who keep it working, which is exactly what the retainer below is. And a build that never ships, or ships and is not used, is a worse outcome than a subscription you at least switch on. The accounting argument is a reason to look seriously at owning. It is not a reason on its own.
Kaiser Permanente had unlimited money and still could not build its own EHR.
We are asking you to trust an argument about building instead of buying, so the most useful thing we can show you is the case against it. Kaiser Permanente, one of the largest healthcare organisations in the United States, set out to build its own clinical information system in partnership with IBM. As IEEE Spectrum reported, "in 2003, after spending over $400 million, Kaiser terminated its Clinical Information System (CIS) EHR project with IBM to start anew with Epic Systems".
What that proves, and what it does not
It does not prove that custom software fails. It proves that a clinical system of record is a category where capital is not the constraint, and where an organisation with more of it than almost anyone still concluded that buying was correct.
That is a specific lesson about a specific category, and it is the category we already put in the right-hand column above.
Why the operating layer is a different question
An ops dashboard, a denial analysis, a referral workflow or a warehouse beside the record system are bounded problems. They have a defined data set, a defined set of users and a failure mode that costs you a bad afternoon rather than a patient.
Bounded is the entire reason a small senior team with modern tooling can deliver them, and unbounded is the entire reason Kaiser could not.
And the part we have to say plainly
This service line is new and there is no completed engagement behind it. There is no case study on this page, no client logo and no result, because there is nothing true to put there yet, and we would rather you heard that from us than found it out later.
What does stand behind it is the engineering record: senior engineers with production experience that predates the current tooling, third-party certifications, and a public code history of work other engineers reviewed and merged. That record is on the about page and you should read it sceptically.
Six phases. You see working software in every one after the second.
The same process as any other build we run, with two additions that only apply here: a scope conversation that explicitly hunts for the reasons not to build, and a retainer that starts the day the build is handed over rather than being negotiated later.
The case against building
Before scope, we look for the product you should buy instead. If a category is genuinely commodity and something off the shelf fits you, building your own is a poor use of money, and we would rather say so now than after a contract.
Scope and architecture
What the system must do, what data it holds, what it must never touch. The data model, the auth and tenancy model, the integration surface with the systems you keep, and the hosting, all decided in writing first.
Fixed proposal, including the retainer
A fixed scope, a fixed build fee, a milestone schedule and the annual retainer figure, all in one document. If the retainer is not funded, we do not take the engagement. That condition is agreed here, not discovered at handover.
Foundation, then milestones
Auth, data model, environments, continuous integration, error tracking and secrets handling first. Then working, deployed software at the end of every milestone, in your repository and your cloud account, not a demo video.
Hardening and the security review
Exploit attempts against our own endpoints, dependency scanning, access-control verification and load behaviour. Where the system sits near regulated data we assess it against the named standard, remediate what fails and produce the documentation an auditor will test.
Handover into the retainer
Architecture documentation, a runbook and a live walkthrough with whoever will own it. Then year one of the retainer begins: regulatory change, the integrations you depend on breaking, upgrades and the ordinary work of keeping software alive.
Every incumbent hides this. Here is the whole shape of it.
We will not print a headline build price, because a number on a marketing page is a guess about a system nobody has looked at, and the site already refuses to do that for the rebuild tier. What we will publish is the structure, in full, including the part most firms bury in a renewal email eighteen months later.
A fixed build fee
Fixed scope, fixed price, agreed in writing before work starts and billed against milestones. Set by scope, data sensitivity and timeline, in that order. No hourly rate, published or billed. Not a number we can honestly print before a scoping conversation.
20% to 30% of build value, annually
The regulatory maintenance and support retainer. It pays for regulatory and standards change, the third-party integrations you depend on breaking without notice, dependency and security updates, and a senior engineer who already knows the system when something goes wrong at 4pm on a Friday.
No retainer, no engagement
We refuse engagements where the client will not fund the retainer. Unmaintained custom software built around regulated processes becomes a liability faster than a subscription does, and handing one over knowing it will not be maintained would be a worse outcome for you than never building it.
Why publish this at all: every incumbent in this market hides pricing behind a form, and the entire argument on this page is that renting quietly and indefinitely is the problem. A firm making that argument while hiding its own numbers would not deserve to be believed. The rest of the price list, including the tiers that carry real ranges, is on the pricing page.
What operators ask before they own anything.
Are you telling us to replace our EHR?
No, and we will not build one. Your clinical system of record stays exactly where it is. What we replace is the layer of separate products bolted around it: the operations dashboards, the analytics, the referral tooling, the internal workflow software and the reporting that currently gets assembled by hand. That layer is bounded, it is not time critical, and it is where the recurring bill quietly accumulates.
What does the annual retainer actually pay for?
Regulatory and standards change, the third-party integrations you depend on changing or breaking without notice, dependency and security updates, monitoring, and a senior engineer who already knows the system when something goes wrong. It is priced at 20 to 30 percent of build value a year. We publish it because pretending an owned system is maintenance free is the single most common way these projects turn into the thing you regret.
Why will you not publish a build price?
Because it would be a guess about a system we have not seen, and a guess printed on a marketing page turns into an anchor that neither of us can defend. We publish the structure instead: a fixed build fee set by scope, data sensitivity and timeline, plus a mandatory annual retainer at 20 to 30 percent of build value. The figure itself is fixed in writing after a scoping conversation and before anyone writes code.
Can you make us HIPAA compliant or SOC 2 certified?
No, and nobody else can either. SOC 2 is an attestation issued only by a licensed CPA firm, HIPAA compliance is the covered entity's own legal obligation with no government-issued certification behind it, and a PCI DSS attestation comes only from a certified Qualified Security Assessor. What we can do is build the technical controls those processes test, assess a system against the named standard, remediate what fails, and produce the documentation. That is the engineering half of the work and it is the half we are qualified to do.
We are not a healthcare company. Is this still for us?
Yes. Healthcare is where we are starting because the percentage-of-collections model makes the cost of renting unusually visible, but nothing in the argument is clinical. If you are a mid-market or enterprise operator paying per seat for several products that each do part of one job, and the software sits close to how you make money, the ownership case is the same one and the process is the same process.
Have you delivered one of these before?
Not on this service line. There is no completed engagement behind it yet, which is why there is no case study, no client logo and no result anywhere on this page. What stands behind it is the engineering record: senior engineers with production experience that predates the current generation of AI tooling, third-party certifications issued by GitHub, Meta and IBM, and a public code history of work that other engineers reviewed and merged. Judge us on that, and on the scoping conversation, rather than on outcomes we have not produced.
What if buying really is the right answer for us?
Then we will say so in the first conversation, before you have signed anything. If a category is genuinely commodity and an off-the-shelf product fits you well, building your own version of it is a poor use of money. The first phase of every engagement is explicitly a hunt for the reason not to build, because a firm that only ever recommends its own product is not giving you advice.
- Percentage-of-collections pricing, "Business services fees are typically 2% to 8% of a practice's total collections": athenahealth, Inc., Form S-1 registration statement filed with the US Securities and Exchange Commission on 22 June 2007, CIK 0001131096. Filing on EDGAR.
- Medicare payment to a billing agent, "the agent's compensation is not related in any way to the dollar amounts billed or collected": 42 CFR 424.73(b)(3), applied to suppliers by 42 CFR 424.80(b)(5). Medicaid equivalent, "not related on a percentage or other basis to the amount that is billed or collected": 42 CFR 447.10(f).
- "The OIG has a longstanding concern that percentage billing arrangements may increase the risk of upcoding and similar abusive billing practices": US Department of Health and Human Services, Office of Inspector General, Compliance Program Guidance for Third-Party Medical Billing Companies, 63 Fed. Reg. 70138, 18 December 1998, footnote 40 at 70143.
- New York billing services: 18 NYCRR 504.9, requiring that a billing agent's compensation "is not related on a percentage or other basis to the amount billed or collected".
- Illinois, a 4.5 percent-of-reimbursements billing agreement held "void as against Illinois law" under the fee-splitting provision of the Medical Practice Act, 225 ILCS 60/22(A)(14): Center for Athletic Medicine, Ltd. v. Independent Medical Billers of Illinois, Inc., Appellate Court of Illinois, First District, 28 May 2008.
- Hosting arrangements that are service contracts, "the fees associated with the hosting element (service) of the arrangement are expensed as incurred": FASB, Accounting Standards Update 2018-15, August 2018. The internal-use software subtopic, ASC 350-40, was subsequently amended by Accounting Standards Update 2025-06, effective for annual periods beginning after 15 December 2027.
- Kaiser Permanente's halted clinical information system: Robert N. Charette, IEEE Spectrum, 8 March 2010.
Every figure above was read at its source before it was published here. If a number on this page cannot be traced to the source beside it, tell us and we will delete it rather than soften it.
Send us your renewal list. We will tell you what is worth owning.
A scoping conversation with a senior engineer, not a sales call. You leave with a view on what should stay bought, what is worth building, and the fixed structure it would run on. Or with an honest reason not to build anything.