Why We Built a Rule Engine with Built-in Simulation

The Problem Nobody Talks About

Here's something I watched happen dozens of times during my 6 years as a backend engineer: a product manager walks over and says, "We need to change the discount threshold from $100 to $75."

Simple, right? Except here's what actually happens:

1. A developer writes the PR
2. Another developer reviews it
3. QA tests it (maybe)
4. It gets deployed to staging
5. Someone manually verifies a few cases
6. It goes to production
7. Everyone holds their breath

That last step — the breath-holding — is the real problem. Nobody knows what's going to happen. How many more customers will qualify for the discount? What's the revenue impact? Will it conflict with the VIP promotion that marketing launched last week?

The answer is always the same: "We'll find out in production."

Rules Are Not Code Problems

The deeper issue is that we've been treating business rules as code problems. They're not. They're business problems that happen to live in code.

When a pricing rule is hardcoded into a Spring Boot service, changing it requires the full software development lifecycle. But the business doesn't think in terms of PRs and deploy pipelines. They think in terms of "if the customer is VIP and the cart is over $100, give them 20% off."

This mismatch creates a bottleneck. Engineering becomes the gatekeeper for every business logic change. And because there's no way to preview the impact, every change carries risk.

What "Built-in Simulation" Actually Means

When we started building LexQ, the rule engine part was straightforward. Plenty of solutions exist for defining if-then rules and executing them via API. What none of them offered was the ability to see the impact before deploying.

Here's what simulation looks like in practice:

Dry Run — You write a rule, then test it with a single input: "If I send customer_tier=VIP, cart_total=100, what happens?" You see exactly which rules fire, which get blocked by conflict resolution, and what the output would be. All before publishing.

Batch Simulation — You take your last 10,000 real execution records and replay them against a new rule version. The result? A side-by-side comparison showing:

• Match rate changes (did more or fewer records match?)
• Metric deltas (how did total discount amounts change?)
• Per-rule statistics (which specific rules matched more or less?)

This is the equivalent of a staging environment for business rules. Except it uses real data, not test fixtures someone wrote six months ago.

A/B Testing for Rules

Simulation tells you what would happen. A/B testing tells you what does happen.

LexQ lets you split live traffic between two rule versions — say 90% to your current rules and 10% to a candidate. You measure real outcomes, then promote the winner. No code deploy required.

This is standard practice for frontend features (every SaaS company A/B tests their UI), but almost nobody does it for business logic. Why? Because most rule engines don't support it. The concept doesn't even exist in frameworks like Drools or OPA.

The Architecture Decision

We deliberately chose to build LexQ as a managed API, not a library you embed in your application. Here's why:

When rules live inside your application code (even if managed by a rule engine library), you still need to deploy your application to change them. The rule engine might separate the definition from the code, but the deployment is still coupled.

LexQ decouples all three: definition, execution, and deployment. You define rules in the console, test them with simulation, and deploy them with one click. Your application just calls the API.

curl -X POST https://api.lexq.io/api/v1/execution/groups/{groupId} \
  -H "x-api-key: sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"facts": {"customer_tier": "VIP", "cart_total": 100}}'

The response tells you which rules matched, what actions to execute, and provides a full trace for debugging.

Who This Is For

LexQ isn't for everyone. If your business rules change once a year and are simple enough to manage with a few if-statements, you don't need a rule engine.

But if you recognize any of these patterns, you probably do:

• Your team deploys code every time a business rule changes. Pricing thresholds, eligibility criteria, fee calculations — every tweak requires engineering effort.
• Nobody knows the impact until production. You've been burned by a rule change that looked harmless but affected thousands of transactions.
• Business logic is scattered across services. The "real" rules exist in Slack messages and spreadsheets, not in any single source of truth.
• Product and ops teams wait weeks for changes that should take minutes. The backlog is full of "change this threshold" tickets.

What We're Building Next

LexQ is live today with the core feature set: visual rule builder, Git-style versioning, pre-deploy simulation, A/B testing, and a 55-tool MCP server for AI agent integration.

We're focused on getting this right for the first set of customers before expanding. If you're interested in trying it out, the free tier includes 1,000 executions/month — enough to validate whether it fits your workflow.

→ Start free at lexq.io → Read the docs at docs.lexq.io → CLI & MCP server on GitHub