Industry
Software engineering for Construction
Construction is one of the least digitised major industries for real reasons: the work is fragmented across many parties, the conditions on site are genuinely hostile to software, and adoption is low because most tools were designed for the office, not the person in a hi-vis with muddy gloves and no signal. The value is in removing real friction from that reality: a defect logged where it is found, a valuation that reconciles, a safety record that actually exists, not in a dashboard nobody on site will ever open. We build for the site, and we are honest about what site teams will and will not use.
Why the domain matters
Construction is notoriously under-digitised, and unlike some industries that is not because nobody has tried. It is because the structural realities of the work are genuinely hostile to software. A single project is delivered by a shifting coalition of parties: a client or developer, a main contractor, dozens of subcontractors, architects, structural and services engineers, quantity surveyors, and suppliers. Each with their own systems, their own commercial interests and no obligation to share data cleanly with anyone else. The site itself is a place of mud, weather, poor connectivity, gloves, hard hats and people who are paid to build, not to type. And the industry runs on thin margins and long, adversarial contractual chains where information is commercial leverage. Any software that ignores any of that dies on contact with a real site, however good it looked in the office.
The market has a shape worth naming, because software lands very differently at each point. Main contractors care about programme, cost, subcontractor coordination, quality and safety across a whole project, and they carry the heaviest compliance load. Subcontractors run leaner and are rightly sceptical of yet another portal a main contractor asks them to log into for free. Developers and clients care about cost certainty, progress and the paper trail that protects them. Consultants (architects, engineers, surveyors), own the design and the models and the valuations. And underneath all of them sits the person on site, whose adoption or rejection quietly decides whether any of it works, because a tool the site team will not use produces no data, and a construction system with no data is just an expensive intranet. The genuinely hard part is not the features: it is that the data is fragmented across many parties, the conditions are difficult, and adoption is low for rational reasons.
We are a senior-led team and we operate what we build, so we start from the site and the fragmented reality rather than from the dashboard we would like to sell. The recurring failure mode in construction software is the comprehensive platform that assumes every party will enter clean, timely data into it, and then sits empty because the subcontractor never logged in, the site manager could not get signal, and the surveyor kept using their spreadsheet because it was faster. We would rather build the narrow thing that a site team genuinely adopts: a defect logged in seconds where it is found, a daily log that takes two minutes, a valuation that reconciles against the actual measure, than the all-singing platform that wins the tender and then produces no usable data. We will also be blunt with you about which digitisation is worth it and which just adds a login, because in this industry that honesty is the difference between a working tool and expensive shelfware.
The challenges in construction
Low adoption is rational, not stubborn
Site teams reject software for good reasons: it is slow on a phone with gloves on, it needs a signal that is not there, it asks for data entry that gets in the way of building, and it was plainly designed for someone at a desk. Subcontractors resist yet another main-contractor portal they get nothing from. Treating this as user stubbornness is the classic mistake. It is a rational response to tools that do not fit the work, and any plan that assumes adoption instead of earning it produces an empty system and no data.
Data fragmented across many parties who do not want to share
A project’s information is scattered across the client, main contractor, every subcontractor, the design consultants and the suppliers. Each with their own systems and their own commercial reasons to hold information close. There is no single source of truth and no obligation to create one, and information is often deliberately used as contractual leverage. Software that assumes clean, willing data-sharing across that adversarial chain ignores how the industry actually protects itself, and most of the real work is coping with fragmentation rather than wishing it away.
The site is a genuinely hostile environment for software
Poor or no connectivity, weather, mud, gloves, hard hats, bright sun on a screen and people whose hands are full are not edge cases on a construction site. They are the normal operating conditions. Anything built for the office and carried onto site fails there. Offline-first behaviour, ruthless simplicity, large touch targets and capture-in-seconds are not nice-to-haves; they are the difference between a tool that gets used at the point of work and one that gets abandoned at the gate.
Programme, cost and quality are commercially adversarial
Construction runs on long contractual chains where delay, variation and defect are contested and expensive, and where the record of who did what and when is commercial ammunition. Software that touches programme, valuations, variations or defects is stepping into that contested space, so it has to produce records that stand up, attribute clearly, and reconcile, because a cost or progress figure that cannot be trusted or defended is worse than no figure at all when the claims start flying.
Safety and building-safety obligations that carry legal weight
Health and safety in construction is heavily regulated. CDM 2015 assigns real duties to clients, principal designers and principal contractors, and the Building Safety Act has sharpened the duty to keep a golden thread of information on higher-risk buildings. These are not box-ticking; they are legal obligations where the record has to exist, be accurate and be retained. Software that touches safety has to make the right record easy to create at the point of work, because a safety record that does not exist because the tool was too painful to use is a genuine liability.
BIM and document control that are heavier than they look
BIM models and construction documents are large, versioned, federated across many disciplines, and governed by information-management standards. The hard part is rarely viewing a model: it is version control, the common data environment, keeping the right revision in front of the right party, and managing the federation of models and drawings so people build from current information rather than a superseded PDF. Underestimating document and information management is a reliable way to ship something that looks capable and quietly lets people work from the wrong revision.
What we build for construction
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Project and programme management
Software to plan and track programme, progress and the coordination of many trades across a project, built to reflect that a construction programme is a living, contested thing, not a tidy Gantt chart that survives first contact with the weather and the subcontractors. We focus on the coordination and the record that actually help a project manager see slippage early and defend the programme, rather than on planning ceremony that looks impressive and diverges from the site within a week.
Site management and daily logs
Site diaries, daily logs, labour and plant records, progress photos and weather, captured on site in seconds, offline-first, by people wearing gloves. This is where adoption is won or lost, so we build ruthlessly for capture at the point of work with large targets and no dependence on signal, because a daily log that takes two minutes and works with no bars gets filled in, and one that needs a desk and a connection simply does not get done.
Snagging, defects and quality
Defect and snagging tools that let someone log an issue where they find it (a photo, a location, a trade, a few taps), and route it to the responsible subcontractor to close out, with the record retained. We build these to work offline and fast because snagging happens on the walk-round, not at a desk, and the value is a defect captured and attributed the moment it is seen, closing the loop that otherwise gets lost between clipboard, email and memory.
Procurement and subcontractor coordination
Tools to manage packages, subcontractor engagement, RFIs, variations and the flow of information between main contractor and trades, designed with a clear-eyed view that subcontractors will not adopt a portal they get nothing from. We build for genuinely two-sided value and minimal friction, because coordination software only works if the other parties actually use it, and in construction that means giving the subcontractor a reason beyond the main contractor’s convenience.
Health, safety and compliance
Systems for the safety obligations that carry real legal weight, inductions, permits, method statements and risk assessments, inspections, and the record-keeping CDM 2015 and the Building Safety Act require, including the golden thread on higher-risk buildings. We make the right record easy to create at the point of work and reliably retained, because in safety the failure mode is a record that does not exist because the tool was too painful to use, and that is a liability, not just a gap.
Cost, valuations and document control
Cost tracking, applications and valuations that reconcile against the actual measure, and document control built on a proper common data environment with real version control across federated models and drawings. We treat the reconciliation and the revision management as the core problem, because a valuation that does not tie out or a party building from a superseded drawing does immediate commercial and physical damage. This is where getting the unglamorous data plumbing right matters most.
Where we help
A snagging tool site teams actually use on the walk-round
A contractor wants defects captured and closed out instead of lost between clipboards, photos and emails. The real work is making capture take seconds on a phone, offline, with a photo, a location and a trade, and routing each defect to the responsible subcontractor to close. Get that right and the walk-round produces a real, attributed record that stands up; get it wrong (a slow form that needs signal), and the site team goes back to the clipboard and the tool produces nothing, which is the usual fate of construction software.
A daily log that gets filled in because it takes two minutes
A main contractor wants reliable daily records (labour, plant, progress, weather, photos), across sites, for both operations and the inevitable contractual disputes. We build capture that works with no signal and minimal typing, syncing when connectivity returns, because the value is a complete, timely record that actually exists. A daily log is only worth anything if it is done every day, so we optimise ruthlessly for the two-minute reality of a busy site manager rather than a comprehensive form nobody completes.
A valuation and cost flow that reconciles and defends
A quantity surveyor and commercial team want applications, valuations and variations that tie out against the actual measure and produce a defensible record when the claims start. We build the reconciliation and the attribution as the core, because in construction a cost figure that cannot be trusted or traced is worse than useless once the contractual chain turns adversarial. The point is numbers the commercial team can stand behind, not a dashboard that looks confident and falls apart under scrutiny.
A safety and golden-thread record that genuinely exists
A principal contractor needs inductions, permits, inspections and the building-safety information trail to be complete and retained, not aspirational. We make each record easy to create at the point of work: an induction on a phone at the gate, an inspection captured on the walk, and reliably stored, because CDM 2015 and the Building Safety Act make the existence and accuracy of these records a legal duty. A safety system that is too painful to use produces gaps exactly where the liability is highest, so adoption is the whole game.
How we build for construction
We start from the site and from adoption, not from the feature list. Before designing anything we want to see how the site manager, the surveyor and the subcontractor actually work: where the signal drops, what they capture on a clipboard today, and why the last three tools they were given got abandoned. In construction the constraint is almost never the feature set, it is whether the person at the point of work will use it in gloves with no bars, so we design for that person first and treat everything else as secondary.
We are unusually blunt about what is worth digitising in this industry, because construction is full of software that produces no data. Removing real friction: a defect captured where it is found, a daily log done in two minutes, a valuation that reconciles, is worth building. Adding a portal that a subcontractor gets nothing from, or a comprehensive platform that assumes clean data-sharing across an adversarial chain, usually is not, and will sit empty. We would rather tell you that early, and build the narrow thing that gets adopted, than let you commission the impressive platform that becomes expensive shelfware.
We build offline-first and fragmentation-aware as a matter of course. The connectivity is not there, the data lives across many parties who will not share cleanly, and there is no single source of truth to lean on, so we design for capture without signal, for reconciliation across systems that do not agree, and for the reality that you often control only your own slice of the project’s information. Pretending the environment is a tidy connected office is the single most reliable way to fail here.
Because we operate what we build, the people designing a daily-log capture or a valuation reconciliation are the ones who hear about it when a site team quietly stops using the tool or a figure will not tie out. That keeps us honest about the only metric that matters in construction software (did the people at the point of work actually adopt it), and stops us shipping something that demos well to a director and then produces nothing on the site it was meant for.
Regulation and compliance
Construction carries a serious, legally-weighty compliance load, and health and safety sits at its centre. The Construction (Design and Management) Regulations 2015 assign specific duties to clients, principal designers and principal contractors around planning, managing and recording how a project is delivered safely, and much of that duty is discharged through records that have to exist, be accurate and be retained. Where our software touches inductions, permits, method statements, risk assessments and inspections, its job is to make the right record easy to create at the point of work and reliably kept, because in safety the compliance is in the record trail, and a record that does not exist because the tool was too painful is a genuine liability.
The Building Safety Act has sharpened obligations further, particularly for higher-risk buildings, with the duty to maintain a golden thread of accurate, accessible information about a building’s design and construction through its life. Software that manages building information has to support keeping that thread current, controlled and retrievable rather than scattered across email and superseded PDFs. We build document and information management with that duty in mind, because the golden thread is only as good as the version control and the common data environment underneath it.
Beyond safety, construction data touches the commercial and contractual framework: payment and valuation obligations, the retention of records that contractual disputes and adjudication rely on, and data protection under UK GDPR for the personal data of site workers, subcontractors and clients. We engineer for records that stand up, clear attribution, and lawful handling of personal data from the start, because in an adversarial industry the record is frequently the thing that protects your client.
We build systems that meet these obligations, but we are engineers, not your legal, health-and-safety or compliance advisers. The duties under CDM 2015, the Building Safety Act and the contractual framework carry real legal weight, and sign-off rests with your own competent persons and legal functions. Our job is to build software that makes the required records easy to create, accurate and retained, and to work alongside the people accountable for them, not to replace their judgement.
Integration
The defining integration reality in construction is that there is no single system of record and no willing consolidation. A project’s information is fragmented across the client, the main contractor, every subcontractor, the design consultants and the suppliers, each with their own systems and their own commercial reasons to hold data close. Much of the real integration work is therefore coping with that fragmentation: reconciling data across parties who do not agree and were never designed to, and being clear-eyed that you often control only your own slice. We build for that rather than assuming a clean, shared source of truth that does not exist.
BIM and document control sit at the technical heart of integration. Federated models across architecture, structure and services, large versioned documents, and a common data environment that has to keep the right revision in front of the right party are heavier than they look. We treat the CDE, the version control and the model federation as core engineering, because the failure mode (someone building from a superseded drawing), is physical and expensive, and getting information management right is more valuable than any model viewer on top of it.
The commercial and operational systems have to connect where it matters: cost and accounting systems, valuation and measurement, procurement and the flow of RFIs and variations between contractor and trades, and the plant, labour and supplier records that feed daily operations. These rarely share formats and often live in spreadsheets, so we integrate carefully and reconcile deliberately, because a valuation or a variation that does not tie out across systems becomes contractual ammunition rather than useful information.
And everything has to reach the site, which means integration with the reality of poor connectivity as much as with other software. Data captured offline on site has to sync reliably when connectivity returns and reconcile with the systems behind it without losing or duplicating records. We design that sync and reconciliation as first-class engineering, because in construction the hardest integration is often not between two servers but between a muddy site with no signal and the commercial systems that need what happened there.
Security and data protection
Construction software holds commercially sensitive and personal data: contract values, valuations and variations that are live commercial leverage, the design and building information that the Building Safety Act treats as a golden thread, and the personal data of site workers, subcontractors and clients. In an adversarial, thin-margin industry that combination is genuinely sensitive, so we build with access controls scoped to the party and the role, encryption in transit and at rest, and clear boundaries about which party can see which slice of a project’s information.
The multi-party nature of construction makes access control the central security problem rather than a detail. A main contractor, dozens of subcontractors and several consultants may all touch the same project with genuinely competing interests, so we design carefully for who can see and change what: a subcontractor should see their packages and not a rival’s rates, a consultant should reach their models and not the commercial figures. Getting these boundaries right in a fragmented, contested project is exactly where a careless design turns into a commercial or legal problem.
The building-safety information trail deserves particular care because it is both a legal duty and a long-lived record. The golden thread on a higher-risk building has to remain accurate, controlled and retrievable through the building’s life, which means version integrity, controlled access and the ability to prove what the record said and when. We treat that information as something whose integrity and retention are part of the deliverable, not something to be reconstructed after the fact when it matters most.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access patterns that indicate a problem across a multi-party project, keep the audit trail that a contractual dispute, a safety investigation or a data-subject request would need, and treat the ability to reconstruct exactly who saw or changed a valuation, a drawing or a safety record as part of the job, because in construction the record is frequently the thing that protects your client, and it has to be trustworthy when the claims start.
What changes
Tools site teams actually adopt, so the data exists at all
Because we design offline-first for the person in gloves with no signal, defects, daily logs and safety records get captured at the point of work instead of abandoned at the gate, which is the whole game in construction, where the usual outcome is an impressive platform that produces no data because nobody on site will use it.
Records that stand up when the chain turns adversarial
By building capture that attributes clearly and valuations that reconcile against the actual measure, the software produces records the commercial and safety teams can defend, so daily logs, variations and inspections become real ammunition and real evidence rather than figures nobody trusts once the disputes and adjudications begin.
Honest scope, so you build what works instead of shelfware
Because we are blunt about which digitisation is worth it in a fragmented, low-adoption industry, you commission the narrow thing that gets used rather than the comprehensive platform that sits empty, spending the budget on adoption and reconciliation that pay off, not on a portal the subcontractors never log into.
What we build for construction
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for construction?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in construction choose us
We are honest that construction adoption has to be earned
Site teams reject software for rational reasons, and most construction platforms fail by ignoring that. We design for the person in gloves with no signal and build the narrow thing that gets used, because a tool nobody on site adopts produces no data, and a construction system with no data is just an expensive intranet, however good the demo looked.
We build offline-first and fragmentation-aware by default
The connectivity is not there and the data lives across many parties who will not share cleanly. We treat capture without signal and reconciliation across systems that do not agree as core engineering, not edge cases, which is what separates a tool that works on a real site from one built for a connected office that never existed.
We take the safety and building-safety record seriously
CDM 2015 and the Building Safety Act make the existence and accuracy of records a legal duty, and the golden thread is only as good as the version control beneath it. We make the required records easy to create at the point of work and reliably retained, because the failure mode (a record that does not exist because the tool was too painful), is exactly where the liability is highest.
We operate what we build
The people who design a daily-log capture or a valuation reconciliation are the ones who hear when a site team quietly stops using the tool or a figure will not tie out. That keeps us honest about the only metric that matters here (whether the people at the point of work actually adopted it), rather than shipping something that demos well and produces nothing.
Common questions
Construction has famously low software adoption, why would your tool be any different?
Because we treat low adoption as rational, not as user stubbornness, and design around it from the start. Site teams reject software that is slow on a phone with gloves on, needs a signal that is not there, or asks for data entry that gets in the way of building, and subcontractors reject portals they get nothing from. We build offline-first, capture-in-seconds tools for the person at the point of work, and we scope ruthlessly to the narrow thing that genuinely gets used rather than the comprehensive platform that sits empty. We will also tell you honestly when a proposed feature just adds a login nobody will use, because in this industry a tool that produces no data has delivered nothing, however impressive the demo.
Our project data is scattered across the main contractor, subcontractors and consultants, can software fix that?
It can help, but only if it is honest about the reality: there is no single source of truth in construction, no obligation to create one, and information is often deliberately held close as commercial leverage across an adversarial contractual chain. We do not pretend that away. Much of the real work is coping with fragmentation: reconciling data across parties who do not agree, controlling who can see which slice of a project, and being clear that you usually control only your own portion. We build for that rather than assuming clean, willing data-sharing that does not happen, because software that assumes consolidation the industry actively resists is exactly the kind that ships and then sits empty.
How do you handle CDM 2015 and Building Safety Act obligations?
As design inputs that shape what the software must make easy to record and retain, not as paperwork bolted on at the end. CDM 2015 assigns real duties to clients, principal designers and principal contractors, discharged largely through records that have to exist, be accurate and be retained; the Building Safety Act sharpens this with the golden thread of accurate, accessible building information on higher-risk buildings. We make inductions, permits, inspections and information records easy to create at the point of work and reliably kept, and we build document control on proper version management and a common data environment so the golden thread stays current. To be clear about the boundary: we are engineers, not your health-and-safety or legal advisers, so sign-off on these duties rests with your own competent persons and legal functions, and we build to work alongside them.
Do we need full BIM, or is that overkill for our projects?
It depends entirely on the project, and we will tell you straight rather than upsell. The valuable, hard part of BIM is rarely viewing a model: it is version control, the common data environment, and keeping the right revision in front of the right party across federated models and drawings, so people build from current information rather than a superseded PDF. For some projects that information management genuinely pays off; for others it is heavier than the work justifies and a simpler document-control approach serves better. We would rather scope you into the level that actually fits your projects and your team’s appetite than commission a full BIM environment that becomes another thing nobody maintains, because underused information management is as useless here as any other shelfware.
Will this work on site where there is no signal?
Yes, offline-first is not an optional extra in construction, it is the baseline, and we build it in from the start. Poor or no connectivity, weather, mud and gloves are the normal operating conditions on a site, not edge cases, so anything that depends on a live connection or fiddly typing fails at the point of work. We build capture that works with no bars: a defect, a daily log, an induction taken on a phone and synced reliably when connectivity returns, without losing or duplicating records, with large touch targets and minimal input. That sync and reconciliation between a muddy site with no signal and the commercial systems behind it is some of the hardest engineering in construction software, and we treat it as core work rather than an afterthought, because a tool that only works at a desk simply does not get used where the work happens.
Building for construction?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if construction is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.