CASE STUDY · ENTERPRISE SOFTWARE · COMPLIANCE ENGINE

Compliance SaaS backend development: two years at the core of RatesCalc

Some software is allowed to be approximately right. A compliance engine is not. From 2022 to 2024 I contributed heavily to the backend API services at the core of RatesCalc, an Australian wage-rate and charge-rate compliance SaaS where every number the system produces has to survive scrutiny.

The domain problem: two constraints pulling in opposite directions

RatesCalc answers a question that sounds simple and isn't: what should a person be paid, and what should the client be charged for their time? The two numbers are chained together, and each carries its own hard constraint. The pay rate must be compliant: correct under the Australian rules that govern what workers are owed. The charge rate must be profitable, high enough that the business quoting it actually makes money after every cost that sits between the two figures.

Get the first one wrong and you've built an underpayment machine with an audit trail pointing straight at it. Get the second one wrong and you've built a very compliant way to lose money on every placement. The product's entire value is holding both constraints at once, for every rate, every time: compliant on one side, profitable on the other, nothing in between left to guesswork.

The calculation engine: why this is harder than a spreadsheet

Businesses in this market historically ran on spreadsheets, and the spreadsheet is exactly the failure mode a compliance engine exists to replace. A spreadsheet gives you a number without the reason for the number. In this domain, correctness means more than arithmetic:

• Rule complexity. Australian pay compliance is far more than one rate. It's a web of conditions where the applicable rules depend on who is doing the work, when, and under what arrangement, and the engine has to encode that branching logic explicitly rather than bury it in cell formulas only one person understands.
• Auditability. A rate that can't be explained can't be defended. Every output has to be traceable back to the inputs and rules that produced it, because the question rarely stops at "what's the rate?" Eventually it becomes "prove it."
• Consistency at SaaS scale. One spreadsheet drifts; hundreds of copies of it diverge. A single backend calculation engine means every user gets the same answer to the same question, and a rule change propagates once, centrally, instead of through a thousand emailed attachments.

That is the engineering substance of the backend APIs I contributed to: a calculation core where the rules are data the system reasons over instead of folklore embedded in formulas.

From numbers to paper: the document pipeline

A compliant rate that stays inside the system is only half a product. RatesCalc carries the calculation through to the artifacts a business actually transacts with: quotes, schedules, agreements, and contracts, generated from the same rate data that the engine computed. That chain matters more than it looks. The moment a human re-types a calculated rate into a contract, the compliance guarantee is broken. The document and the engine can silently disagree. Generating the paperwork from the calculation keeps a single source of truth from the first quote to the signed contract.

Two years at the core of the backend APIs

From 2022 to 2024 I contributed heavily to the backend API services at the core of RatesCalc, the layer where the calculation engine and the document workflows live. Two years on one backend is a different kind of engineering than a greenfield sprint: it means extending a system while it's serving real users, changing calculation behaviour without breaking the answers people already rely on, and treating every modification to a compliance engine with the caution the word "compliance" demands.

The product runs on infrastructure the company hosts itself, and I helped manage that server environment alongside the product work. On a self-hosted compliance SaaS the two responsibilities are inseparable. The correctness of the engine and the availability of the machine it runs on are the same promise to the user, and I held a piece of both.

What this proves

The stack details here are deliberately generic; this is a commercial product, and its internals are its own. What two years at the core of this backend demonstrates about Exybit's custom software work is the part that transfers:

• Correctness-critical backends: engines where the output has to be a defensible number rather than a best effort.
• Domain-rule modelling: turning dense regulatory logic into software that can be maintained, extended, and explained.
• Document automation: quote-to-contract pipelines driven by calculated data, with nothing re-typed by hand.
• Sustained contribution: two years inside one production backend, plus the self-hosted environment underneath it.