A data foundation for housing associations

Why standard reports rarely fit

Because they mirror the vendor's process instead of yours. Associations working LEAN or steering on their own KPIs hit this first: you want to measure whether an improvement had any effect, and that particular measurement is exactly what the standard package does not contain. The consequence is familiar — reports that falter, long recovery times when something breaks, and a small team without the room to fix it structurally.

The real problem is not the missing report. It is that trust in the figures erodes. Every time a dashboard fails, time goes into firefighting instead of into tenants and homes. Process owners who get their figures late end up steering on gut feeling.

What an association actually has to load

Usually four kinds of source. The primary system holding homes, contracts, tenants and repair requests; the finance and HR system; a number of loose registrations that in practice live in Excel or SharePoint; and open data about the neighbourhood. Yres connects to those as follows:

Why history weighs more heavily here

Because nearly every question a housing association asks is a question about change over time. How did rent arrears develop, how long has this repair request been open, what was the state of this complex before the renovation, how did affordability shift over three years. A source system usually keeps only the current state: an address that changes overwrites the old one.

Yres records the full history of every table as SCD2. Six of the seven load types keep that history, so you can always look back at the state of any given day, even when the source system cannot do so itself. That is also what makes an auditor's question or a retrospective accountability exercise straightforward: the figures of that moment are still there.

• Change detection on a hash of key and content, so only real changes produce a new version
• Disappeared rows can be left standing or closed off cleanly — important when a source occasionally delivers incompletely
• Roll one table back to a point in time, with a dry run first
• Archiving to Parquet with a single view across database and archive, so a multi-year series stays complete without growing the database

What that looks like in practice

Woonstichting 'thuis rents out and manages around 11,000 social housing units in and around Eindhoven, Veldhoven, Best, Son en Breugel, Waalre and Oirschot. The organisation works LEAN: improving processes and measuring whether those improvements work. The standard reports from sector vendors did not match those own KPIs, and with a small internal team there was little room to solve it.

After comparing other sector parties, 'thuis chose Yres — not the familiar choice within the housing world, but the one that fitted on merit. Work ran in three-week sprints, so it was always clear what was being delivered. The result: reports refresh faster, errors are found and fixed earlier, and the data is current. Trust in the figures grows, and process owners can steer on relevant data again.

"We want to spend our time on our tenants and our homes, not on reports that do not do what they should." — Toin Pijnenburg, IT Manager, Woonstichting 'thuis

What it means for a small team

That upkeep does not grow with the number of sources. At a housing association the data platform is almost never anyone's full-time job, so operations have to sit in the product rather than in scripts of your own. With Yres they do: about eighty checks on the configuration, a test suite shipped with every version and safe to run on production, maintenance pipelines that clear stuck runs and prune logs, and a database that only scales up during loads.

Everything runs in your own Azure tenant: the data, the metadata, the credentials and the secrets. If you stop using Yres, that environment keeps running and your own data engineers can keep developing on it. In a sector where tenders and vendor changes are part of the job, that is not a detail.

Frequently asked questions