When I first started working on my software platform, I imagined the core of the system as a single, elegant calculator. The logic seemed simple enough: take a few inputs, apply some business rules, return a result. But as I dug deeper into the real-world rules I needed to model, I quickly realized something: I’m not building one calculator. I’m building fifty.

Each jurisdiction — in my case, each U.S. state — operates under its own unique framework. What counts as a valid rule in one state might be completely irrelevant in another. Even basic concepts like “how long you have to act” or “when the clock starts ticking” vary wildly depending on where you are.

The Illusion of Uniformity

At the surface, many rule systems look the same. You assume you’ll just have to deal with a few variations in terminology or maybe a couple of edge cases. But once you start reading the fine print, it hits you: the edge cases are the system.

For example, one jurisdiction might say the timer starts on the date of the incident. Another might add a “discovery rule,” allowing extra time if the issue wasn’t known right away. Some include hard deadlines, even if the problem was discovered late. Others carve out special exceptions based on profession, location, or relationship between the parties involved.

The Shift in Thinking

This forced a shift in how I think about architecture. I couldn’t build a generic engine that applied rules equally across all states. Instead, I had to acknowledge that each jurisdiction was essentially a self-contained rules engine — a little program of its own with its own logic, exceptions, and calculations.

That means my platform isn’t hosting one calculation engine. It’s hosting 50 — one per state. And possibly more, if you account for local, federal, or cross-border differences.

The Engineering Response

From a technical standpoint, that’s a different beast. It requires:

A shared structure for inputs (I call this SearchCriteria) A clean way to route requests based on jurisdiction A rule system that’s modular, testable, and easy to extend A way to encode exceptions and edge cases without cluttering the core logic

I’ve chosen South Carolina as my pilot state. It’s where I live, and I’m already familiar with some of its legal patterns. Starting there gives me a concrete case to work with as I figure out how best to structure the others.

Why This Matters

This isn’t just about law. Any system that models real-world regulations, compliance standards, or region-specific rules will eventually run into the same challenge. Uniformity is a comforting illusion — but if you design for it, your app will fall apart under the weight of real complexity.

Instead, embrace the differences early. Design for change. And expect to build more than you thought you would.

Coming Thursday: I’ll be sharing how I structured the SearchCriteria class to keep user input clean and logic-specific code isolated. The goal? Modularity and long-term sanity.

About Me

I’m Paul A. Jones, Jr., a developer and founder building in public.

After years in consulting, I’m launching my own software company to solve complex, rule-based problems in law and beyond. I write about bootstrapping SaaS, domain-driven design, C# and .NET development and the real challenges of turning professional workflows into software.

If you’re into system architecture, legal tech, or the startup grind from a developer’s POV, my blog is for you.

📬 Subscribe to the blog: PaulJonesSoftware.com

🐦 Follow along on Twitter/X: @PaulAJonesJr

🔧 Building in public. No fluff. Just real dev work, every week.