Health Plan Core Administration Platform: Buy Facets, QNXT or HealthRules Payer, and Build Only the Surround
The core itself is not a build decision. If Facets, QNXT, HealthRules Payer or Plexis adjudicates your claims correctly, keep it, and treat anyone quoting a custom core administration platform as selling you the first two years of a project they will not finish.
On this page
The core itself is not a build decision. If Facets, QNXT, HealthRules Payer or Plexis adjudicates your claims correctly, keep it, and treat anyone quoting a custom core administration platform as selling you the first two years of a project they will not finish. The real question is where the packaged platform runs out, which is configuration lead time, value based arrangements, integration reconciliation and the experience layer. That surround runs $120,000 to $250,000 for a first release and is a genuine build.
When is off the shelf genuinely the right call here?
Almost always, and more completely than in any other category on this site. Facets, QNXT, HealthRules Payer and Plexis are large, mature systems that adjudicate claims correctly at volume, carry decades of accumulated edge case handling, and are maintained against a regulatory environment that changes constantly. Rebuilding that is not a software project, it is a decade. We turn that work down and you should be suspicious of anyone who does not.
Buy, and buy the surrounds too, if this describes you:
- A third party administrator or startup plan under roughly 30,000 members, where differentiation sits in service and network rather than in software and a build's fixed cost will not amortise.
- A plan whose configuration lead time is genuinely keystrokes rather than testing, because a replay harness will disappoint you.
- Fee for service contracting only, no shared savings, no partial capitation, no delegated arrangements to reconcile.
- One line of business and one state, so there is a single regulatory calendar rather than three.
- No permanent owner for configuration or for a regression scenario library. Both need a named analyst, not a developer, and without one they decay.
Replace the core only for a structural reason: it is genuinely end of life and unsupported, or you are entering a line of business it cannot support, such as adding Medicaid managed care to a system built for commercial. That is a packaged platform selection with a specialist integrator and a multi year, eight figure budget. It is not a custom development question and should not be sold to you as one. If your complaint is configuration speed rather than capability, replacement will not fix it, and you will spend two years discovering that expensively.
When does a custom build actually pay off?
The packaged core covers perhaps seventy percent of what a modern plan needs. The remaining thirty percent is where your differentiation, your regulatory exposure and your operating cost all live, and that thirty percent is a well scoped build. The question was never whether to build. It is where.
Four domains recur. Configuration lead time, where a benefit change takes a quarter and product strategy quietly reshapes itself around what configuration can do quickly. Value based and delegated arrangements, which are calculated periodically over populations rather than adjudicated per claim, and therefore end up in an actuary's spreadsheet and a finance analyst's settlement workbook. The integration estate, usually point to point interfaces built over fifteen years by people who have left, reconciled by an exception report somebody reads on Tuesdays. And the member and provider experience layer, which is served from core data but is not core adjudication.
Build the surround when two or more of these are true:
- Configuration lead time is shaping your product roadmap, and sales has stopped asking for designs they know will take a quarter.
- Value based settlements are calculated in spreadsheets your provider partners dispute every quarter.
- Enrollment discrepancies reach members before they reach your reports, which usually means a member finds out at a pharmacy counter.
- You have obligations arriving on a fixed regulatory date that your core vendor's roadmap does not clearly cover.
- You are a provider sponsored plan, where the arrangement with the parent health system is your most complex contract and the one the core handles worst.
How do they compare on the things that matter in this industry?
Expressing a benefit design. The packaged platforms are configuration products with real ceilings. A tiered network with a carve out for a named orthopaedic partner and an embedded deductible structure may need workarounds across benefit plan, network and pricing configuration. Ask your vendor for a price and a date on the design your sales team wants next January, and treat the date as the answer.
Proving a change is safe. This is the largest practical gap. Configuration testing today is usually a spreadsheet of scenarios a senior analyst wrote from memory. A replay harness runs a real historical claim population against the changed configuration and diffs payment outcomes, so a change that alters payment on forty claims you did not intend to touch appears within the hour rather than in production three weeks later.
Contracts calculated over populations. Core systems model fee for service pricing extremely well and capitation adequately. They do not model an attribution methodology, a quality gate that modifies a settlement, a risk corridor with a truing up period, or reconciliation of delegated encounter data against expected utilisation. That is a design boundary rather than a defect, and no amount of configuration crosses it.
Partial file failure. Ask any vendor or developer what happens when a nightly file half succeeds. The answer you want involves a processing outcome per record rather than per file, an exception queue with owners, idempotent reprocessing and replay. If the answer is file level success and failure, your operations team reconciles by hand forever.
Experience surfaces. Packaged member portals are serviceable and identical across every plan using them. They lag your product design and cannot easily show what a specific procedure will cost this member given their accumulator position today, which is exactly where a regional plan can beat a national competitor.
What does total cost of ownership look like at your scale?
These bands come from Digital Heroes delivery experience rather than a price list. A first release covering one surround domain properly runs $120,000 to $250,000 over 16 to 24 weeks. In practice that domain is almost always either the configuration regression harness or the value based arrangement engine. A multi domain programme adding the integration layer, delegated encounter handling, experience surfaces and application programming interface compliance work runs $350,000 to $900,000 across 12 to 24 months.
Lines of business drive the number, well ahead of member count. Medicare Advantage, Medicaid and commercial each carry their own regulatory calendar, file formats and reconciliation obligations, so a plan running all three is running three programmes that happen to share a codebase. State count for Medicaid is next, because Medicaid Management Information System interfaces are state specific and change on the state's schedule. The sharpest multiplier is write back: any custom logic writing into the core raises vendor support and testing burden considerably against reading and surrounding.
A regional plan at roughly 180,000 members running commercial and Medicare Advantage, scoping the configuration regression harness read only throughout, totals about $230,000 across 24 weeks. Two lines of business is why it sits near the top of the band. The same scope for a commercial only plan lands nearer $160,000, because the Medicare Advantage claim population and its separate regression scenarios drop out.
Running cost is 15 to 20 percent of build, so $35,000 to $46,000 a year on that release. Then the plan specific lines. Every core platform upgrade is a regression test of your extracts and your data store, on the vendor's schedule rather than yours. Every regulatory calendar change touches file formats, from 834 enrollment companion guides that differ per employer group and per exchange, through state Medicaid files, to Medicare Advantage reconciliation cycles. The regression suite itself needs a named analyst curating it, because a scenario library nobody prunes eventually takes hours to run and starts getting skipped, which returns you to the original problem with extra steps.
What does the hybrid look like, and when is it the honest answer?
In this category the hybrid is the only defensible shape, and the useful question is which surround to build first and how to build it safely.
Start read only. Configuration testing, value based settlement calculation, reconciliation reporting and experience surfaces all consume core data without modifying it. That means no vendor support risk, a much shorter path to production, and a system you can switch off without touching adjudication if it turns out to be wrong. Treat any write back as a deliberate decision made jointly with your core vendor, never as a technical detail inside a sprint.
Pick one domain and finish it. Plans that scope configuration testing, value based arrangements and reconciliation into a single first release get eighteen months of half built systems and no cycle time improvement. One domain in 16 to 24 weeks produces something operations will actually use on Monday.
Before any of that, spend four to six weeks answering one question in writing: exactly how does data leave your core platform, at what latency, and who inside the plan controls that route. Every other estimate depends on it, and it is the single most common reason these programmes slip.
Then sequence by pain. Provider sponsored plans almost always take value based arrangements first. Commercial plans with an aggressive sales calendar take the configuration harness. Application programming interface compliance work belongs in the multi domain phase and carries a fixed external date, so it cannot be the thing that slips.
Which should you choose, by operator size and stage?
Under 30,000 members, or a startup plan. Buy everything, core and surrounds. The one exception worth considering early is reporting and reconciliation, because administrators live or die on answering an employer group's question quickly and packaged reporting is rarely shaped like the questions clients actually ask. That is a much smaller piece of work than anything else here.
30,000 to 100,000 members, one or two lines. Buy the core, then build one surround domain at $120,000 to $250,000. Choose it from evidence rather than preference: count the professional services days you buy each year for configuration changes, and ask sales what a missed January effective date is worth in that group's annual premium.
100,000 members and up, multiple lines. Buy the core, run the multi domain programme at $350,000 to $900,000 across 12 to 24 months, and sequence it. Here the regulatory calendar is the constraint rather than the budget, so put anything with a fixed external date in its own phase.
Provider sponsored plans of any size. Buy the core, build the value based arrangement engine first. Attribution on a defined methodology at a stated cadence, settlement traceable to inputs, and a provider portal showing performance during the period rather than after it. That is the difference between a contract that changes behaviour and one that is a retrospective payment adjustment.
One rule holds across all four. Whoever builds your surround should be able to tell you what they will not touch. A developer comfortable writing into adjudication tables without your platform vendor's blessing will cost you support coverage.
If you would rather someone argued with your brief than agreed with it, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You can take that specification to any other firm on your shortlist.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey found that tech debt can amount to 20-40% of the value of a company's entire technology estate before depreciation, and CIOs report that 10-20% of the budget for new products is diverted to resolving tech-debt issues. Source: McKinsey & Company (2020) →
- The federal government spends about 80% of its IT budget on operations and maintenance of existing systems rather than on development or modernization, with many critical systems being decades old. Source: U.S. Government Accountability Office (GAO) (2025) →
- PMI's Pulse of the Profession research found organizations waste an average of roughly 9.9% of every dollar invested in projects due to poor performance - equivalent to about $1 million wasted every 20 seconds collectively worldwide. Source: Project Management Institute (PMI) (2018) →
- Only about 30% of digital transformations succeed at meeting their objectives, but getting six critical success factors in place (leadership commitment, talent, agile culture, progress monitoring, clear strategy, and a modernized platform) raises the odds of success from 30% to 80%. Source: Boston Consulting Group (BCG) (2020) →
Frequently asked questions
What does it actually cost to replace the core, if we ever have to?
A genuine core replacement is a multi year, eight figure programme, and it should be a packaged platform selection run with a specialist integrator rather than a development engagement. Conversion of open claims, adjustment history and accumulator balances with audit trail intact is the hardest part and the part most often underestimated.
Do it only for a structural reason: the platform is end of life and unsupported, or you are entering a line of business it cannot support. Configuration speed is not a structural reason, and replacing on those grounds is how plans spend two years learning an expensive lesson.
What happens if our core vendor raises licensing or professional services rates?
The surround reduces your exposure to the services rate card specifically, because the work you currently buy by the day, mostly configuration regression testing, moves into a system you own. That is often the largest single line in a plan's annual professional services spend.
It does not reduce your exposure to core licensing, and it should not pretend to. Keep the surround read only and keep your own operational data store, so a future platform selection is a migration of extracts rather than a rebuild of everything you have added.
How long does the first surround release take?
Sixteen to 24 weeks for one domain done properly, with four to six weeks of discovery before it. The multi domain programme runs 12 to 24 months in phases.
The discovery answer that gates everything is how data leaves your core platform, at what latency, and who inside the plan controls that route. A plan with a maintained operational data store moves considerably faster than one where the only path is a nightly extract with a two day lag.
Would moving from Facets or QNXT to HealthRules Payer solve our configuration problem?
Possibly, in part. HealthRules Payer has a more expressive rules language than either and was designed later with that in mind, so designs that need workarounds elsewhere may configure directly. That is worth testing on your own hardest benefit design rather than on a standard demonstration.
Be clear about what a migration is, though. It is a multi year programme with a specialist integrator, and much of your twelve week lead time is regression fear rather than configuration capability. Build the replay harness first and measure which half of the problem you actually have.
Why is a configuration regression harness worth $60,000 or more?
Because most of a twelve week lead time is not keystrokes, it is proving the change did not disturb existing groups, and that proof is usually a senior analyst working through scenarios written from memory.
The harness replays real historical claims against the changed configuration and diffs payment outcomes, so unintended payment changes are visible within an hour. Plans that have it report the effect in cycle time immediately, because the fear of regression was the actual constraint rather than the analyst's typing speed.
Is it safe to let a developer write into our core platform?
Be careful and price it accordingly. Writing into adjudication tables or altering configuration outside your platform vendor's supported path can cost you support coverage, which is a bad trade at any development saving.
Read only surrounds are both cheaper and safer, and they can be switched off without touching adjudication if they turn out to be wrong. Treat write back as a joint decision with your core vendor, documented before it is built rather than discovered during an incident.
Where does the CMS prior authorization API rule fit in the plan?
In the multi domain programme rather than a first release, and it carries a fixed external date. The CMS Interoperability and Prior Authorization final rule extends application programming interface obligations for impacted payers, including Patient Access, Provider Access, Payer to Payer and Prior Authorization interfaces built on FHIR, with main compliance dates in January 2027. Confirm your specific obligations with counsel.
The practical question now is whether your core vendor's offering covers your prior authorisation workflow, which usually lives in a separate utilisation management system. Discovering that gap late leaves no room to close it.
We are an administrator with 25,000 members. Does any of this apply?
Mostly not yet. Buy the core and buy the surrounds, because your differentiation is in service and network rather than software and a build's fixed cost will not amortise across your membership.
The exception worth considering early is reporting and reconciliation. Administrators are judged on answering an employer group's question quickly, and packaged reporting is rarely shaped like the questions clients actually ask. That is a far smaller piece of work than a regression harness or a settlement engine.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
Will a custom ERP scale as we grow from 50 to 500 employees?
Yes, if it is designed for that from the start, which mostly means clean database design, permissions that handle new departments, and modules that stay separable. Adding users to software you own costs nothing in licenses, the opposite of the per-seat scaling penalty on NetSuite or Dynamics. What does need budget as you grow is new modules and integrations, so keep a small standing development arrangement rather than restarting a vendor search every two years.
What questions should I ask a development agency on the first call?
Ask who exactly will build it, what happens when scope changes mid-project, what their maintenance terms are after launch, and what they will need from you every week. Then ask them to describe a project that went wrong and what they changed afterward; teams that have shipped at real volume have war stories, and teams claiming a perfect record are hiding something. The scope-change answer matters most: a disciplined shop describes a written change-order process, not a vague promise to be flexible.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
What tech stack should a custom ERP be built on?
A boring, hireable one: Digital Heroes most often ships ERPs on PostgreSQL with a Node.js or Python backend and a React frontend, hosted on AWS or Azure. The stack matters far less than the database design, because your ERP schema will outlive every framework choice. Be skeptical of any agency proposing a niche or proprietary framework, since your ability to hire maintainers later is part of the total cost.
Why do companies replace NetSuite with custom software?
The three reasons we hear most at Digital Heroes are per-user license growth, SuiteScript customizations that became fragile, and workflows the platform cannot model without workarounds. A company adding 50 users to NetSuite takes on roughly $59,000 per year in extra licenses at the commonly quoted $99 per user rate, which is often the moment the custom math starts winning. Replacements usually keep the accounting structure intact and migrate module by module.
What should I prepare before contacting an ERP development agency?
Bring a list of your current tools and spreadsheets, a rough map of how an order or job moves through the company today, your user count by role, and the three problems costing you the most hours. You do not need a formal specification; a good agency writes that with you during discovery. Companies that arrive with those four things typically cut two to three weeks off scoping in our experience.
How much does a custom ERP cost for a small business?
A small-business ERP covering two or three core modules typically runs $40,000 to $120,000, with inventory, ordering, and accounting sync being the usual starting set. Across 2,000+ Digital Heroes projects, integration count and user roles drive cost far more than screen count. A full mid-market ERP with six or more modules usually lands between $150,000 and $400,000.
Who can build a custom ERP software system?
Digital Heroes builds custom ERP software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other ERP software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Eleanor.
Senior Partnerships Manager · New-york · 5 posts on the site
Published · Last updated .
