Why Companies That Aren't Builders Still Need to Run Construction Like a Core Function

There's a category of company that spends enormous sums on construction and doesn't think of itself as being in construction at all.

A retailer opening ninety stores a year. A cloud operator with data centers under construction on three continents. A manufacturer standing up new plants. A health system adding a patient tower while renovating four others. An airline building hangars and lounges. None of them would describe construction as their business. All of them build more in a year than most general contractors do.

And most of them manage it with a small team reporting to someone whose actual job is something else.

That gap is the subject of this piece. Not whether these organizations should build, they clearly should, but why building at scale without treating it as a real operational capability produces predictable, expensive failures.

Why this pattern is now everywhere

Corporate construction spending has concentrated in a few places, and all of them are growing fast.

Data centers are the most dramatic. New data center construction starts surpassed $58 billion in 2025, more than double the prior year, driven almost entirely by AI and cloud demand. The companies commissioning that work are technology companies, not developers.

Reshoring and advanced manufacturing have pushed industrial construction into the hands of manufacturers who spent decades not building anything. Retail and quick-service rollouts continue at pace. Health systems are expanding capacity against demographic demand. Logistics operators keep adding distribution capacity.

What these have in common: the organization's growth depends on physical assets, the assets have to be built, and building them is not what the organization is good at.

The asymmetry nobody names

Here's the thing that makes this different from other support functions.

When construction goes wrong at a construction company, the damage is contained to the project. Margin gets eaten, a client is unhappy, the next bid is more careful.

When construction goes wrong at a non-builder, the damage lands somewhere else entirely. The store misses the holiday season. The plant can't produce the product the launch was announced around. The data center can't take the workload that was already sold. The hospital wing opens after the grant period closes.

The cost of the overrun is rarely the real cost. The real cost is the business consequence, and it's usually much larger than the construction budget it came from.

Which means construction sits on the critical path of the core business while being managed as a support function. That asymmetry, between the stakes and the attention, is the root of almost everything else in this article.

The repetition paradox

Now the part that's genuinely strange.

A general contractor running forty projects a year develops institutional knowledge almost automatically. The same estimators price similar work. The same superintendents hit the same problems. Lessons circulate because the people circulate.

A retailer building forty stores a year often learns nothing across them. Each one runs through a different regional team, with a different local GC, on a different lease timeline, documented in whatever way that team prefers. Forty repetitions of nearly identical work, and the forty-first is priced and scheduled roughly the way the first one was.

Non-builders frequently have the highest repetition and the lowest learning rate in construction. The prototype store, the standard data hall, the modular clinic layout, these are the most repeatable projects in the industry and they're often managed with the least accumulated knowledge.

The reason isn't incompetence. It's that nothing is structured to carry forward. There's no mechanism, no owner of the mechanism, and no one whose job it is to notice.

What operational muscle actually means

"Run it like a core function" is easy to say. Concretely, it means five things exist.

• A repeatable process. Not a policy document. An actual sequence that every project follows, from request through closeout, that a new person can be handed. Most non-builders have this for procurement and not for construction.
• Standards that are enforced. Design standards, specification standards, documentation standards. If each project team picks its own equipment and naming conventions, facilities inherits chaos and nothing is comparable.
• Data that accumulates. Cost per square foot by project type, actual versus estimated at each gate, change order causes, schedule duration by phase. Most organizations have this data scattered across closed projects and have never assembled it.
• People with somewhere to go. If the construction function is three people with no career path, you're training talent for your GCs. Institutional knowledge leaves when they do.
• Governance sized for construction. Approval processes designed for buying software applied to buying buildings produce either rubber-stamping or paralysis. Neither is governance.

An organization with all five is running construction as a core function regardless of what industry it's in. An organization with two is exposed, and usually doesn't know by how much.

Three archetypes

1. The rollout operator. Retail, restaurants, clinics, fitness. Builds many small, similar projects across many markets. Speed to open is the dominant metric, since every week of delay is lost revenue on a signed lease. The characteristic failure is fragmentation: regional teams operating independently, no comparability, and prototype standards that drift until the "standard" store differs by market. They have the most to gain from standardization and the least structural incentive to slow down and build it.
2. The data center or industrial operator. Fewer projects, vastly larger, driven by demand forecasts that move faster than construction timelines. Power availability, equipment lead times and site selection dominate the schedule. The characteristic failure is a program that outgrows its team: a group built to deliver one facility a year now delivering four, with the same headcount and the same processes, and nobody noticed the moment it broke.
3. The health system or institution. Continuous renewal on occupied sites, mixed funding with separate reporting obligations, long approval cycles, and a facilities organization that inherits every building forever. The characteristic failure is the seam between construction and operations: buildings handed over with incomplete asset data, and a deferred maintenance backlog that grows because nobody connected what was built to what has to be maintained.

Different industries, same underlying condition. The organization's capacity to build has not scaled with how much it builds.

Where it actually breaks

• Estimates that were never calibrated. The number in the capital request came from a rule of thumb, an old project, or a vendor. Nobody checked it against what the organization's own comparable projects actually cost, because that data was never assembled.
• Approval processes that don't fit. Construction decisions need to happen faster than quarterly and involve more judgment than a purchase order. Governance built for other spending either delays everything or approves without scrutiny.
• Permanent information asymmetry. Your GC has done this a hundred times. Your team has done it twice. In any negotiation over change orders, schedule or scope, they know more than you do, and that's structural rather than adversarial. The only counterweight is your own historical data.
• Institutional memory that walks out. The person who knew why the last three projects went the way they did takes a job elsewhere, and the knowledge goes with them because it was never written anywhere.
• The handoff to operations. Facilities receives a building they weren't consulted about, with asset documentation that may or may not be usable, and operates it for thirty years.
• Nobody owns the function. Construction reports to real estate, or facilities, or finance, or operations, depending on the org chart. Where it reports matters less than whether a single person is accountable for how well the organization builds.

How exposed is your organization

Nine questions. They're deliberately answerable in a few minutes, and the answers tend to be uncomfortable in a useful way.

1. Can you produce your actual cost per square foot, by project type, from your own completed projects, without a research exercise?
2. Do you know how accurate your capital estimates have been across your last ten projects?
3. If the person who ran your last three projects left tomorrow, what would be written down?
4. Does every project follow the same documented process, or does each team run it their way?
5. Can you see the status of every active project without opening each one separately?
6. Do your design and specification standards exist, and does anyone check projects against them?
7. Is one named person accountable for how well your organization builds, as their actual job?
8. When facilities receives a completed building, do they get usable asset data?
9. Has your construction team grown in proportion to your construction spend over the last five years?

Six or more clear yeses means you're running it as a function. Three or fewer means the capability hasn't kept pace with the spending, and the exposure is larger than it appears because nothing has gone badly wrong yet in a way that made it visible.

The question most organizations fail first is number two. Estimate accuracy is the cheapest measure of construction capability that exists and almost nobody tracks it.

What good actually looks like

The organizations that handle this well aren't running bigger construction departments. They've done a few specific things.

They standardized the repeatable parts and stopped re-deciding them. Prototype designs, specification packages, preferred vendor lists, a documented process every project follows. The creative work goes into what's actually different about each site.

They assembled their own cost history and use it to sanity-check every new estimate. This is the single highest-return thing most non-builders could do and it requires no new software, just the discipline to capture outcomes in a consistent format.

They named an owner for the construction function with real authority, not a coordinator.

They built or bought the capability deliberately. Either an internal team large enough to carry institutional knowledge, or a long-term owner's representative relationship where the rep accumulates that knowledge on their behalf. What doesn't work is a rotating cast of project-by-project consultants, which recreates the memory problem with extra steps.

They measure themselves. Estimate accuracy over time, schedule variance from approval rather than from notice to proceed, change orders by cause. Not to punish anyone, but because you can't improve a capability you don't measure.

In-house, outsourced, or both

Three models, and the right one depends mostly on volume and consistency.

• In-house team. Makes sense above a certain sustained volume, where the work justifies permanent headcount and knowledge stays with the organization. The risk is understaffing relative to spend, which is extremely common, and creating a small team with no career progression.
• Owner's representative. Makes sense for organizations building periodically, or entering unfamiliar geographies or building types. The rep brings capability you don't need permanently. The failure mode is treating it as transactional: a different rep on each project, with nothing accumulating on your side.
• Hybrid. A small internal core that owns standards, data and governance, with owner's reps executing projects within that framework. This is what most successful non-builders converge on at scale. The internal team is the memory. The reps are the capacity.

Whichever model, the standards and the data should belong to the organization, not to whoever is currently executing. That's the part that gets lost.

How many people should you have

Every organization asks this and there's no credible public benchmark, which is worth saying plainly rather than inventing one. Published ratios of construction spend per project manager vary so wildly across project type, geography and delivery model that any single figure would be misleading.

What's more useful is asking a different question: how many concurrent projects can one person actually carry, given your project type?

A rollout operator managing near-identical small builds with a standard prototype and a national GC agreement might reasonably run many at once, because the variability is low and most decisions were made once at the standard level. Someone managing complex renovations on occupied sites, each with different existing conditions, stakeholders and approvals, saturates at a much smaller number.

The practical test isn't a ratio. It's whether your people are managing projects or reacting to them. When the answer to "what's the status" is consistently "let me find out," the team is past capacity regardless of what a benchmark says.

Two patterns worth watching for specifically. The first is a team that was correctly sized for a program that has since doubled, where nobody revisited the staffing because it happened gradually. The second is a team where everyone is a generalist and no one owns standards, data or process improvement, because all capacity goes to active projects. That second one is how organizations stay stuck: there's never time to build the capability because everyone is busy compensating for not having it.

Where to start

If the diagnostic above went badly, the sequence that tends to work is smaller than people expect.

1. Assemble your cost history first. Pull the final cost, original estimate, and basic characteristics of every project you've completed in the last three to five years into one consistent format. This is unglamorous, takes weeks not months, requires no software purchase, and gives you something you've never had: a reference point for every future estimate. Most organizations discover their estimates have been biased in a consistent direction, which is immediately actionable.
2. Name an owner. One person accountable for how the organization builds, with authority over standards and process. Not a coordinator.
3. Document the process once. Whatever your best team currently does, write it down and make it the default. It doesn't need to be optimal. It needs to be the same every time, because you can't improve a process that varies by who's running it.
4. Standardize what genuinely repeats. Prototype designs, specification packages, contract templates, documentation formats. Put the creative energy into what's actually different about each project.
5. Then look at systems. Software applied to an undefined process digitizes the inconsistency. Applied to a defined one, it makes the data accumulate. Order matters here.

Making the case internally

The hardest part of this is rarely the work. It's getting organizational attention for a function that doesn't generate revenue and isn't anyone's strategic priority.

A few things that tend to land with executives.

• Frame it as business risk, not construction risk. Nobody outside the function cares about change order rates. Everyone cares that the new distribution center is on the critical path of the fulfillment strategy. Translate construction exposure into the business outcome it threatens.
• Lead with estimate accuracy. If you can show that the organization's estimates have been consistently off by a measurable amount, you have a finance conversation rather than a facilities conversation. Finance understands systematic forecast error.
• Use the repetition argument. "We build forty of these a year and we're not getting better at it" is an operational efficiency claim, which is language every executive team already speaks.
• Ask for something small and specific. Assembling cost history and naming an owner are cheap and concrete. Asking for a platform and headcount in the first conversation usually fails; asking for permission to find out how accurate your estimates have been usually doesn't.
• Bring the number you don't have. The most effective version of this conversation often starts with "I can't currently tell you what we spend per square foot on a standard build, and I think that's a problem." Executives find missing information more alarming than bad information.

The systems question

Software doesn't create operational muscle. It does determine whether what you learn can accumulate.

The practical requirement for a non-builder is narrower than most construction software is designed around. You need consistency across projects more than depth within one. You need cost data that's comparable between the store you built in March and the one you're pricing now. You need visibility across a portfolio without opening each project. You need the record to survive a project team turning over.

That's a different requirement from what a general contractor needs, and it's why contractor-oriented platforms often disappoint non-builders who adopt them. They produce excellent detail about one project's execution and no clean way to compare across forty.

The distinction matters more than the feature list. If your systems don't make projects comparable, your organization cannot learn from its own repetition, and the repetition paradox holds no matter how much you build.

Where INGENIOUS.BUILD fits

INGENIOUS.BUILD is built for the owner side of construction rather than the builder side, which is the relevant distinction here.

Projects run on a consistent structure, so the tenth build is documented the way the first one was and the data is comparable. Capital planning connects to live project financials, so portfolio forecasts reflect what's committed rather than what was assumed. Funding source tracking handles programs drawing on multiple sources with different reporting obligations. And every party works in their own connected workspace, so the record belongs to the owner and survives whichever GC, rep or internal team was involved at the time.

That last point matters most for non-builders specifically. Your contractors change. Your team changes. The organization's memory of how it builds should not depend on either.

Book a demo if building at scale is something your company does without being a construction company.

The short version

If your organization builds regularly, construction is already a core function whether or not it's organized like one. The spending is real, the business impact is on the critical path, and the failures show up somewhere other than the construction budget.

The gap for non-builders isn't usually money or intent. It's that nothing accumulates. Projects repeat and learning doesn't, because no process, no standard and no system was set up to carry it forward.

That's fixable, and it's mostly not a software problem. It's a decision to treat something you do constantly as something you should be good at.

FAQ

What does it mean to manage construction as a non-construction company?

Running capital construction projects where building isn't your core business, such as retailers opening stores, technology companies building data centers, manufacturers building plants or health systems expanding facilities. The organization funds and owns the asset while contracting out the building.

Why do non-construction companies struggle with construction projects?

Usually because the capability hasn't scaled with the spending. Common causes include estimates never calibrated against the organization's own project history, approval processes designed for other kinds of spending, information asymmetry against experienced contractors, institutional knowledge that leaves with individuals, and no single person accountable for how well the organization builds.

What is the repetition paradox in corporate construction?

Organizations that build the most repeatable projects, such as prototype stores or standard data halls, often learn the least across them, because each project runs through a different team with different documentation and nothing structured carries forward. High repetition, low learning rate.

Should companies build an in-house construction team or use an owner's representative?

It depends on sustained volume. In-house makes sense at consistent scale, keeping knowledge in the organization. Owner's reps suit periodic building or unfamiliar geographies. Most organizations building at scale converge on a hybrid: a small internal core owning standards, data and governance, with reps providing execution capacity.

Why doesn't contractor software work well for corporate construction programs?

Contractor platforms are built for depth within a single project's execution. Non-builders need comparability across many projects, portfolio visibility without opening each one, and records that survive team turnover. Those are different requirements, which is why detail-rich contractor tools often can't answer what a portfolio costs.

What should a corporate construction function actually have in place?

A documented repeatable process every project follows, enforced design and documentation standards, accumulated cost and outcome data, people with career paths so knowledge stays, and governance sized appropriately for construction decisions rather than borrowed from procurement.

How should a company measure its construction function?

Estimate accuracy across completed projects, schedule variance measured from funding approval rather than notice to proceed, change orders broken down by cause, portfolio forecast reliability, and cost per unit by project type compared to the organization's own history.

What's the biggest hidden cost of construction delays for non-builders?

The business consequence rather than the construction overrun. A missed store opening loses a selling season, a delayed plant misses a product launch, a late data center can't serve capacity already committed. These typically exceed the construction cost variance that caused them.

How many people should manage a corporate construction program?

There's no credible public benchmark, since ratios vary enormously by project type, geography and delivery model. A better test is whether your team is managing projects or reacting to them. If the answer to "what's the status" is routinely "let me find out," the team is past capacity.

Where should a company start improving its construction function?

Assemble cost history from completed projects into one consistent format, name a single owner accountable for how the organization builds, document the current process so it's the same every time, standardize what genuinely repeats, and only then evaluate systems. Software applied to an undefined process digitizes the inconsistency.

How do you make the internal case for investing in construction capability?

Frame it as business risk rather than construction risk, lead with estimate accuracy since finance understands systematic forecast error, use the repetition argument as an operational efficiency claim, and ask for something small and specific rather than headcount and a platform in the first conversation.