Code, Cash, and Chaos: Building Software That Survives the Policy Makers

My neck still hurts from staring at my monitor yesterday at a Gbagada workstation, trying to fix a routing bug while the generator outside hummed its usual erratic rhythm.

Between waiting for NPM packages to install and battling a spotty internet connection, I scrolled through the morning news. A headline about Trump’s $100 million IRS penalty suddenly "melting away" due to a tax settlement caught my eye.

It didn't make me think about politics. It made me shudder at the sheer, unadulterated nightmare of writing the backend logic for that system.

Can you imagine being the software engineer tasked with maintaining the codebase for tax audits and financial calculations when rules can literally evaporate overnight?

In our own backyard, we deal with this daily. One day you are writing clean, straightforward payment flows, and the next, a new directive drops from the Central Bank, or a sudden "cybersecurity levy" is announced, paused, and then re-evaluated. If your code isn't built to bend, it will snap. And when financial code snaps, people lose money, and your support channel turns into a war zone.

The Danger of Hardcoded Assumptions

Early in my career, I was naive. I would write financial calculations directly into my database queries or hardcode tax percentages right inside my controller files. Something like:

const charge = amount * 0.075;

It felt simple. It worked. Until the VAT rate changed, or a specific category of merchants got exempted, or a new flat-rate stamp duty was introduced. Suddenly, I was doing a global search-and-replace across five different microservices, praying to God I didn't miss a spot and break the checkout flow for thousands of users.

If you are building any product that handles money—whether you are working out of a quiet room in Jos or hustling with a small team in Onitsha—you have to assume the rules will change tomorrow. The "No gree for anybody" mindset applies to your architecture too. Do not let shifting regulations ruin your weekend.

How I Build for the Pivot

These days, I treat regulatory rules like external API data. They do not belong in the core application logic.

Here is my approach for keeping things modular:

1. The Rules Engine Pattern: Instead of writing nested if-else blocks for country-specific taxes or local government levies, I use a basic rules engine. I store tax rates, transaction limits, and processing fees in a PostgreSQL database using JSONB columns. This lets us query complex, nested rule structures without restructuring the database schema every time a politician signs a new bill.

2. The Dry-Run Pipeline: Before any transaction finalizes, it passes through a calculation pipeline. This pipeline fetches the active ruleset based on the timestamp, the user's location, and the transaction type. If a rule changes at midnight, we just insert a new row in the database with a start date. The code doesn't change; it just pulls the new active record.

3. Feature Flags as Shields: If a new policy is announced but might get suspended due to public backlash (which happens more often than we care to admit), we wrap the entire logic in a feature flag. If things go sideways, we toggle it off in one click from a dashboard instead of rushing a hotfix deployment while sweating through our shirts.

Execution Over Perfection

Building this way takes a bit more time upfront. It feels like over-engineering when you are just starting out and trying to find product-market fit. But the moment you have to pivot because of a sudden policy shift, you will thank your past self.

We can't control what happens in the senate, the central bank, or the tax offices. But we can control how gracefully our servers handle their decisions. Keep your core logic pure, separate your state from your rules, and keep building.