.png)
"How hard could it be?" - the question that costs $1.5M to answer
Sarah, CTO at a $1.8B GWP P&C carrier, told me last quarter she had two senior Java engineers convinced they could build the company's underwriting rules engine in six months. "We just need decision tables and a REST endpoint," the lead engineer had told her. "How hard could it be?"
I asked her to let me sketch what "just decision tables and a REST endpoint" actually means at a mid-market insurance carrier scale. Forty-five minutes later, we had a whiteboard with 23 components: rule parser, expression evaluator, type system, fact-base storage, conflict resolution, rule chaining detection, versioning, branching, dependency graph for change impact analysis, decision-table UI, validation framework, test harness, simulation runner, audit log, RBAC, multi-tenancy, REST and Java SDK, performance monitoring, observability, deployment tooling, CI/CD integration, NAIC examination support, and disaster recovery. The two engineers' faces changed somewhere around component twelve.
In my experience, the build-versus-buy conversation for rules engines is the single most expensive decision a mid-market carrier or bank makes in the BRMS evaluation phase - because the cost of the wrong call is not the license fee saved, it is two years of executive attention and $1.5M to $2.5M of engineering effort that should have gone to building competitive products.
This article is for the architect or CTO weighing build versus buy. I cover what you actually need to build (component inventory most teams underestimate), the honest engineering cost in 2026 dollars, the ongoing maintenance burden after launch, a 9-question decision framework, and four cases where I tell prospects that building still makes sense. Skip to Section 6 if you want the framework; Section 7 is where I admit when build wins.
Should you build or buy a rules engine? (Direct answer)
For 90-95% of mid-market insurance carriers, banks, and healthcare payers, buying a commercial BRMS is the correct decision. Building a production-grade rules engine requires 2-3 senior Java engineers full-time for 12-18 months ($1.5M to $2.5M total cost), plus 1-2 engineers ongoing for maintenance ($400K-$700K per year). The math only works in your favor in four specific cases:
(1) you already employ a stable team of rules-engine specialists for unrelated reasons,
(2) your domain is so unusual no commercial product fits,
(3) the rules engine itself is your product, or
(4) regulatory or sovereignty requirements explicitly forbid commercial software.
Outside these cases, a modern proprietary BRMS like Higson delivers 40-60% lower 5-year TCO with implementation time measured in weeks rather than years.
Why "build your own" sounds tempting (and why those reasons usually fall apart)
In every build-versus-buy conversation I have had, the same five arguments come up. They are all reasonable on the surface. They mostly do not survive contact with production reality.
Argument 1: "We need full control and customization"
True for the first six months. Then the carrier discovers that the customization they were defending was "we want the rule editor to be teal instead of blue." The actual business logic - decision tables, calculation flows, eligibility rules - is the same shape at every mid-market carrier I have worked with. Commercial BRMS already gives you that shape and lets you change the data inside it. The teal-vs-blue customization comes at the price of building and maintaining the entire stack.
Argument 2: "It's just an if-then evaluator. How hard can it be?"
This is the question I quoted Sarah's engineer asking. The actual answer is that production-grade rule evaluation requires a parser, an expression language, type coercion, conflict resolution (what fires when two rules match), execution ordering, salience handling, forward chaining detection, infinite-loop guards, decision-table interpretation, and a test harness that can replay historical decisions. Each of these is a 2-6 month engineering project on its own. Martin Fowler wrote about exactly this trap years ago - that "easy to set up, very hard to maintain" is the consistent failure mode of homemade rule systems.
Argument 3: "Open source like Drools is free, so building is free-ish"
Drools is not free. Drools' source code is free; running Drools in production costs you 2-3 senior Java engineers full-time, $200K-$500K in custom tooling to give business analysts a usable interface (Drools Workbench is engineer-oriented), plus rule-change cycle time measured in sprints rather than days. Honest 5-year Drools TCO at a mid-market carrier sits at $2.5M-$4M, per my colleagues' analysis in the Higson Pillar Main article on rules engines. "Free" software is the most expensive software in the BRMS category, and that is before you start building wrapper tooling.
Argument 4: "Our developers like building things"
They do. They will also like building things that are not rules engines - things that actually differentiate your insurance product, your claims experience, your underwriting models. Time spent building infrastructure that ten commercial vendors already sell is time not spent on the things your competitors cannot copy.
Argument 5: "We will save money on license fees"
Maybe. The Higson AWS Marketplace license is $0.63 per hour - roughly $5 500 per year for a single instance, $30K-$80K for a typical mid-market production deployment. Saving $50K per year on license fees while spending $400K-$700K per year on a maintenance team is not saving money - it is reallocating it from "vendor invoice line we can negotiate" to "engineering headcount line we cannot easily reverse."
What you would actually need to build (the component inventory most teams underestimate)
Here is the production rules engine component inventory. I have built this list with carriers in the whiteboard exercise I described in Section 1. It is the list of components a credible rules engine needs to be production-ready, not a wish-list.
Total engineering effort: 31-49 engineer-months for v1. Assuming a team of 2-3 senior Java engineers working in parallel, that translates to 12-18 calendar months of dedicated work. At a fully loaded senior Java engineer cost of $200K-$280K per year (US 2026 rates), that is $400K-$700K per year per engineer. Across the team and timeline: $1.5M to $2.5M for v1.
And that is v1. The list above is what gets you to feature parity with what a commercial BRMS offers out of the box on day one.
The maintenance burden nobody calculates upfront
The $1.5M-$2.5M build estimate is the easy half. The harder half is what happens after launch. Software does not finish; it just changes hands. Here is what the post-launch maintenance burden looks like in practice.
Specialist scarcity
Rules engines are niche. A senior Java engineer who deeply understands rule-evaluation theory, decision-table semantics, conflict resolution, and the production patterns around all of it is rare. I've worked with carriers who built their own engine and then could not find replacements when the original team moved on. The remaining team becomes a single point of failure for an entire business-critical system.
Continuous regulatory load
NAIC Model Bulletin on AI Use in Insurance updates; state DOI examination patterns shift; new federal-level requirements (No Surprises Act, ECOA Reg B fairness testing) periodically demand new audit-log fields and new decision-explanation capabilities. A commercial vendor absorbs that work across hundreds of customers. Your in-house team absorbs it for one customer. The math does not improve over time - it worsens.
Security maintenance
Every dependency in your stack will have a CVE. Every CVE in a system that fires consumer-facing pricing or eligibility decisions is potentially a compliance event. Patching, regression-testing, and re-deploying a custom rules engine is a quarterly tax that has nothing to do with business value.
Feature drift from market
In 2024, ONNX integration in rules engines was a curiosity. In 2026, it is table stakes for any carrier doing hybrid AI / rules patterns. In 2027, MCP server integration (Higson's USP today) will become an expected feature for AI-agent-driven rule editing. Custom engines fall behind the commercial market on each new feature unless you actively keep up - which is more engineering investment for no competitive advantage.
Honest ongoing cost
Realistic steady-state maintenance for a custom rules engine at a mid-market carrier: 1-2 senior engineers full-time, $400K-$700K per year. Over a 5-year horizon: $2M-$3.5M, on top of the $1.5M-$2.5M build cost. Total custom-engine TCO: $3.5M-$6M over 5 years.
For comparison, a Higson commercial BRMS deployment at the same carrier: $50K-$200K per year license plus 3-6 month implementation engagement. Total 5-year TCO: roughly $1M-$1.5M. That is 60-75% lower than building, with implementation measured in months rather than years and the vendor absorbing the ongoing roadmap.
Buy vs build decision framework: 9 questions for the architect
Here is the framework I run with Sarah-level CTOs and Daniel-level architects in RFP scoping meetings. The questions are ordered from cheapest to answer to hardest. If you hit three or more "build" answers in questions 1-6, then questions 7-9 become the deciding ones.
- Do you already employ 2-3 senior engineers with deep rules-engine experience (Drools, Camunda, FICO Blaze, InRule, custom) committed to your roadmap for the next 5 years? If no -> buy.
- Is rule-change cycle time (idea to production) a competitive differentiator in your market? If yes and you do not have a no-code authoring layer story -> buy.
- Is your domain genuinely unusual (e.g. specialty reinsurance, ITAR-regulated, sovereign-cloud-only)? If unusual enough that no commercial product fits -> consider build. If standard P&C, life, health, banking, retail -> buy.
- Do you need NAIC-grade audit trail and state DOI examination support? Commercial BRMS includes this; custom requires 3-6 months of engineering to match. If yes -> lean buy.
- Do you need ONNX / ML model integration inside rules (hybrid AI patterns)? Commercial BRMS like Higson include this; custom requires significant ML-infra investment. If yes -> lean buy.
- How many distinct rule-authoring stakeholders (BAs, actuaries, product managers, compliance) need access? If more than 3 different stakeholder types -> buy (the authoring UI cost dominates).
- Is your 5-year horizon stable enough that you can commit to a permanent rules-engine maintenance team? If team stability is uncertain -> buy.
- Can you tolerate 12-18 months before the engine is in production? If you need a working rules platform in under 6 months -> buy.
- Is the rules engine itself your differentiator (you sell rules-engine-as-a-product to your customers)? If yes -> build. If no (rules engine is internal infrastructure) -> buy.
In my experience, the carriers who get this decision right run through this list in writing, not in a meeting. The temptation to choose build is strongest in the room with engineers who like the challenge. The temptation to choose buy is strongest in the room with CFOs who like predictable costs. Neither pressure is the right frame - the frame is whether the rules engine is your moat or your plumbing.
When building still makes sense (the honest cases)
I would rather lose a deal than win one badly. There are four cases where I tell prospects build is the right answer - sometimes Higson is not the fit, sometimes nothing on the market is the fit. The honest paradox of transparency:
Case 1: You already have the specialist team and they have nothing else to do
If you employ 2-3 senior Java engineers with deep rules-engine background for unrelated reasons (perhaps they came over in an acquisition, perhaps they are subject-matter specialists in a niche domain), and those engineers do not have higher-priority work to do, then the marginal cost of having them maintain a custom engine is closer to zero than the cost of paying a commercial license. This is rare but not unheard of - I have seen it twice in 20 years.
Case 2: Truly unusual domain where commercial products do not fit
Sovereign-cloud-only deployments where commercial BRMS cannot be hosted. ITAR or classified environments. Highly specialized verticals (specialty reinsurance covering exotic risks, niche derivatives trading). If a domain expert reviews the top 5 commercial BRMS and concludes that none of them model the specific concepts you need - and they have done that review with intellectual honesty - then build can be the right answer.
Case 3: Rules engine is your product
If you are building a SaaS product whose core value proposition is the rules engine itself - if you intend to compete with Higson, Drools, Camunda - then you need to own the technology. This is the InsurTech founder building a new BRMS for healthcare payers. Buying a BRMS to white-label and resell is rarely the right model.
Case 4: Volumes far above commercial product ceilings
If your throughput requirements genuinely exceed what any commercial product can deliver (50 000+ sustained req/s with sub-millisecond P50 latency on rules of meaningful complexity), then custom development optimized for your specific workload may be warranted. This is rare - I have seen it credibly claimed at maybe one or two carriers nationally - but it is real.
Outside these four cases, the build decision is usually a story your engineering culture is telling itself. The story sounds like "we have unique requirements" or "we want full control," but underneath, the comparison is between a commercial BRMS with a complete feature set on day one and a custom engine that will be in production in 18 months with a partial feature set and a permanent maintenance team.
Where Higson fits in the buy decision
Higson is built for the mid-market segment specifically - $500M-$5B GWP P&C carriers, $1B-$20B AUM banks, mid-size healthcare payers. The decision to buy from us versus from Drools, Camunda, FICO Blaze, InRule, or IBM ODM is a different question (covered in our BRE Comparison Guide). The decision to buy versus build is the one this article addresses. Where Higson tends to fit well:
- Insurance-native design. Decerto has 20+ years and 200+ insurance implementations behind Higson. The decision-table primitives, audit trail format, and product-configuration concepts map cleanly to insurance vocabulary.
- Sub-millisecond execution at mid-market scale. 0.23 ms typical P50, 9 000 sustained req/s. Above mid-market peak load - Notus Finance migrated from Drools and now runs 100 000 calculations in 8 seconds (vs 14 in Drools).
- No-code Higson Studio for the Linda BA persona. Authoring decision tables visually, running UAT against historical quote data, deploying without a code release - this is the layer custom-built engines almost never get right.
- ONNX runtime native for hybrid AI / rules. Run an ML model trained in PyTorch or TensorFlow inside the same decision flow as deterministic rules - one decision, two information sources, one audit record.
- AWS Marketplace at $0.63 per hour for PoC. Run your first rule in 15 minutes, no commitment. Costs less than the coffee budget while you evaluate.
Where Higson is not the fit: rule sets under 50-100 rules with no audit requirement, pure BPMN workflow problems (Camunda territory), enterprise scale beyond 50 000 sustained req/s (InRule / IBM ODM territory), or .NET-only shops where Java is a non-starter.
A real-world build attempt I worked on (anonymized)
This is the build-attempt story I bring up in build-vs-buy conversations. Names changed; the carrier and outcome are real.
In 2021, a $1.4B GWP mid-Atlantic specialty carrier decided to build their own rules engine for product configuration. Their argument: their specialty lines were too unusual for commercial BRMS to fit (Case 2 from Section 7). They committed three senior Java engineers and a Lead Architect (call him James), and budgeted 9 months.
Month 9 came with a working core engine but no UI - their Business Analysts were editing XML files in IntelliJ. Month 14 came with a serviceable UI but no versioning - rule changes were being tracked in Git commit messages by the BAs, who had become accidental developers. Month 22 came with versioning, basic UI, and the first state DOI examination, which turned up an audit-trail gap that took another 4 months to fix. By month 27, they had spent $2.1M in fully-loaded engineering time.
In month 30, James called me. They were re-evaluating Higson. The carrier had concluded - correctly - that their specialty lines were not actually more unusual than they had assumed. They were unusual in the front-end product presentation, not in the rule-evaluation requirements. Decision tables, eligibility logic, and pricing rules looked the same shape as every other carrier I had worked with. The build had been a $2.1M lesson in confusing front-end product complexity with back-end infrastructure novelty.
I recommended Higson because in my experience that combination - specialty lines, mid-market scale, multi-state - is exactly what we are built for. We migrated their rule set in 5 months. The custom engine they had built was decommissioned 9 months after that. They got the $2.1M lesson; you can get it for the price of reading this article.
FAQ
Should you build or buy a rules engine for your insurance carrier?
For 90-95% of mid-market insurance carriers, buying a commercial BRMS is correct. Build costs 2-3 senior Java engineers full-time for 12-18 months ($1.5M-$2.5M for v1), plus 1-2 engineers ongoing for maintenance ($400K-$700K/year). Total 5-year custom-engine TCO: $3.5M-$6M. Higson commercial BRMS at the same scale: roughly $1M-$1.5M 5-year TCO. Build only makes sense if you already employ the specialist team, your domain is genuinely unusual, the rules engine is your product, or you exceed commercial product ceilings on throughput.
How much does it cost to build a rules engine in-house?
Production-grade rules engine v1 requires 31-49 engineer-months across core evaluation, decision-table runtime, authoring UI, versioning, test harness, audit log, integration surface, performance optimization, and deployment tooling. At US 2026 senior Java engineer fully-loaded cost ($200K-$280K/year), v1 totals $1.5M to $2.5M over 12-18 months. Ongoing maintenance: 1-2 engineers full-time, $400K-$700K/year. 5-year total custom-engine TCO sits at $3.5M-$6M for a mid-market deployment.
What goes wrong when you build a custom rules engine?
The five most common failures: (1) underestimating the authoring UI - a Business Analyst-usable interface is 8-12 engineer-months on its own; (2) audit-trail gaps that surface during state DOI examination - typically 3-6 months to retrofit; (3) versioning and rollback complexity once multiple rate filings run in parallel; (4) specialist scarcity when the original team moves on - rules-engine expertise is hard to hire; (5) feature drift from market - by year 3, custom engines lag commercial products on ONNX, hybrid AI, MCP, and other newer capabilities.
Is it cheaper to use an open source rules engine like Drools?
Drools' source code is free, but Drools is not. Running Drools in production requires 2-3 senior Java engineers full-time ($500K-$800K annually), plus $200K-$500K in custom tooling to give Business Analysts a usable authoring interface (Drools Workbench is engineer-oriented). Honest 5-year Drools TCO at a mid-market carrier sits at $2.5M-$4M. A modern proprietary BRMS like Higson delivers the same use case at roughly $1M-$1.5M 5-year TCO, with the authoring UI included.
How long does it take to buy and implement a commercial rules engine?
Implementation timelines for commercial BRMS at mid-market scale: 3-6 months end-to-end for the first 5-10 high-volume decisions, including rule extraction from legacy code, decision-table modeling, shadow-mode testing, and production cutover. Higson typical timeline: 4-5 months for a $500M-$5B GWP P&C carrier. Compare to 12-18 months minimum for v1 of a custom build, with feature parity not reached until well past launch.
What does a production rules engine actually need to do?
Beyond if-then evaluation, a production rules engine needs: parser plus expression language, type system with coercion, conflict resolution and salience, forward-chaining detection with infinite-loop guards, decision-table runtime with hit policies, business-user authoring UI, versioning and branching, test harness with historical replay, audit log with NAIC-examination-grade detail, role-based access control, REST API and SDK, performance optimization for sub-millisecond execution, deployment tooling, and disaster recovery. Each is a 2-12 engineer-month project.
When does building a custom rules engine actually make sense?
Four cases where build still wins: (1) you already employ 2-3 senior rules-engine specialists committed to your roadmap with no higher-priority work; (2) your domain is genuinely unusual - sovereign-cloud, ITAR, niche specialty lines that no commercial product models; (3) the rules engine itself is your product - you are building a BRMS to sell or white-label; (4) throughput requirements exceed commercial product ceilings (50 000+ sustained req/s with sub-millisecond P50). Outside these four cases, build is rarely the correct answer.
What is the difference between building a rules engine and using one like Higson?
Building gives you full source ownership and complete customization but requires 12-18 months and $1.5M-$2.5M before v1 is in production, plus a permanent specialist team. Using Higson gives you a complete BRMS in 3-6 months at $50K-$200K/year license, with no-code authoring (Linda BA persona), NAIC-grade audit trail, ONNX runtime for hybrid AI patterns, and the vendor absorbing roadmap and security work across hundreds of customers. The trade-off: less code ownership, dramatically lower TCO and faster time-to-value.
Related reading
Talk to Higson
The build-versus-buy decision for rules engines is the single most expensive decision a mid-market carrier makes in the BRMS evaluation phase. Get it right and you have a competitive advantage on rule-change speed; get it wrong and you have an 18-month detour with a permanent maintenance team. In my experience, the carriers who get this right run the decision framework in writing, with concrete TCO numbers, before letting the engineering enthusiasm or the cost-cutting reflex take over.
If you are currently weighing build versus buy - or you are already 6-12 months into a build and second-guessing it - I would be happy to walk through the framework with your team. We can do this in an hour. I'll bring concrete numbers from the carriers we have worked with; you bring the spec your engineers wrote when they said "how hard could it be."
Three ways to start:
- Schedule a 30-minute build-vs-buy review - we will run the 9-question framework against your specific situation.
- Try Higson on AWS Marketplace at $0.63 / hour - faster than reading the rest of your engineering spec.
- Download the BRE Comparison Guide - 12 vendors, for the technical evaluator running the RFP.
Citations
- McKinsey & Company, "Building Workflow-Enabled Decisioning" - rule-change cycle time and TCO research.
- Gartner Hype Cycle for Decision Management Software (2025) - BRMS market context and TCO patterns.
- Forrester Wave: Digital Decisioning Platforms (Q1 2026) - vendor landscape for decision automation.
- Martin Fowler, "Rules Engine" - bliki essay on the maintenance pitfalls of homemade rule systems.
- Stack Overflow Developer Survey (2025) - US senior Java engineer compensation benchmarks.
- NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023, updated 2024-2025) - audit-trail requirements that custom engines must match.
- OMG Decision Model and Notation (DMN) Specification - standards a credible rules engine should implement.
- ONNX Runtime documentation - the AI integration pattern modern BRMS must support.
Take Full Control of Your Product Logic
We provide fee Proof Of Concept, so you can see how Higson can work with your individual business logic.
.png)
.png)
.png)