On 1 October 2025 the Czech Republic switched on its biggest welfare reform in a generation: four separate benefits — housing allowance, housing supplement, subsistence supplement, and the child allowance — were collapsed into a single dávka státní sociální pomoci (DSSP), nicknamed the “superdávka.” For 2026 it is the number that decides whether a low-income household makes rent.
I wanted one honest answer to a question every recipient actually asks — “if I earn 100 Kč more, how much of it do I keep?” — plus a transparent breakdown of where the money comes from. The result is a single-page calculator (in Czech, because its users are Czech). This post is about the hard part, which was not the UI: it was getting the math exactly right when the rules are split across five laws and the only binding implementation is a government web form nobody published the source of.
Open the calculator → (the app itself is in Czech)
The problem: the law is not the ground truth
The statute — Act 151/2025 Sb. plus its sibling laws and decrees — defines the benefit in prose. But prose is ambiguous, and the place where ambiguity gets resolved is the Úřad práce (Labour Office), which runs everyone’s application through one official calculator at mpsv.gov.cz. Whatever that calculator outputs is what a household receives. So for a tool that claims to predict real payouts, the ground truth is not my reading of the statute — it is the MPSV calculator’s behaviour.
The two disagree in places. The clearest example is the housing component. A strict reading of §23 and §28 suggests recognised rent should be min(actual rent, normative cap). The MPSV calculator does something else: it recognises a flat 80% of the normative rent and ignores your actual rent entirely (even when your real rent is lower). I couldn’t resolve that from the text — only by watching the calculator.
graph LR; LAW[Five laws and decrees]:::src --> AMBIG[Ambiguous prose rules]; MPSV[Official MPSV web calculator]:::src --> ORACLE[Scrape 21 million answers]; AMBIG --> ENGINE[Reimplement the engine in JavaScript]; ORACLE --> ENGINE; ENGINE --> VAL[Validate exact match 99.98 percent]:::ok; VAL --> APP[Self-contained explainer app]:::app; classDef src fill:#3d8fc4,color:#fff; classDef ok fill:#1a7f5a,color:#fff; classDef app fill:#e6a817,color:#3a2a00; classDef step fill:#eef2ff,color:#1e293b,stroke:#94a3b8; class AMBIG,ORACLE,ENGINE step;
The approach: treat the government form as an oracle
If the calculator is the source of truth, then the way to reproduce it is to treat it as a black-box oracle and fit an implementation to it. I drove the official form across a grid of inputs — net work income, other income, rent, energy cost, housing type, municipality size, number of adults, children by age band, alimony, asset test, vulnerability flags — and recorded its answers. By the current version that’s 21,023,897 verified computations.
Then I wrote a clean-room engine in plain JavaScript and tuned it against that dataset until it stopped disagreeing. Where I had a curated golden subset, it now reproduces 603,658 / 603,658 rows. Across the full 21M scrape, my engine agrees with MPSV on the exact koruna in 99.98% of cases; the residual 0.02% are households where the benefit comes out to 0 Kč either way, so the disagreement never changes a real payout.
That number — 99.98% match against 21M of the government’s own answers — is the whole credibility argument for the tool, so it sits in a badge at the top of the page rather than buried in a footnote.
The formula, four components
Under the hood the benefit is a sum of four independent components, with no global cap:
DSSP = S_housing + S_subsistence + B_children + B_work
graph TD; DSSP[Superdavka DSSP total]:::root --> H[Housing component]:::c; DSSP --> S[Subsistence component]:::c; DSSP --> C[Child bonus]:::c; DSSP --> W[Work bonus]:::c; H --> HN[80 percent of normative rent minus 30 percent of income]; S --> SN[Living minimum minus 70 percent of income]; C --> CN[500 to 1000 Kc per child by income ratio]; W --> WN[40 percent of income then tapered]; classDef root fill:#2d3748,color:#fff; classDef c fill:#3d8fc4,color:#fff; classDef leaf fill:#eef2ff,color:#1e293b,stroke:#c7d2fe; class HN,SN,CN,WN leaf;
Everything keys off two quantities: P, the household’s decisive net monthly income, and ŽM, the household’s living minimum (the sum of each member’s statutory minimum). The component thresholds are all multiples of ŽM — 1.43× ŽM is where the subsistence component and the “addressed vs. flat-rate” energy rules switch; 1.6× ŽM is where the work bonus stops growing and starts tapering. The repeated coefficients (0.30 of income toward housing, 0.40 work-bonus rate, 0.80 rent recognition) are spelled out term by term in the app’s “Explanation with formulas” section, each linked to its paragraph in the law.

The app’s “Skladba superdávky” chart: how each component fades in and out as income rises. The dashed line is the pre-2026 system, so you can see exactly where the new benefit overtakes or undershoots the old one.
The quirks you only find by watching the oracle
The interesting part of reverse-engineering is the behaviour that isn’t in any plain reading of the statute. These are the choices baked into the official calculator that I had to replicate to hit 99.98%:
- Housing is indexed by the number of adults, not people. The normative-rent table is looked up on adult count, not household size. This single detail moves the housing component by thousands of koruna for families with children.
- Only 80% of normative rent is recognised, and your real rent is ignored above that floor. The app ships an MPSV-faithful mode by default but offers a “strict reading of the law” toggle that applies
min(actual, normative)instead — so you can see both the lawful-on-paper number and the one you’ll actually get. - A discontinuity exactly at P = 3× ŽM. The child bonus drops to 0 Kč precisely at that point and immediately returns to ~1,000 Kč — an unfilled seam in the algorithm. It’s un-triggerable in practice (your income would have to land on the exact koruna), but the engine reproduces it because the oracle does.
- Self-employment imputes a phantom income. For a person on self-employment as their main activity (OSVČ hlavní), §12 floors the counted income at 39,173 Kč/month (80% of the average wage) even in a month they earned nothing. This is the single biggest reason some households are dramatically worse off than under the old system.
- Auto-imputed alimony of 2,500 Kč for the “separated, amount not set” case, and banker’s rounding to the nearest 100 Kč that matches Python’s
round()— both small, both necessary for exact agreement.
The design choices in the explainer
Matching the oracle is necessary but not the point; the point is making the result legible. The choices I made there:
- Lead with the marginal koruna. The headline isn’t the benefit amount, it’s “for every extra 100 Kč you earn, you take home X Kč.” That’s the number that tells someone whether picking up more hours is worth it, and the benefit’s tapers make it genuinely non-obvious.
- Show the exact amount, not MPSV’s rounding. The official form rounds to 100 Kč, which makes the figure jump between 0 and 100 on tiny income changes. I display the precise koruna so the curves are smooth and the marginal effect is readable.
- A “?” on every term, in plain Czech, because the legal vocabulary (rozhodný příjem, normativní nájemné, zranitelná domácnost) is exactly what trips people up.
- An honest “MPSV mode vs. strict law” switch, so the tool never pretends the calculator and the statute are the same thing.
- Built-in tests. Appending
#testto the URL runs the engine’s golden tests against stored MPSV oracle values right in the browser — the validation isn’t a claim, it’s runnable.
Who wins and who loses
Because I had a fast, exact engine, I could also do the comparison the reform’s own materials are vague about: I ran both the old four-benefit system and the new DSSP across ~9,300 typical households.
The pattern is consistent. Working families with children and a net wage around 25–40k Kč gain (up to +5,400 Kč/month); single working parents and low-wage workers in big cities mostly gain modestly. Very-low- and zero-income households lose — typically −1,000 to −6,000 Kč/month — for three structural reasons the calculator makes visible: the near-universal child allowance was replaced by a smaller, income-capped child bonus; the housing normative is now indexed by adults rather than people; and the old housing supplement (doplatek na bydlení), which topped up uncovered real costs, is simply gone. The starkest case is a self-employed person with zero turnover, hit by that §12 phantom income — a swing of −26,000 Kč/month in one of the worked examples.
How it’s built
The whole thing is a single self-contained index.html — vanilla JavaScript, hand-drawn <canvas> charts, no framework, no build step, no backend, zero external requests. That’s deliberate: the engine was validated offline against the scraped oracle, so the deployed artifact has no dependency that could drift, it loads instantly, it’s trivial to archive, and anyone can read the entire model by viewing source. It deploys as a static page and that’s the entire ops story.
Caveats
The calculator is orientational. It doesn’t model §37 (individually raised living needs — care plans, public service, prescribed diets), and for self-employment it applies only the lower 0.80× average-wage floor. The fine-grained vulnerability categories of §7 (age 68+, disability grade II/III, pregnancy, single parent, …) are collapsed into a single per-person “vulnerable yes/no” flag you set yourself. For a binding figure, file through the official Jenda portal or the MPSV calculator. This is an independent project and is not endorsed by MPSV.
Legal basis
- Act 151/2025 Sb. — on the social-assistance benefit (DSSP), in force 1 Oct 2025
- Act 152/2025 Sb. — amending act
- Government Decree 361/2025 Sb. — living and subsistence minimum
- MPSV Communication 526/2025 Sb. — normative rent for 2026
- Act 110/2006 Sb. — on the living and subsistence minimum
Open the calculator → (in Czech)