The product and context
An AI-agentic HR and payroll platform built for the realities of Pakistan. This case study focuses on one architectural decision, rather than claiming to document every part of the product.
My role
My contribution spans strategy, technical project management, qa and infrastructure. The decision described here is my first-person account of the direction I advocated. It is not a claim that I independently built every component of the platform.
The problem
Payroll rules change. Hardcoded compliance can turn a routine policy update into a risky software release.
The project needed to accommodate changing rules while keeping payroll behaviour understandable. The concern was not just how quickly a feature could be shipped, but how a future change would be reviewed and applied.
The options and tradeoffs
One approach is to encode the current rules directly in application logic. This can be straightforward to start, but couples policy changes to software releases. The alternative is to separate rule definitions from the code that evaluates them, with explicit versions and effective dates.
The decision
Treat compliance rules as versioned data rather than burying them in application code.
The system focus is:
- Versioned rules
- Payroll workflows
- Review & approval
- Auditable runs
What the design needs to protect
- Rule versions need clear ownership and review.
- Effective dates must determine which rule set applies.
- Historical runs need a record of the rules used.
- A data change still needs validation before it affects payroll.
These are design requirements and review questions, not a claim that a complete public audit has verified every control.
Delivery and verification questions
How would a reviewer trace a payroll result back to its rule version? What happens around an effective-date boundary? Can a past run be explained after a rule update? These are useful acceptance questions for delivery and QA.
The tradeoff
Versioning introduces ownership and validation work. The payoff is a clearer history of which rules apply to each payroll run.
Outcomes and evidence
This account establishes the problem, my reasoning and the design direction. It does not assert measured savings, performance improvements or a verified before-and-after result. Implementation artefacts, screenshots and measurements can be added when they are ready to share.
What I learned
A technical PM needs to understand the operating environment as carefully as the feature backlog.
The wider lesson is to connect the product’s operating constraints to the architecture and delivery plan. A decision is easier to evaluate when its assumptions, tradeoffs and verification questions are visible.