What did a 349-home scheme reveal about an apparent grid constraint?
The scheme comprised 349 homes. With the solar PV proposed as part of the Future Homes Standard compliance strategy, it initially appeared to have an export problem.
On paper, the concern looked straightforward. Add all the proposed generation together and compare it with the apparent network limit. The total looked serious enough to influence design decisions.
But the network does not see a static page of nameplate ratings. It sees the combined site through time. Homes consume electricity while PV generates it. Outputs vary. Peaks do not all coincide. The relevant question was not simply how much PV had been specified, but how much export was expected to reach the connection point.
HubbPro therefore simulated the development as a complete site: expected demand, expected generation, coincidence, and expected export at the grid boundary. The result was a more representative export profile that resolved the uncertainty around the apparent problem.
That conclusion needs a clear boundary. It came from a scheme-specific model, not measured operational performance. The model did not prove that every possible export constraint had disappeared. It gave the team better evidence about the scheme they were actually planning.
Before designing around a constraint, make sure it is the real constraint.
Why do cautious assumptions become expensive when they stack?
Network planners, product suppliers, assessors, and installers all have good reasons to be cautious. Their work has to protect compliance, performance, comfort, safety, and network integrity.
The problem is not caution itself. The problem is accumulation. A conservative planning allowance is combined with a conservative heat loss. That drives a larger product selection, which produces a larger electrical input. The larger input is then carried into the compliance model and the connection request. Each step can look defensible in isolation while the complete scheme becomes over-engineered.
On the 349-home scheme, the initial kVA-per-plot allowance was more conservative than both the scheme-specific evidence and the relevant network guidance benchmark used for comparison. This does not mean the IDNO was wrong or acting improperly. It means the planning value deserved to be tested against the development.
The Future Homes Hub guide to grid connections for all-electric houses makes the same wider point: applications commonly ask for too much power too early, while accurate load assessment and realistic phasing can support quicker and more cost-effective connections.
The objective is not to make every number smaller. It is to make every important assumption proportionate, traceable, and defensible.
Why is choosing a heat pump not the same as designing the heating system?
The second lesson came from the heat pumps. The supplier had proposed units using conservative heat-loss calculations. The initial selections provided more capacity than the refined heat-loss assessment supported.
Supplier and installer inputs were then being carried into the SAP assessment without a whole-scheme reconciliation. Again, that is not evidence that the supplier or assessor was at fault. SAP reflects the inputs it receives, and a supplier can be entirely right about the capability of a product while the development still ends up with the wrong overall system.
Different parties each owned part of the answer. The IDNO had planning allowances. The SAP assessor had compliance inputs. The heat pump supplier had product data. The installer had practical experience. What the client lacked was ownership of the interfaces between them.
That is why so many low-carbon design conversations feel like product fatigue. The questions arrive one box at a time: which heat pump, what size, what efficiency, and where will it go? Those are valid questions, but they follow a more important one: what energy system does this development actually need?
The problem was not the heat pump. It was choosing the box before understanding the system.
Can thermal storage move heat pump demand away from the electricity peak?
The real 349-home project concerned expected PV export through the grid boundary. Qvantum did not solve that export question. HubbPro's whole-site simulation resolved the uncertainty.
The experience did, however, prompt a different question. Change the season and consider a cold evening rather than a bright day. The issue is now import: what electricity needs to enter the scheme, and when?
A conventional heat pump discussion tends to focus on output and efficiency. Thermal storage adds time. Heat can potentially be generated before the electrical peak, held in a thermal store, and used later for heating or hot water.
Qvantum describes its accumulator tank as a thermal battery that can respond to electricity prices and periods of renewable surplus. This makes the architecture relevant to a whole-system comparison, but it is not evidence that it will solve every development constraint.
A thermal store does not create capacity or erase demand. Its potential value is that it may move part of the demand away from the peak. The result depends on usable storage capacity, recovery rate, controls, comfort limits, standing losses, tariffs, and the actual site profile.
The right question is not whether thermal storage is good. It is whether a particular storage and heat pump architecture performs better than the alternatives on this scheme, under traceable assumptions.
Who must own the control, risk, and reward behind energy flexibility?
Every attractive flexibility model eventually meets the same practical question: who holds the keys?
If heat pumps, thermal stores, batteries, or smart controls are owned by individual homeowners, who can operate them as a coordinated system? Who chooses the tariff? Who permits load shifting? Who maintains the equipment and gets access when something fails? Who benefits financially, and who carries the comfort or performance risk?
Ofgem's work on domestic demand-side response explains that heat pumps and other electrified assets can shift consumption to off-peak periods, including through automated services managed by third parties. It also makes consumer participation central to that model.
A model can work perfectly until the residents receive the keys. A purchaser may change tariff, disable a control, sell the property, or reasonably reject somebody else deciding when their heating operates. Individually owned assets cannot simply be assumed to behave as a dependable fleet.
Flexibility only works when control, risk, and reward have an owner.
What should housebuilders compare before selecting products and infrastructure?
The project team does not need to compare every imaginable technology. It does need to compare credible complete systems before one product route becomes embedded in planning, cost, compliance, and the grid application.
For a residential development, that comparison may include:
- expected import and export profiles at the connection point;
- scheme-specific demand, generation, diversity, and phasing;
- plot-by-plot monobloc heat pumps against alternative heat and storage architectures;
- refined heat loss, hot water demand, plant selection, and SAP inputs;
- usable thermal or electrical storage, recovery, losses, and controls;
- PV self-consumption, tariffs, and time-based operation;
- ownership, metering, billing, maintenance, resident consent, and regulatory obligations; and
- connection capacity, reinforcement exposure, programme, and delivery risk.
A microgrid might be one route worth testing. It is not the destination by default. A microgrid brings additional ownership, protection, metering, billing, regulatory, and operating questions that must be included in the comparison.
The Neighbourhood Green network innovation project found that heat pump load should not simply be treated as its full peak equipment rating because appliance and heating peaks do not necessarily coincide. That is a useful illustration of the wider principle: complete profiles make better infrastructure decisions than stacked nameplates.
What practical questions should the project team ask at each design gate?
The five objects from the 349-home story provide a practical review sequence for design meetings, consultant briefs, and investment decisions.
- At the gate: what is the actual constraint, what evidence supports it, and is it an import, export, capacity, programme, or commercial issue?
- At the box: which assumptions arrived with the product, and have they been reconciled with the rest of the development?
- At the cupboard and clock: what demand could move through time, by how much, and within which comfort and recovery limits?
- At the keys: who owns, controls, maintains, and pays for the system, and what changes when a home is sold?
- At the map: have we compared complete system architectures, or only competing products?
These questions do not remove the need for network, MEP, sustainability, compliance, product, and utility specialists. They help the client make sure those specialists are working from one visible set of assumptions.
The aim is to identify uncertainty while it is still a decision, before it becomes a late redesign, a larger connection request, or an infrastructure commitment.
How does HubbPro act as a map for whole-site decisions?
HubbPro is not the answer, and it does not replace the judgement of the project team. A modelling tool cannot understand commercial pressures, resident expectations, procurement constraints, or delivery risks in the way the people responsible for the scheme can.
HubbPro is the map. Its role is to compare whole-scheme scenarios and make assumptions visible before one chain of product inputs quietly becomes the infrastructure strategy.
That can mean comparing demand, PV, heat pumps, thermal storage, batteries, connection capacity, phasing, tariffs, or a possible microgrid. The model helps the team see the available roads and the inherited assumptions. It identifies which options deserve detailed engineering.
HubbPro does not prove a saving, design a microgrid, guarantee that reinforcement can be avoided, or turn a hypothetical flexibility scenario into an operating system. Those outcomes still depend on network limits, detailed design, controls, tariffs, ownership, regulation, procurement, and resident behaviour.
The map does not drive the car. It stops the first answer becoming the only answer.
On the next scheme, before a product assumption becomes an infrastructure decision, the project team should ask who is actually responsible for the whole-system question, and which numbers are real versus which the project simply inherited.