The developing contractor: tear down the wall

Parties that both develop and build hold a unique position. They control the process from the first sketch to the final brick. That horizontal integration should be a powerful advantage.

In practice, it rarely is.

Over the past months, OMRT spoke with more than a dozen Dutch developing contractors, in collaboration with TU Delft, about their software landscape and vision for the future. The pattern was consistent: there is an accumulation of bottlenecks compounding at every transition, every phase change, every handover to a new team. And it is costing more than most companies realise.

Fragmentation starts earlier than you think

The obvious friction point is the handover from design to construction. But for developing contractors, the problem starts well before that.

The design team at a developing contractor works through distinct phases, moving from sketch design to schematic, preliminary, and final design, often switching between modelling tools as the project matures. The process from early massing study in sketching software like Forma to a fully detailed model in Revit involves many transitions. Each transition means data has to be rebuilt, assumptions made and context re-established.

By the time the project moves internally, the contractor's team picks it up in their own BIM environment, alongside ERP and estimation systems. But there is still no live connection between these worlds. Information has to be manually re-entered, and the knowledge accumulated through earlier design phases effectively evaporates.

One branch director at a major developing contractor described this as the schuttingmethode: the development team finishes its work and throws the result over the fence to the contractor. What lands on the other side is incomplete at best.

The bottlenecks: what the interviews revealed

This accumulated fragmentation leads to concrete and costly problems. Across our conversations, four patterns kept surfacing.

Duplicate work and data loss.

The contractor's team has to reinterpret geometry and specifications that the design team already defined. Quantities and cost data from design models are manually transferred into financial and planning software. One development manager described how every project requires the same effort: rebuilding what the design team already built, in a different system, with no guarantee the numbers match.

A chain of frustration.

The back-and-forth that follows is expensive. The contractor goes back to the design team for clarification. The designers feel their decisions are being misread. The developer is stuck in the middle, reconciling two worlds that were never properly connected. Several interviewees highlighted that the lack of standardised data exchange between departments creates persistent friction, even within a single organisation.

Slower project cycles.

One developing contractor stated a goal of reducing project duration by 30 to 40 percent. But achieving that is impossible when each manual handover and subsequent correction round adds weeks. Every transition between teams, phases, or tools is another obstacle to pass before construction can begin.

Limited feedback loops make it worse

Several developing contractors described the absence of structured feedback from the construction site to the development team. Lessons about buildability, material lead times, or cost overruns from one project rarely inform the next.

One interviewee pointed to a fundamental gap: there is no mechanism for on-site data to feed back into earlier design and budgeting phases. The result is that the same mistakes get repeated across projects, and the contractor's knowledge of what is actually buildable never reaches the people making design decisions.

This is the biggest missed opportunity for developing contractors. They have execution knowledge that external design teams simply do not have. Being able to flag that shortening a span slightly saves significantly on steel is something an integrated internal team can do, but an external design team working in isolation cannot. That knowledge, applied at the right moment, leads to buildings that are faster to deliver, more cost-effective, and genuinely more buildable.

What integration looks like

Developing contractors who are moving past this describe a fundamentally different process. Design data flows continuously through every phase, without re-entry, without rebuilding, without loss.

Several of the contractors we interviewed are investing heavily in connecting design and execution environments. One is linking its parametric design tools directly to 4D planning software, so that information from design studies feeds into on-site scheduling and cycle-time benchmarking and vice versa. Another has built an in-house housing configurator that converts parametric inputs into 3D models and drawings automatically, removing the need for a massive library of pre-drawn house types.

The strategic ambition behind these efforts is generally consistent. Multiple developing contractors reported goals of delivering 60 to 80 percent of their projects through standardised, concept-based approaches.

But the biggest gain is not just speed or cost reduction. It is the ability to make decisions with the full picture in view. When the contractor's team sees that a structural choice is pushing up costs, that insight feeds directly back into the model. The developer sees the financial consequences in real time, and trade-offs between cost, sustainability, and buildability become visible before they become real problems.

The wall is mainly organisational, not technical

The tools to make this possible exist. The barrier is rarely technical. Several interviewees were clear about this: the challenge is getting people to follow one process. Internal politics, cultural resistance, and inconsistency in working with templates prevent adoption even when the technical infrastructure is in place.

One innovation manager described it as a governance problem rather than an IT problem. Another emphasised the importance of proving that a new tool can replicate what teams already trust before introducing new capabilities: replicate first, innovate second.

For the developing contractor, tearing down the wall involves an organisational shift toward shared environments, continuous data flows, and feedback loops that actually close. The companies that get this right will not just be faster. They will be structurally better at turning every project into a learning opportunity for the next.

This article is based on research conducted by OMRT in collaboration with TU Delft, involving interviews with eighteen Dutch real estate developers, developing contractors, and developing investors.