Modular and Offsite Construction Software Problems: The 5 That Fill Your Yard, and How to Avoid Them

Why does the module record get scoped last when it is the spine?

Because every part of it already exists somewhere. The design origin is in the model. The bill of materials is in the design to manufacture chain. The routing is in a production spreadsheet. The inspection records are in a folder of PDFs. The set sequence is in a schedule the site team maintains. Snagging is in a construction management tool. Nothing is missing, so the module record looks like duplication.

It is not duplication, it is the spine. One serial per module carrying its project, type and variant, its bill of materials as built rather than as designed, its station history with timestamps, its inspection sign-offs, its transport load, its set position and date, and everything raised against it afterwards for the warranty life of the building. Every other feature in this category is straightforward once that exists and impossible before it.

The projects that go wrong build the planner first, because the planner is what the operations director asked for. Then the planner needs to know which modules exist, in what state, and there is no authoritative answer, so it gets fed from a spreadsheet and inherits every error in it. Build the record, get station scanning live so the record is current, then build the planner on top of data people already trust. Vertex BD and hsbCAD are strong at the front of this chain and stay in your stack. They are design to manufacture tools rather than production control systems, and treating them as though they were is a common and expensive mistake.

What goes wrong with bills of material and as-built data from the design environment?

The design environment holds the module as designed. Production needs it as built, and the two separate immediately.

The first gap is granularity. A model carries assemblies suited to design coordination, not the picking and staging structure a line needs, so somebody re-authors the bill of materials by hand into a production form. That translation is where errors enter, and it happens again for every variant. Corner modules differ from mid runs, accessible rooms differ from standard, mechanical and electrical routing differs by riser position, and if each variant is a manual re-authoring you now have dozens of chances to be wrong.

The second gap is the return path. Substitutions happen on the line. A different fixing is used because the specified one did not arrive, a service is routed slightly differently because of a clash, a component is swapped by a supplier. If none of that flows back into the module record, the as-built diverges from the design silently, and you discover it at set when a service does not line up or four years later when a warranty claim needs to know what was actually installed.

Taking the bill of materials directly from the design environment is worth doing and it is specific to whether you run Revit, Vertex BD, hsbCAD or something bespoke, so price it as an integration rather than assuming it. Then make substitution capture a two-tap action at the station, because a change nobody can record easily is a change nobody records.

Why do design, ERP (Enterprise Resource Planning) and shop floor integrations break after launch?

The design integration breaks when a template changes. Somebody restructures a family or renames a parameter in the model authoring environment, the extraction stops finding what it expected, and either the import fails loudly or, worse, it succeeds with gaps. Insist that every extraction run reports counts in, counts matched and rows rejected with reasons, on a screen rather than in a log.

The ERP integration breaks on job costing boundaries. Purchasing and cost live in the ERP, production state lives in the new system, and the two have to agree on what a module costs and when. Decide at design time which system owns each number and where the reconciliation view lives, because the alternative is a monthly argument between production and finance that neither can win with data.

Shop floor tracking breaks physically rather than digitally. Barcode and radio frequency labels on modules and major components are technically simple and need real thought about survivability: a label has to pass through a paint booth, sit in a yard through a winter, and still scan on a wet morning before a set. That is a materials decision, not a software one, and it is routinely discovered after the first hundred labels have failed. Test the label in the actual process before you standardise on it.

What happens when inspection records and site readiness gates are not covered?

Two gaps, both cheap to close and both expensive to leave open.

Modular units are typically inspected in the factory by a third party agency under a state or national modular programme and labelled accordingly, because the local building official never sees the inside of a closed wall. That inspection record belongs to the module serial for the life of the building, alongside material certifications, fire stopping evidence and commissioning results. Keep them in folders and a warranty claim four years later begins with somebody hunting for which inspector signed which unit. Attach them to the serial and the whole package exports in one action, which also shortens handover, since a client's turnover requirement is usually organised by unit.

The second gap is site readiness. Modules cannot be set on foundations outside tolerance, cannot be set when the crane is not erected, and cannot be set when a road closure has not been granted. Every experienced manufacturer has delivered to a site that was not ready and paid for the standing time, the return trip or the temporary storage. A readiness gate before dispatch is one of the cheapest features in this whole category: a defined checklist owned by the site, including foundation survey acceptance against tolerance, crane readiness, access and permits, confirmed within a window before a load is released. It converts a recurring argument into a documented condition, and when a site fails the gate you hold the record that explains the delay rather than absorbing it.

Should you build custom or configure what you already own?

Stay where you are if you produce repetitive panels to a fixed catalogue with short lead times and little yard time. Your design to manufacture chain plus a disciplined spreadsheet is genuinely adequate at that shape, and ManufactOn is a sensible step up for prefabrication tracking and material flow without commissioning anything. Vertex BD and hsbCAD stay in your stack either way, because design to manufacture is not what you would be replacing.

Build when two or more of these are true. You produce volumetric modules where each unit is a variant and a client change ripples across dozens of serials. Your yard regularly holds weeks of finished inventory and nobody planned for it. You deliver to crane set sequences your production line cannot naturally produce. You carry third party inspection obligations per module and warranty exposure measured in years. Or you run more than one factory serving overlapping projects, at which point the allocation decision alone justifies the system.

The honest test is whether your yard is a buffer or a symptom. A yard holding a week of modules is a sensible buffer. A yard holding six weeks is the schedule reconciliation problem made physical, and no amount of production efficiency fixes it, because the line was never the constraint.

How do hidden costs get into the quote?

Five drivers, and each is worth pinning down before a contract exists.

• Design environment integration. Pulling the bill of materials directly from Revit, Vertex BD or hsbCAD is specific to your setup and to how disciplined your model templates are. Priced as a connector, delivered as a translation exercise.
• Multiple factories. Balancing production across plants is a materially harder scheduling problem than sequencing one line, not a deployment of the same thing twice.
• ERP integration for purchasing and job costing. Straightforward technically, slow organisationally, because it requires agreeing which system owns which number.
• Labelling hardware. Barcode or radio frequency tags that survive a paint booth and a winter in a yard are a materials trial, not a purchase order.
• Supplier line side scheduling. If your model depends on just in time material, that is a supplier-facing capability with its own onboarding rather than an internal screen.

In Digital Heroes delivery experience a first release covering the module record from bill of materials to set position, station level production tracking, the planner reconciling line, yard and set sequence, and delivery manifests runs $80,000 to $160,000 over 14 to 20 weeks. A full platform adding transport permits and load planning, inspection and certification records, engineering change control, site readiness gates, punch lists and warranty history runs $200,000 to $500,000 across 9 to 18 months.

What separates a build that works from one that fails here?

Ask them to draw the module lifecycle on a whiteboard before anything is signed. It should run from design variant and bill of materials, through routing with station states, to inspection, yard location, load, set position, punch and warranty, with one serial holding all of it. A developer who draws work orders and inventory has built a manufacturing system for a factory that ships boxes and has not understood that your product gets craned into a building and then lived in for decades.

Ask how they would schedule backward from a set date through transport and yard capacity to a line slot. If the answer is a Gantt chart, they are offering a drawing of the problem rather than a solution to it. A constraint model over line stations, yard slots and set windows handles a manufacturer's real volumes comfortably, and the behavioural change it produces is the point: when the plan shows a module will sit for five weeks, somebody sees it in advance and either resequences the line or has the conversation with the site.

Ask what happens to modules already built when a design revision lands, and make them describe the disposition per state. Not started modules take the new revision. In flight modules take it if the affected station has not been passed and are flagged if it has. Complete modules get a rework instruction with a cost code or a recorded accepted deviation. That single answer separates people who have worked in manufacturing from people who have not.

Then roll out on one project and one line while existing spreadsheets keep running for four to six weeks. Production teams accept station scanning quickly when it replaces a clipboard, but schedulers need a few cycles of real set dates before they trust the planner. Adding change control and warranty to release one is the most common way these builds stall. And settle ownership of the code and infrastructure accounts before kickoff, because the module records carry third party inspection evidence and warranty history for buildings you no longer own.