Engineering Public Sector Software That Passes an Audit

Public sector software engineering is not harder because the domain is complicated. It is harder because every decision you make becomes evidence. An auditor will look at your data handling, your access controls, your calculation logic, and your deployment pipeline. If you cannot show your work, the product fails regardless of whether it functions correctly. That is the constraint that shaped how I built OptimalTax, an automated tax returns platform that reached 99% tax calculation accuracy in production.

The audit trail is an architecture decision, not a logging afterthought

Most teams add logging late. They instrument the happy path, ship, and then retrofit observability when something breaks. On a tax platform, that order is inverted. Before I wrote a single calculation function, I defined what an auditor would need to reconstruct any result independently. That meant event sourcing at the calculation layer, not just application logs. Every input, every rule version applied, and every output is stored as an immutable record with a timestamp and a correlation ID.

The practical consequence is that the data model is larger than it needs to be for the user-facing product. That is a deliberate trade-off. A citizen should be able to file a return. A tax authority should be able to reproduce that return from first principles three years later. Both requirements live in the same system, and they pull in different directions.

Rule versioning is the problem nobody scopes correctly

Tax law changes. Rates change, thresholds change, deduction categories change. A naive implementation embeds these values in application code or a configuration file and redeploys when the rules change. That works until a user amends a return filed under a previous rule set, or an auditor asks why a 2024 calculation differs from a 2026 one.

I solved this by treating fiscal rules as versioned data entities, not configuration. Each rule set carries a validity window. The calculation engine selects the applicable version based on the filing date, not the current date. Amending an old return re-runs the original rule set. The system never loses the ability to reproduce historical results, because the rules that produced them are still in the database.

This is not a novel pattern. It is standard practice in financial systems. The mistake I see on public sector projects is that teams know the pattern exists but do not scope the migration path. You need to decide early whether you are migrating legacy rule definitions into the new model or running parallel systems during transition. On OptimalTax, we migrated. The parallel-system route creates consistency risks that are worse than the migration cost.

Secure development attestation is now a procurement requirement

Under CISA guidelines enforced throughout 2025 and 2026, software vendors selling to US federal agencies must submit a Secure Software Development Attestation Form certifying compliance with NIST SP 800-218. That is not a box-ticking exercise. It requires demonstrable evidence of threat modelling, secure coding practices, and a verifiable software supply chain.

I build to this standard regardless of whether a specific client requires the form. The reason is practical, not ideological. A platform that can pass NIST SP 800-218 scrutiny is also a platform that will survive a procurement review in the UK, a GDPR audit in Germany, and a data protection assessment in Cameroon. The constraints converge. Dependency pinning, signed commits, static analysis in CI, and documented threat models are not overhead. They are the minimum viable security posture for any regulated platform.

For the Financial Services Platform I built in the fintech sector, the same discipline produced a 30% reduction in response times partly because removing unvetted dependencies also removed bloat. Secure supply chain hygiene and performance are not in tension.

Access control must reflect the real permission model, not a simplified one

Citizen-facing government services have at least three distinct actor types: the citizen, the case worker, and the auditor. Each needs a different view of the same data. The citizen sees their own records. The case worker sees records they are assigned to, with write access scoped to active cases. The auditor sees read-only access to a defined subset, with every access logged.

The failure mode I have seen on inherited codebases is role-based access control that was designed for two roles and then stretched to cover five. You end up with boolean flags, middleware exceptions, and permission logic scattered across the service layer. It becomes impossible to reason about what a given actor can actually do.

I model permissions as a first-class domain concept from the start. Each permission is explicit, named, and attached to a resource type and an action. The access control layer is a single, testable module. When the permission model changes, there is one place to change it, and the test suite tells you immediately if you have broken an existing boundary.

What a production-ready public sector codebase looks like in practice

The things that distinguish a regulated platform from a standard web application are mostly invisible to the end user. They show up in code review, in the deployment pipeline, and in the incident response runbook.

On a platform built to this standard, you will find:

• —Immutable audit records written before the user-facing response is returned
• —Versioned rule entities with explicit validity windows
• —Dependency lock files committed and verified in CI
• —Threat model documentation updated alongside feature changes
• —Access control as a testable domain module, not middleware flags
• —Runbooks that specify exactly what an on-call engineer does when a calculation discrepancy is reported

None of these are exotic. They are disciplined application of patterns that exist in the engineering literature. The difficulty is doing all of them consistently, under deadline pressure, when a product manager is asking why the feature is taking longer than the estimate.

The answer I give is that the extra time is not gold-plating. It is the cost of building something an auditor can inspect without finding surprises. A platform that fails a compliance review costs far more to remediate than it would have cost to build correctly.

The engineering record is open if you want to look at it

The OptimalTax case study is one data point. The work index covers the full range: fintech, SaaS, AI products, design systems, corporate delivery. If you are assessing whether this kind of build is real, the engineering lens goes deeper into architecture, stack choices, and the trade-offs I make and why.

If you are evaluating a vendor or a technical approach for a regulated platform, that is exactly the conversation I am set up to have. The contact form is the direct route.