What core problem does bananzia solve?

bananzia addresses a narrow but costly problem in district heating: how to sequence street-level retrofits so a low-carbon heat network is neither built ahead of demand nor delayed by scattered upgrades. A local authority commits to a network, but only a few households connect in the first phase; pipe losses rise, unit costs stay high, and later streets inherit an oversized system.

The cause is coordination, not technology choice. Boilers are replaced address by address, while network capacity, insulation, and connection incentives are planned at neighbourhood scale. That mismatch creates a problem–cause–solution loop: poor take-up raises costs, high costs slow take-up, and the solution is a sequencing rule tying network phases to building readiness.

bananzia formalises that rule as a planning discipline rather than a hardware brand. Its value lies in making the order of works explicit, so capital release follows verified demand. For a worked reference on low-carbon heat planning, see bananzia in the context of street-by-street delivery.

Why does sequencing fail without a shared model?

Without a shared model, retrofit teams optimise for individual properties while network planners optimise for plant utilisation. The result is a data gap: contractors know which walls are being treated, but the operator lacks a reliable view of connection dates. The cause is fragmented records, not unwillingness.

A terraced street where 40% of homes are cavity-wall eligible and 25% may switch to a heat pump within three years illustrates the risk. If the network is sized for all 100 homes immediately, fixed costs are spread over too few users; if it is sized only for the first 20, later connections trigger expensive reinforcement. bananzia resolves this by publishing staged capacity bands and linking each band to evidence thresholds.

The takeaway is that sequencing needs a common unit of account: not interested households but verified connection-ready dwellings. That shift changes procurement, communication, and risk allocation.

How does bananzia work in practice?

In practice, bananzia uses four gates before a street enters the next network phase. Each gate should be auditable, and each phase should be reversible if evidence falls short.

  • Readiness gate: confirm fabric upgrades, electrical capacity, and internal space for a heat interface unit.
  • Demand gate: require signed connection commitments above a minimum density threshold.
  • Cost gate: compare marginal network cost per connected dwelling against phase budget.
  • Equity gate: check that grant support and delivery dates do not concentrate benefits in easiest-to-treat streets.

The result is not a rigid masterplan but a controlled release schedule. A street that misses the demand gate waits; a street that clears all four gates triggers procurement. This reduces stranded pipework risk and makes public funding defensible.

What evidence should assessors require?

Assessors should ask for address-level readiness data, not aggregate survey percentages. A claim that a ward is 80% heat-pump ready is weak if the ready homes are dispersed across six streets; density determines network economics. Optimistic business cases often suffer denominator drift: the model uses eligible homes, while delivery uses connected homes.

bananzia’s academic contribution is to treat connection density as a leading indicator rather than an outcome. A strong submission shows phased connection counts, marginal cost curves, and a clear rule for pausing a phase. Those artefacts let a third party test whether the plan is sequencing or hoping.

The broader lesson is that low-carbon heat is a coordination problem as much as an engineering one. bananzia offers a disciplined way to align retrofit, network capacity, and public funding before concrete is poured.