Expert article
Choosing construction software: the process first, the product second
Comparing feature lists is easy and rarely leads to the right decision. The better question is: which of our processes may we adapt to the software — and which may we not?
Expert article by Open Experience GmbH. · As of: September 2026
How do you choose the right construction software?
By first sorting your own processes into two groups. Primary value-adding processes — the things a firm is known for — must not be bent to fit a piece of software: whoever subordinates their core process to a standard solution afterwards works exactly like the competitors using the same solution. Supporting processes, by contrast, are in better hands with standard software, because there cost and maintainability count and no difference arises. Only after that classification is a feature comparison worthwhile.
Legal framework: Germany (Civil Code BGB, construction contract rules VOB/B, fee schedule HOAI). Other countries have different rules, and contractual agreements take precedence over the standard periods named here.
Primary or supporting — the decision before the decision
The same software can be the right choice for one firm and the wrong one for another. The difference lies not in the product but in the role the process plays.
| Characteristic | Primary value-adding process | Supporting process |
|---|---|---|
| *How to recognise it* | This is precisely what the client pays for | Necessary, but interchangeable |
| *Direction of adaptation* | The software follows the process | The process follows the software |
| *Decision criterion* | Fit, even if it takes longer | Cost, maintainability, time to introduce |
| *Risk of the wrong choice* | Losing what sets the firm apart | Resources tied up with nothing in return |
The classification is specific to each firm: for one practice site supervision is the core process, for another it is an ancillary service.
Example 1 — when efficiency is the core process
A design practice is known for particularly efficient site supervision. The division of labour is well rehearsed: experienced engineers inspect on site and dictate voice messages, and the back office turns them into tasks. Introduce a ticket system now that relieves the back office but adds work for the site management, and the very advantage the practice is known for tips over.
- The arithmetic does not add upRelief at the cheap end, extra effort at the expensive one — that is a shift, not an improvement.
- Better to wait than to bendWhere no suitable solution exists, waiting is the better decision than one that damages the core process.
- What fitting software does hereCapture the task and the image in one step, add the remark as a voice message — the back office does the evaluation as before.
The example is an illustration, not a reference — it describes a pattern that keeps surfacing in selection projects.
Example 2 — when bespoke development lands in the wrong place
An engineering practice has built a genuine lead with its own library of building services models including their geometric dependencies. Out of that good experience grows the idea of also having a task capture system built. The mistake lies not in the ability but in the classification: the practice is known for building services design, not for site supervision.
- Resources on the wrong leverDevelopment capacity missing in the core area creates a backlog exactly where the lead comes from.
- Too few people who know the processWhoever does not live the process daily can neither specify it nor maintain it over the years.
- What would have been rightAn inexpensive standard system for the secondary process — and the firm's own development where it has an effect.
The right altitude for holding data
The second selection question is about data rather than features: which information is needed every day to get the work done, and which is kept as a reference? Working data has to be where the work happens — mobile, offline, findable in seconds. Reference data belongs in an orderly archive it can be fetched from when needed. Force both into the same system and you end up with either a sluggish site app or an archive nobody can search.
- In active useDefects, inspections, photographs of the current section, current drawings — every day, reachable in a few taps.
- Kept as a referenceContracts, older drawing revisions, completed sections — filed so they can be traced, but out of the way.
- Standard plus project-specificA construction file built the same way everywhere at its core that can still take up the particulars of a project.
Questions that settle a selection faster than any demo
What do our clients pay us for?
The answer names the processes that must not be adapted.
Who enters the data?
Systems that push capture down the line fail because of the people expected to do the capturing.
Does it work without a network?
In the structural shell that is not a matter of comfort but the condition for it being used at all.
Can we get back out again?
Export formats decide whether the data belongs to the project or to the vendor.
Who maintains it in three years?
With bespoke development this is the most expensive question, and usually the unanswered one.
What does the tenth user cost?
Pricing models that penalise rolling out prevent exactly what creates the benefit.
Specialist or generalist
That leaves the question of principle: one comprehensive vendor that avoids interface trouble, or several specialised solutions that can do more within their segment. Both are defensible. What decides it is where the depth is needed: whoever runs the construction phase as a core process needs depth there and can do without it elsewhere. How that looks next to other vendors — including the question of when a competitor is the better choice — is set out on the comparison pages.
What Open Experience is at this point
Open Experience is the specialist for the construction phase: defects, photographs, site diary, checklists and 360° capture in one platform, with hardware of its own and in the language of service phase 8 of the German HOAI. Design, cost planning and payroll are somebody else's business — and that is not a gap but the decision to be deep in the core process.
Frequently asked questions
Standard or bespoke development — which is cheaper?
Standard almost always to buy, bespoke development almost never to run. The real cost question is not the introduction but the upkeep over five years.
How do I recognise a primary process?
By the fact that clients name it when they explain why they work with you. Anything that is internally necessary but interchangeable belongs in the other group.
How many systems are too many?
It is not the number that decides but the handovers. Two systems with a clean interface beat one in which half the work goes on beside it.
What is a common data environment?
An orderly environment in which every project participant works from the same status — with a clear separation between work in progress, the released status and the archive.
How long does an introduction realistically take?
The installation is a matter of days. The changeover takes a project — mainly because the old parallel routes have to be switched off, not because the software is difficult.
What do selection projects most often fail on?
On two things: the choice was made by feature list instead of by process — and the people expected to do the capturing every day were not part of the decision.
Sources and legal basis
The legal statements in this article are based on the primary sources listed below. The article is not a substitute for legal advice in an individual case.
Look at your processes first, then talk about software.
45 minutes without a product demo: we sort out with you which process sets you apart — and which one can live with a standard.