← Work

Case Study · obolus.at

Accurate to the cent, year after year.

How to build a salary and tax platform that absorbs a new body of rules every January without being rebuilt, and can cite every number it shows.

Role
architecture, backend, frontend, operations
Team
1
Since
2026
Stack
Vue · Nuxt · TypeScript · Nitro · SQLite · Storyblok · Kor · Docker · Traefik · GitLab CI
obolus.at
The problem

What the job actually was

The constraint

Austrian income tax is not a formula, it is a body of rules that changes every January. The incumbent is a free calculator run by the Chamber of Labour, and people trust it. Under those conditions a new entrant has exactly one way to be worth using at all: be exactly right, show the derivation, and be current before anyone else is.

The decisions

A rules-based engine with a versioned rate registry, one version per tax year. Computation runs in the browser, so no salary figure is ever transmitted. And editorial content is derived from the same registry as the engine, which makes it structurally impossible for a published number to drift from a computed one.

The discipline

Every rate, threshold and contribution base is cited to its primary source. When the ministry publishes next year's figures, a single registry version is seeded and the entire site previews the new year: tables, glossary, calculators, FAQ. On 1 January it flips. That is the work that makes the difference in December, while everyone else is still updating content by hand.

The operation

EU hosting, CI/CD, monitoring, updates, and the annual re-audit against the new publications. Built and run, not built and handed over. That difference is why the architecture looks the way it does: you build differently when you are the one doing the next five January rollovers.

Architecture

One registry, and everything reads the same version

The published number and the computed number come from the same version. Divergence is structurally impossible.
obolus data flowPrimary sources are seeded once per year into a versioned rate registry. The registry feeds both the tax engine, which runs in the browser, and the content layer. Because both read the same registry version, a published number and a computed number cannot diverge.BMF · BVAEBPrimary sources, published annuallySEEDED · ONCE PER YEARRate registryone version per tax yearat-2025at-2026at-2027 · previewSAME VERSIONIN THE BROWSERNOTHING TRANSMITTEDTax enginerules based, cent accurateContent layertables, glossary, FAQPages on obolus.at
Primary sources are seeded into the registry once a year. The tax engine and the content layer read the same version of it, so a figure in a table and a figure in a result cannot drift apart.
Transferable

What carries over to your project

Three things, and none of them depend on the subject being tax. First, correctness discipline under a regulatory constraint: the provenance and version of every number are part of the architecture, not of the documentation. Second, an SEO surface that is generated rather than written, so content and computation cannot drift apart. Third, a platform layer that makes a very small team a viable way to deliver a product of this size and operate it for years.

If this is the shape of your problem

An email costs you five minutes, an audit costs you access and 72 hours. Either tells you more about how we work than another case study would.

Write to usBack to the home page