Building a calculator platform designed to scale

As the business has grown, so has demand for more calculators, more variety, and faster delivery for clients. That growth surfaced a clear question: how do we build a suite that can keep expanding without the cost and complexity compounding alongside it?

Our calculator suite had grown organically, product by product. Several calculators solved adjacent problems in their own way, each with its own logic, its own assumptions, and its own maintenance path. That's a natural pattern in early growth, but it's not one that scales. We wanted a foundation that could support a much larger suite, built and maintained by a growing team, without each new calculator adding its own silo of logic to manage.

For calculators that members use to make decisions about their retirement, accuracy is the product, not a feature bolted onto it. So any platform we built had to make accuracy easier to sustain at scale, not just easier to achieve once.

We evaluated actuarial partners with that in mind, looking for a partner engaged in how the logic is structured and maintained on an ongoing basis, not simply one who signs off at the end of a build. That relationship needed to hold as the number of calculators, and the pace of change around them, both increased.

The central decision was architectural. Rather than embedding calculation logic in each product, we built a new API from the ground up to serve all of them.

The reasoning was practical. Superannuation is heavily regulated, and the parameters underpinning it change regularly. A suite built product-by-product means every regulatory change has to be tracked down and applied in multiple places, then verified independently each time. That's a maintenance cost that grows with every calculator you add.

With a single calculation service, a regulatory change is made once and cascades to every calculator that depends on it. Verification happens once, against one implementation, with one actuarial review. As the suite grows, that cost stays flat instead of multiplying.

The other requirement pulled in the opposite direction. Our calculators sit inside client websites, and every client has its own design system, tone, and member experience. Trusted, regulated results had to arrive in whatever shape the design called for, for every new client we bring into the suite.

So we built a new frontend framework alongside the API, splitting the responsibilities deliberately. The framework collects the information a member provides, manages state, and presents results. The API owns the calculations. Enough shared logic sits in the framework to keep data collection and behaviour consistent across the suite; none of the actuarial logic does.

The result is that a calculator's appearance and interaction model can change substantially, a different layout, journey, or visual language, without touching a single calculation. Design work has no path to affecting accuracy, which means we can take on new clients and new design requirements without adding risk to the platform.

We now have a calculator suite built on one actuarially reviewed engine and delivered through a consistent frontend framework, designed specifically to keep growing.

In practice that means new calculators start from a proven foundation rather than a blank page. Regulatory updates are applied in one place and verified once, regardless of how many products sit on the platform. The logic behind the numbers is documented and understood inside the business, not distributed across individual builds. And clients get genuine design flexibility without trading it against compliance or slowing down delivery.

As the suite continues to expand, that architecture is what makes the growth sustainable, each new calculator adds reach without adding proportional overhead, risk, or complexity.