Building decarbonization is a sector caught between regulation-driven demand and the brutal reality of fragmented delivery. The regulatory push is real — the EU’s Energy Performance of Buildings Directive, national retrofit mandates, local net-zero commitments. Demand is being constructed by policy, which is exactly what most climate tech sectors lack. But the organizational challenge is equally real: every building is different. Every retrofit is partially custom. Every project involves a different combination of building age, construction type, ownership structure, tenant situation, and regulatory requirement. The company that wants to be a scalable technology business finds itself running what is, structurally, a services business with technology components. The tension between “we do installations” and “we sell software” is the defining organizational fault line of this sector.
The typical scaling path
Built environment companies typically start with one of two entry points: a technology play (smart building controls, digital twins, energy management software) or a services play (energy audits, retrofit project management, installation). Technology-first companies build a platform, secure pilot customers, and demonstrate energy savings. Services-first companies build a delivery team, complete projects, and demonstrate track record. Both hit the same scaling problem from opposite directions. The technology company discovers that selling software into the built environment requires understanding building physics, construction logistics, and property management — none of which the founding team has. The services company discovers that scaling project-by-project requires an army of on-site technicians, project managers, and subcontractor relationships that grow linearly with revenue. Both converge on the same ambition: a technology-enabled services model that combines software scalability with physical delivery capability. And both discover that building this hybrid organization is far harder than building either a pure tech company or a pure services company.
Where it breaks
The hybrid model breaks because the two halves of the organization operate at different speeds, with different margin structures and different talent requirements. The software team ships quarterly. The installation team delivers over months. The software team’s cost structure is engineering salaries and cloud infrastructure. The installation team’s cost structure is labor, materials, and subcontractor management. Blending these into a single P&L creates confusion about what the company’s economics actually look like — and that confusion propagates into every organizational decision. Hiring profiles differ: the CTO who can build energy management software isn’t the person who can manage a network of retrofit contractors. Accidental complexity emerges as the company builds organizational structures to bridge the two worlds — technology teams embedded in delivery operations, project managers who also do product feedback, field data that’s supposed to improve the platform but never gets cleaned enough to be useful. The adaptation trap locks in as each completed project leaves behind custom configurations, site-specific workarounds, and one-off integrations that become impossible to standardize across the growing portfolio.
The structural tension
The core tension is between scalability and specificity. Software scales because it’s standardized. Retrofit delivery doesn’t scale because every building is specific. The technology platform wants to abstract building performance into standardized data models and automated recommendations. The delivery team knows that the ninety-year-old apartment block in Berlin and the 1970s office tower in London have nothing in common except the regulatory requirement to improve. The platform can model both. The organization can’t serve both with the same processes, the same skill sets, or the same project economics. Long sales cycles compound the tension — selling a retrofit program to a building owner or property manager involves navigating ownership structures, tenant agreements, financing options, and regulatory compliance timelines. By the time the contract is signed, the company has invested months of pre-sales effort that SaaS economics can’t justify. The organization builds business development capabilities that look more like real estate consultancy than technology sales.
What I see
The pattern across built environment companies is an organizational identity crisis that nobody names. The investor pitch says “proptech” or “cleantech platform.” The operational reality is a construction-adjacent services business that uses software to coordinate delivery. Neither identity is wrong — the sector genuinely requires both technology and physical delivery. But the organizational design needs to reflect the hybrid reality rather than pretending one half will eventually absorb the other. The companies that succeed in this sector are the ones that accept the dual nature of their business and design the organization explicitly for it: a technology operation with its own leadership, metrics, and development cadence, and a delivery operation with its own leadership, metrics, and project management framework. Connected by shared data and shared customers, but not forced into a single operating model. The ones that struggle are trying to run an installation business with SaaS metrics, or build a technology platform with project delivery culture. The organizational model has to match the structural reality of what the business actually does.
If your built environment company is stuck between platform ambitions and project delivery realities, the organizational model needs to match the business you’re actually running. Reach out.