Build or Buy in 2026

Tests One And Two: Unusual, And Does It Make You Money

The first two tests fail more often than people expect, and they fail for different reasons.

1. Unusual-feeling is not unusual: Every organization believes its workflows are distinctive, and at the level of daily experience they are: the sequence of screens, the local vocabulary, who hands what to whom. What matters for a software decision is whether the underlying model is unusual, and it usually is not. A practice that schedules patients, verifies coverage, delivers care, codes it and bills it is running the same model as everyone else with different furniture. The test is whether a vendor’s data model can represent your reality, not whether their screens match your habits.
2. Where genuine distinctiveness does show up is in the specialty layer, and the specialty work in this cluster is a decent illustration of what real difference looks like: cardiology with component splits across a stacked encounter, gastroenterology with a modifier decided mid-procedure, oncology where the drug rather than the procedure carries the value, dermatology where coverage turns on documentation language, orthopedics with episode-level global periods. Those are real structural differences. Even so, most of them are addressable inside a platform’s rules layer.
3. Test two is the one that saves people money: Suppose the workflow genuinely is unusual. Ask whether that unusual thing is how the organization makes money, or whether it is an accident of history. Organizations frequently propose building software to preserve a process that nobody chose, that predates most of the current staff, and that no one can articulate a commercial reason for. Encoding that into custom software makes it permanent and expensive.

If the honest answer is “this is just how we have always done it,” the cheaper project is changing the process to match a bought platform.

Tests Three And Four: Extend Instead, And Maintain For Life

Test three is a question to put to the vendor, in writing, before you conclude anything. Not “can your platform handle X,” which invites a yes. Ask instead: which of these three is X for us, configuration, API extension, or not possible? A vendor who answers that precisely is telling you something useful either way. A vendor who will not answer it precisely has told you something too.

Test four is the one that gets skipped, and it is the one that hurts.

Building software is a project with an end date. Owning software is not. Payer rules change quarterly, code sets get restructured, regulations arrive with compliance dates, and integrations break when the systems on the other end upgrade. Every one of those is a maintenance event, and they keep coming for as long as the software runs.

The specialty work in this cluster produced a steady supply of examples: a code series retired and replaced with a differently structured one, a mandatory modifier introduced with automatic denials attached, a federal interoperability rule with a compliance date. None of those were foreseeable at build time and all of them are maintenance.

So test four is not “can you fund the build.” It is: can you fund a small permanent team, indefinitely, for a system that will never be finished. Organizations that answer honestly here often discover their build case was really a budget-timing case, where the capital was available and the operating cost was not, and that combination is the worst possible reason to build.

The Hybrid Most Organizations Actually Land On

When all four tests are applied honestly, the common outcome is neither pure option. It is: buy the platform, build the thin layer that is genuinely yours.

That layer is usually small and specific. A rules engine for the handful of payer behaviors your platform does not model. A reconciliation process that compares expected against allowed at line level, which most platforms do not do well. A specialty-specific validation that runs before submission. An integration that moves data between the platform and something else you run.

Each of those is weeks of work rather than quarters, sits alongside a supported product rather than replacing it, and can be abandoned without stranding the operation. That last property matters more than it sounds. A thin layer you can throw away is a fundamentally different risk position from a platform you cannot leave.

This is also where the honest version of our own commercial interest sits. Most of the useful work we do in revenue cycle is this shape, not whole-platform replacement, and it is the recommendation I would give regardless of who did the building. If you want the detail on the build option, custom medical billing software development covers what we actually do, and claims processing configuration covers where the rules live.

The Questions That Actually Separate Vendors

Test three depends on getting precise answers from vendors, and the default evaluation process is not built to produce them. A demo shows the happy path. A feature matrix collapses “supported,” “supported with configuration” and “on the roadmap” into the same tick. Neither tells you what you need.

Six questions that do. I have watched all six change a decision.

1. “For each of these requirements, is it configuration, API extension, or not possible?” The question from test three, asked as a written list rather than a conversation. The value is partly in the answers and partly in whether you get answers at all.
2. “Show me the exception path, not the happy path.” Ask to see a claim that denies, gets worked, gets appealed and gets resolved. Ask to see a patient with two coverages where the secondary is wrong. The demo is built around the clean case; your revenue problem lives in the other one.
3. “What happens to my data if we leave?” Format, completeness, timeline, cost. A vendor who has thought about this answers immediately. The answer also tells you your real switching cost, which is the number that determines whether a wrong buy is genuinely recoverable.
4. “How often do you change the data model, and what happened to customers the last time you did?” Platforms evolve. If your custom extensions sit on top of it, their upgrade is your maintenance event.
5. “Which of my integrations are pre-built, which are configured, and which are custom work?” Integration count is the dominant cost driver whichever path you take. Pre-built means someone else maintains it. Custom means you do, even inside a bought platform.
6. “Who is accountable when a claim is wrong because of your rules engine?” Not a legal question. An operational one. The answer reveals whether the vendor treats their content as a product they stand behind or as a configuration you own.

If you get precise answers to all six, you can run the four-part test properly. If you cannot get answers, that is itself a finding, and it belongs in the decision.

What Building Actually Involves

If you have cleared all four tests, here is what you are taking on, described without enthusiasm.

1. Integration is the project: Not a workstream in it. Eligibility, clearinghouse, remittance, the electronic health record, the practice management system, whatever holds your contracts. Each has its own interface, its own reliability characteristics and its own upgrade schedule. Anyone who scopes a revenue cycle build primarily by feature list has scoped the wrong thing.
2. The edge cases are the product: The happy path in claims processing is straightforward and is not where the money is. The value is in the exceptions, and exceptions are discovered rather than specified, which means the requirements will grow during the build in ways that are not scope creep but genuine discovery.
3. Compliance is continuous, not a phase: Protected health information, audit trails, access control, breach obligations. These are architectural decisions made early that are expensive to retrofit.
4. And the last mile is where schedules die: Connecting to a major electronic health record is well understood. Getting a result to land in the right field, in the right workflow, in front of the right person, in a way that survives the vendor’s next upgrade, is the part that takes the time. I say that as the person who has to estimate it. Anyone presenting that part as routine has not done it.

When Buying Clearly Wins, And It Usually Does

The explicit version, because an article like this owes one.

• Buy when your workflows are ordinary, which is most of the time, and when a platform’s data model can represent your operation without contortion.
• Buy when the requirement is configuration or extension, which is where most requirements actually live.
• Buy when you cannot commit to permanent maintenance, regardless of how well the other three tests went. This one overrides.
• Buy when speed matters more than fit. A platform running next quarter usually beats a better-fitting system running the year after, because the revenue leaks in the meantime are real and the perfect system frequently arrives late.
• Buy when you do not have engineering capacity you are willing to dedicate permanently. Borrowed capacity builds things nobody maintains.

For the shortlist itself, our list of revenue cycle management companies is a starting point, and healthcare claims management software covers the claims-specific product category.

What Your Integration Layer Has To Do Either Way

One thing does not change with the decision, which is why it deserves its own section.

Whether you buy, build or run the hybrid, you will operate more than one system, and the quality of the connections between them will set the ceiling on everything else. Standards and systems are the vocabulary here: X12 transaction sets for claims and remittance, HL7 v2 and FHIR for clinical data, and whichever electronic health record you run, whether that is Epic, Cerner or eClinicalWorks.

Four things the layer has to do:

1. Move data both directions: Reading is the easy half. Writing back into the system of record, correctly and idempotently, is where the difficulty concentrates.
2. Reconcile identity across systems that were never designed to agree on what a patient, an encounter or an episode is.
3. Fail visibly: A silent integration failure produces a revenue gap nobody notices for a month.

Survive upgrades on the other side, which you do not control and are not consulted about.

Buying a platform does not remove this work. It changes who does it and how much of it is your problem, which is a real difference but not the same as elimination. Our prior authorization services covers one instance of this in depth, and automation in the revenue cycle and robotic process automation cover the approaches frequently proposed as an alternative to proper integration, which they are not.

Buying The Operation Rather Than The Software

Build-versus-buy framings usually omit a third option that is frequently the right one: do not run the revenue cycle yourself at all.

Outsourcing moves the software decision to someone whose business it is, along with the staffing, the payer expertise and the maintenance burden. For organizations under a certain size, or without anyone who owns billing technology as a job, it outperforms both alternatives comfortably. Outsourcing revenue cycle management covers where that line usually falls, and medical billing versus revenue cycle management clarifies the scope difference if it is fuzzy.

Two cautions, both from the work elsewhere in this cluster. Outsourcing relocates a problem that originates upstream rather than solving it, so if your denials are created at eligibility, an outsourced biller inherits bad data and works it faster. And a partner reporting performance against their own metric definitions is not independently verifiable, which is why how to improve revenue cycle management argues for owning the definitions whoever does the work. Rural and critical access organizations carry a different profile again, covered in critical access hospital reimbursement, and specialty operations like behavioral health have their own considerations.