2026-04-13
121 tests before a single button
The problem sounded simple: given a team of people — some Canadian employees, some US W-2 workers, some contractors, some international hires on EOR — what is each person's delivery margin? Revenue minus the true cost of employment, including every statutory deduction, calculated correctly for each jurisdiction.
It's the kind of problem that looks like a spreadsheet until you sit down to actually build it.
The statutory cost logic alone has real complexity hiding inside it. CPP contributions stop once an employee crosses the annual maximum. So do EI premiums. The ceiling is different for each. The month the ceiling is hit is different for each person depending on their salary. A contractor has no statutory burden at all. A US W-2 employee has FICA instead of CPP and EI, with its own ceiling logic. An EOR hire has a flat overhead percentage because you're paying a service fee, not running payroll directly.
Each of those is a different function. Each function has edge cases. The mid-year hire who starts in October has already had a few months of contributions deducted before your model starts. The high-salary executive hits the CPP ceiling in February. The contractor who became a full-time employee mid-year needs to be handled at the point of status change, not as a full-year calculation in either direction.
I wrote the spec first. Every edge case named and documented before a single line of code existed. Then I wrote the tests. Then I wrote the code to make the tests pass.
121 tests. Every calculation independently verifiable from its inputs.
The working calendar question came up during testing. Available hours aren't just salary divided by twelve. They depend on how many working days are in the month. That depends on public holidays. That depends on the year — a holiday that falls on a weekend is observed on a different date. A model that ignores this produces utilisation figures that are subtly wrong in ways that compound over a year.
So the calendar became configurable. The model ships with a default Canadian working calendar. You can override any month — add a holiday, mark a company shutdown day, adjust the working day count. When you change the calendar, every number downstream re-runs immediately. The calculation doesn't care where the change came from.
The interface took a fraction of the time the engine did.
That's the thing most people get backwards. They build the UI first because it's visible, because it feels like progress, because you can show it to someone. Then the calculation gets bolted on later, and when it's wrong — and it's always slightly wrong at first — untangling the UI from the calculation is painful.
If you start with a pure function — inputs in, numbers out, no side effects — the interface is just plumbing. You wire the UI state to the inputs and display the outputs. The hard problems are already solved. The interface cannot make the calculation wrong because the calculation doesn't know the interface exists.
The analysis layer was the last piece. Once you have correct per-person numbers, the interesting question is how to slice them. By project — to see which engagements are carrying the team and which ones aren't. By client — to see where the profitable relationships are. By employment type — to understand the structural cost difference between a contractor model and an employee model. By role — to see what a senior resource actually costs versus what a junior one produces.
All of those views come from the same underlying data. The grouping logic is a parameter, not a different calculation. You can see any of them without re-running anything.
From spec to 121 passing tests to a working interface with Excel export: a few weeks of evenings.
That sounds fast until you account for what the tests bought. I changed the CPP ceiling logic three times before I was satisfied with how mid-year hires handled the proration. Each change took about two minutes to verify because the tests told me immediately whether anything broke. Without the tests, each of those changes would have required manually inspecting outputs across multiple scenarios to confirm correctness.
The investment in correctness is not a cost you pay before the good part. It is the good part. A number you can't verify isn't a financial tool. It's a guess with a nice interface.
There's a version of this tool that exists to impress people. Animated charts, a polished onboarding flow, marketing copy about "AI-powered insights."
That's not this.
This is a calculation engine that's correct. It handles the cases that professional services finance people actually run into. It exports a workbook that an auditor can follow. It has 121 tests that prove it does what it says.
If you're trying to understand whether a project is profitable down to the person, that's what you need. Everything else is decoration.