I put every government fee on my site in a CSV, with an expiry date

LankaSolve — Wed, 28 Oct 2026 05:02:20 +0000

Most "how to get a passport in [country]" pages go wrong the same way. They were right the day someone wrote them, nobody wrote down where the facts came from, and nothing tells anyone when to check again.

I run LankaSolve, a static site with step-by-step guides and calculators for Sri Lankan government procedures: passports, national ID cards, police clearance, driving licences, vehicle transfers, EPF/ETF and VAT. It's one person, a few hours a week. So the design question was never "how do I write a lot of pages." It was "how do I keep a few hundred government facts true without a team."

Here's what worked.

1. Every fact is a row with a source and a next-check date

The core of the project isn't a component. It's docs/sources/source-registry.csv. Every externally sourced fact (a fee, a form number, a deadline, an office address) is one row:

data_id, category, data_point, value, unit,
source_authority, source_title, source_url, source_date,
last_verified, next_check_due, volatility, notes

The rule is simple: if a Sri Lankan fee, rule or requirement isn't in the registry with a primary source, it doesn't go on the site. Not from memory, and not from a blog that ranks well. There are about 350 rows behind the published pages right now.

The next_check_due column is the part that matters. A fact with no expiry date quietly turns into a guess.

2. Volatility tiers decide how often to re-check

Not every fact goes stale at the same speed, so every row has a tier:

GREEN: maths and constants (a perch is 25.29 m²). Never re-checked.
YELLOW: official values that change now and then (fees, tax rates). Re-checked every few months.
RED: things that change often or need interpretation. These get short re-check dates, and one rule: a RED fact can't become a calculator or an automated decision without a deliberate sign-off.

The RED tier earned its place this year. Sri Lanka Police suspended online police clearance applications in September and restored them from 16 October. While it was suspended, that row was re-checked weekly. The guide carried a dated status banner, and the public sources page carried a timeline. When the notice came out, updating the site meant changing one row and the text that depended on it, not hunting through pages.

3. Write down what the government doesn't publish

The driving licence practice test taught me this. It has 100 questions, and each one cites the regulation or official page its answer comes from, down to the gazette schedule for road signs. The mock exam is 40 questions, with a 30/40 pass mark and 60 minutes.

Those three exam numbers aren't published anywhere by the Department of Motor Traffic. They come from driving schools and exam-prep material. So the data file says that next to the numbers, and so does the page. It's tempting to present a widely repeated number as fact. Labelling it honestly costs one sentence.

The same idea applies to forms. Each guide's checklist links the official form it names. The rule is: link the department's own PDF if one exists. If the form is only generated inside a portal when you submit (some company-registration forms work this way), link the portal. If it's issued ad hoc by a local office with no central version, link nothing. Never guess a PDF URL from a form number.

4. Calculators are plain functions, not components

The EPF/ETF, VAT and loan calculators live in src/calculators/ as pure JavaScript, with no Astro, no DOM and no browser state. A small client-side script in src/ui/ imports the function and wires it to the form.

That keeps testing boring in the good sense. Each calculator gets one test file covering normal values, zero, the boundaries, and one worked real-world example, and it runs with Node's built-in test runner (node --test). There's no framework, and no test that checks the same maths a second time through the UI.

5. Static everything

It's Astro building plain HTML to Cloudflare Pages, with Pagefind for search at build time. Runtime dependencies: Astro and the sitemap integration. There's no CMS, database or server. Guide content lives in data files that a shared guide template renders, so a fee change is a data edit, not a layout edit.

6. Make the receipts public

All of this would be invisible if the sources stayed in a CSV in the repo, so there's a Verified Sources page listing what was checked, where, and when. It's the page I'd point to if anyone asked "why should I trust this?"

What I'd tell anyone building something similar

Put a date on every fact, plus a date to check it again.
Keep the facts in one boring file, not spread across your templates.
Write down the gaps. "This isn't officially published" is useful information.
A one-person project lives or dies on maintenance cost, so price every new page in re-checks, not in words.

If you want to see it in practice, the driving licence practice test is the most self-contained part. It's in English, Sinhala and Tamil, and every answer has its source.

DEV Community: LankaSolve