Ardor Institute

The problemCopy Anchor Link

Germany's Energy Efficiency Act makes every data centre above a size threshold file an annual waste-heat report with BAFA, the federal energy-efficiency office.

There are directories of European data centres, and none of them include thermal profiles: how much heat, at what temperature, how reliably, and whether the operator would connect to a district heating network. You can find out where data centres are. You cannot find out what heat they produce.

The filing contains exactly that data. An operator has to produce it anyway, and a district heating utility needs it to decide whether to lay pipe. Today it goes into a national archive nobody searches. France, the Netherlands and Ireland are building the same thing independently, in different formats and languages.

What I builtCopy Anchor Link

• Heat map. A public map of data centres and district heating networks. Estimated profiles and report-backed profiles are labelled differently, because they are not the same thing.
• Report wizard. Three steps. Pick a facility on the map and the wizard pre-fills; otherwise enter IT load, efficiency, cooling type and location.
• Calculation model. Annual recoverable heat from four inputs, conservative by default, with a path for measured values. The method is published in full.
• Checkout and delivery. Payment, then a rendered PDF in the operator's dashboard, with a 30-day read-only link to send to a consultant.
• Regulatory layer. A German and English site, a glossary of 14 regulatory terms, guides to the 2027 obligation, and a consultation paper proposing a German register for tradable waste-heat certificates.

How it is structuredCopy Anchor Link

In the codeCopy Anchor Link

export const CAPTURE_EFFICIENCY: Record<string, number> = {
  air: 0.5,
  mixed: 0.6,
  liquid: 0.8,
};

export function calculateHeatProfile(data: FacilityData): HeatProfile {
  const itLoadMW = data.itLoad / 1000;
  const totalPower = itLoadMW * data.pue;
  const annualEnergy = totalPower * 8760;
  const efficiency = CAPTURE_EFFICIENCY[data.coolingType] || 0.5;
  const recoverableHeat = annualEnergy * efficiency;
  const households = Math.round(recoverableHeat / 20);
  const tempRange = TEMP_RANGES[data.coolingType] || "25–40°C";

  return {
    totalPower,
    annualEnergy: Math.round(annualEnergy),
    recoverableHeat: Math.round(recoverableHeat),
    households,
    tempRange,
    availability: "~8.000 h/Jahr",
    efficiency: Math.round(efficiency * 100),
  };
}

How a report gets madeCopy Anchor Link

Next.js 16 and React 19, Supabase for Postgres and sign-in, Stripe for payment, a separate PDF service, German and English throughout. 147 commits in April 2026.

Data and accessCopy Anchor Link

Ten tables: people, organisations and their members, reports, the marketplace's records and matches, buyer accounts, Stripe's events, and a log of data requests. Row-level security is on for all ten. The Stripe event table has no access rules at all, which means only the server can read it.

The data-request log exists because the product handles personal data in the EU: each request under GDPR Articles 15 to 22 is recorded with its type, its 30-day deadline and what was done.

The second half: the map and the marketplaceCopy Anchor Link

Reporting is the part people can buy today. The part it exists to feed is the other half of the site: a map of where waste heat is, and a way for someone who needs heat to find it.

• The map. More than 100 data centres across ten countries and ten district-heating networks, as pins over a heat layer, with filters for capacity, cooling type and whether a site's figures are verified or estimated.
• Feasibility, per buyer. The same site is a good match for one buyer and a poor one for another. Each site gets a physical heat profile, and that profile is graded separately for four kinds of buyer: industry, district heating, hospitals and housing.
• The marketplace records. Tables for site profiles, buyer accounts, matches and the events on a match, so an introduction can be followed from first contact to outcome.

How a match is gradedCopy Anchor Link

A grade starts at 5 and moves on evidence, and it always says why.

The result is one of three verdicts: feasible, borderline, not feasible, with its drivers and blockers attached.

The roadmapCopy Anchor Link

What broke, and the fixCopy Anchor Link

Checkout failed with infinite recursion detected in policy for relation "org_members". A rule deciding who may insert a report looked up organisation members, and that lookup ran the rule again.

Two changes fixed it. The rules were rewritten to call small helper functions that read membership with the rules switched off for that one lookup. And checkout stopped depending on those rules: it verifies the person and their organisation first, then writes the report as the server.

What is not finishedCopy Anchor Link

Things an engineer would find, so here they are.

• Duplicate payment calls. A table to recognise a repeated call from Stripe exists, and the code that should use it was not written. A retried call could start a second report.
• Refunds. Downloads already refuse a refunded or disputed report, but nothing yet records that a refund happened.
• Rate limiting is held in memory per server instance, so it does not hold across instances. The code says so and names the replacement.
• No automated tests.

The decision that matteredCopy Anchor Link

I started with a marketplace thesis: compliance is the way in, the marketplace is the product. Every filing adds a verified heat profile, and buyers pay to search them.

Halfway through I rebuilt the site around a narrower claim: reporting first, market infrastructure later. A marketplace with an empty database helps nobody. Buyers need report-backed profiles, and those only exist once operators have filed.

The regulation does the hard part of a market: it forces supply to document itself. The product's job is to be the cheapest, clearest way to comply, and to keep the data.

Open questionsCopy Anchor Link

MoreCopy Anchor Link