When you’re building specialized software, there’s always a point where the old way of doing things starts to buckle under the weight of new requirements. For me, that point came when I realized I couldn’t keep hardcoding new calculators into the system.

From Hardcoding to Dynamic Instantiation

At first, each calculator was wired in by hand. If I needed a South Carolina personal injury calculator, I had to do something like this:

var calculator = new SCPersonalInjuryCalculatorUtility();
var result = calculator.CalculateDeadline(…);

It worked, but the approach had obvious flaws. Every time I added a new calculator, I had to edit core code, duplicate boilerplate logic, and recompile the entire system. Scaling that way was going to be painful.

The breakthrough came when I realized I could store the calculator’s fully qualified class name in the database and let the system resolve it at runtime. Now, the pattern looks like this:

string className = repository.GetCalculatorName(caseTypeId, jurisdictionId);
var calculator = CreateCalculator(className);
var result = calculator.CalculateDeadline(…);

Instead of hardcoding, I have a helper method that does three things:

private ICalculatorUtility CreateCalculator(string className)
{
string assemblyName = "StatutePro.Calculator";
string fullTypeName = $"{className}, {assemblyName}";

Type calculatorType = Type.GetType(fullTypeName) 
    ?? throw new InvalidOperationException($"Type {fullTypeName} not found.");

object instance = Activator.CreateInstance(calculatorType)!;

if (instance is not ICalculatorUtility utility)
    throw new InvalidCastException($"{fullTypeName} does not implement ICalculatorUtility.");

return utility;

}

This helper does all the heavy lifting:

1. Retrieves the calculator’s class name from the database.
2. Resolves the type dynamically with reflection.
3. Guarantees that the new object implements ICalculatorUtility.

In practice, it feels a lot like working with generics. The <T> in my solution is the calculator, and the shell takes care of everything else — logging, auditing, deadlines logic, and error handling.

Understanding the Process: Dynamic Instantiation with Reflection

Check out the flowchart below, which breaks down the process of dynamic instantiation with reflection on my legal deadline platform. From retrieving the fully qualified class name from the database to instantiating the calculator at runtime using Type.GetType and Activator.CreateInstance, this visual guide illustrates the seamless transition from hardcoding to a scalable, flexible solution.

Why This Matters

This pattern unlocked three immediate benefits:

• Seamless rollout: I can add or remove calculators live with minimal user impact.
• Centralized logic: The shell handles all the cross-cutting concerns, so each new calculator only contains the unique rules.
• Scalability: The system now supports tenant-specific calculators, exclusivity windows, and usage tracking — features that would have been nearly impossible under the old model.

And there’s a bigger, more surprising benefit too: this approach lays the groundwork for an app store for legal deadlines.

You’ve Built a Marketplace Without Realizing It

Because calculators are now dynamically resolved, I don’t need to ship them all myself. Any qualified expert could contribute one — a law professor specializing in securities law, a litigation boutique that wants a medical malpractice calculator, or even a compliance consultant writing niche regulatory calculators.

The system doesn’t care who wrote the calculator. As long as it implements the interface, the platform can load it. That’s the definition of a marketplace.

• Contributors build calculators.
• The platform hosts and manages them.
• Users “install” (or subscribe to) the ones they need.
• The business takes a cut.

This isn’t just extensibility. This is the foundation of a legal deadline app store.

Monetization Possibilities

Dynamic instantiation transforms monetization from flat licensing into tiered, usage-based, and marketplace-driven models:

• Pay-per-use: Usage counters tied to each calculator (already wired in via CalculatorUsage) make metered billing trivial.
• Premium exclusivity: A tenant can have a custom calculator available only to them for a set period.
• Revenue sharing: External experts could list calculators for sale, with the platform taking a percentage.
• Analytics dashboards: Usage data feeds directly into client-facing dashboards showing activity, trends, and risk exposure.

In other words: the same technical decision that solved my scaling problem also unlocked new revenue levers.

Operational Advantages

Beyond monetization, the pattern improves day-to-day operations:

• Hot-swap capability: A buggy or outdated calculator can be disconnected instantly without downtime.
• Rapid rollout: New calculators can go live without code changes or redeployment.
• Centralized debugging: Core logic stays in the shell, so any issues are fixed once and propagate everywhere.

That’s a massive efficiency gain when the system grows from a handful of calculators to hundreds.

Next Steps

The foundation is now in place. The next steps are:

• Formalize the factory API so it’s production-ready.
• Build tooling for publishing and managing calculators (versioning, testing, approvals).
• Explore pilot programs with external experts to test the marketplace model.
• Wire up detailed usage tracking for both global Count and per-tenant CalculatorUsage.

It’s rare when a single technical pattern reshapes both the product roadmap and the business strategy. Reflection did that for me.

This approach doesn’t just solve a technical problem — it opens the door to scalable growth, new revenue models, and operational resilience.

About the Author

My name is Paul A. Jones Jr., and I am a software engineer and legal tech founder developing tools for professionals in law and other regulated industries. I write about systems thinking, modern workflows, and SaaS applications at PaulJonesSoftware.com. Follow me on Twitter: @PaulAJonesJr.