slim.lu

A price comparison service for Belgian consumers. It takes a market where the real cost is deliberately hard to see and turns it into something a household can compare — showing the sources, the check dates and the gaps rather than hiding them. Live at slim.lu, open source at ARBITORIA-BE/slim. I defined the problem, the ranking rules and the validation criteria; the implementation is AI-assisted.

The observation

Belgian telecom pricing is not complicated by accident. Every operator runs a promotional window that expires — six months here, twelve there — after which the price steps up to a number nobody quoted at signup. Bundles change the arithmetic again. Brand names hide ownership: Scarlet is Proximus, BASE is Telenet, VOO has been folded into Orange. The result is a market where the advertised number and the two-year cost are different questions, and only one of them is easy to look up.

This is the same shape as the problem I work on professionally. A figure that is technically accurate and still misleading, because the context that produced it has been stripped away. The difference is that at work I fix it inside a company's systems, and here the affected party is a household.

What the service does

• Five comparison surfaces — mobile, internet, mobile + internet, internet + TV, and the full triple play.
• Four Belgian operators — Proximus, Telenet, Orange and DIGI.
• Prices taken from the operators themselves, parsed from their own pages and validated against typed schemas before they can reach a comparison.
• Collection on a daily schedule, at 06:00 UTC, with the page cache refreshed hourly.
• Three languages — Dutch, French and English, matching how Belgium actually reads.

Publishing what is usually hidden

The part I care most about is not the comparison; it is the disclosure around it. A comparison you cannot audit is just an assertion with a table around it. So the service publishes, on a page anyone can reach:

• The source and collection method for every operator, alongside when each was last checked — in hours, not a vague "recently".
• Which operators are excluded, and the specific reason for each. Lebara because automated price fetching is blocked by bot protection, with the date the 403 was observed. Mobile Vikings because prices load at runtime from an external API. Lycamobile because its plans are 30-day bundles rather than monthly contracts, so they are not comparable on the same axis. VOO, BASE and Scarlet because they are already covered — they resolve to Orange, Telenet and Proximus respectively. Others simply because a fetcher has not been built yet, which is also said plainly.
• The affiliate relationship. The service earns commission when a user completes a contract with a provider. That is stated, and so is the separation: ranking is determined by the algorithm regardless of whether a product is an affiliate link.

A comparison site that cannot show its sources is asking to be believed. Publishing the exclusions is the cheapest way to earn the opposite.

Naming the operators you left out is the uncomfortable one, and the most useful. It converts a silent gap in coverage into a stated limitation the reader can weigh — the same instinct as marking unconfirmed items in a dataset rather than dropping the rows.

Under the hood

The engineering exists to make the above true continuously rather than once. It is built with AI coding tools against requirements and acceptance criteria I set — so read it as evidence of specification and verification, not of hand-written code.

• Each operator has its own fetcher, and every result is validated against a typed schema before use. Operator pages change without warning: Orange's mobile pricing was originally ruled out as unfetchable because it rendered through a JavaScript component, then re-checked months later and found rebuilt as static HTML, so the exclusion was reversed. That round trip is recorded with dates rather than quietly patched.
• Automated checks cover the claims, not just the code — including data freshness, price integrity, ranking neutrality, disclosure completeness and translation-key parity. The neutrality claim in particular is verified by a test rather than asserted in a footer.
• Decisions are written down as architecture decision records, including rejected options and amendments where a decision's premises later turned out to be wrong. Roughly 850 automated tests run before anything merges.
• Boring beats clever when production disagrees. After one release the guide pages returned 404 across every locale in production while working locally. Two hypotheses failed. The third diagnosis was that content files were never traced into the serverless bundle. The fix was to delete the MDX pipeline entirely and rewrite the guides as ordinary typed routes — fewer moving parts, and no longer dependent on a framework combination that did not hold up.

Where it is now

The product works and the data pipeline runs daily; the audience is still small. I would rather report that accurately than inflate it — the numbers worth quoting here are the four operators covered and the daily check, not a traffic figure.

Why this matters for the work I want

slim.lu is what happens when the data-quality habit is pointed at a consumer market instead of a corporate database: find where the context went missing, rebuild it, and publish the limitations alongside the answer. That is the same job as producing an analysis someone will make a decision from — the caveats have to travel with the number, or the number does damage.

Live at slim.lu. Source at github.com/ARBITORIA-BE/slim. The disclosure pages are linked from every comparison.