Modular and Offsite Construction Software: Why Do Finished Modules Sit in the Yard for Six Weeks?

Two schedules, one product, and a yard absorbing the difference

A volumetric modular manufacturer runs a line that produces four modules a day. The line is measured on throughput, and throughput is best when the line runs the same configuration back to back. The site team on a hotel project needs modules delivered in crane set sequence: level 4 corner unit first, then along the elevation, then the corridor modules, because that is the only order a crane and a tower position allow.

Those two truths do not reconcile by themselves, so the yard reconciles them. Finished modules come off the line, get wrapped, and sit. Six weeks later half of them are set and the other half are still there, taking damage from weather, being double handled by a telehandler, and quietly consuming the working capital that was supposed to be released when the module was invoiced.

Ask the operations director what the yard costs and you will usually get an answer about acreage. The real cost is the sum of storage, double handling, weather remediation, damage rectification at set, the finance carrying cost on completed inventory, and the occasional module that has to be partially rebuilt because it sat through a winter. Offsite construction's whole promise is that manufacturing discipline beats site improvisation. A yard full of finished product is the promise leaking away.

Problem 1: nothing in your stack owns the module from design to warranty

A module has a design origin in the model, a bill of materials, a routing through stations, a set of quality and inspection records, a transport event, a crane position, a punch list at set, and a warranty life measured in years. In almost every manufacturer we have worked with, those live in five systems: the CAD to manufacture chain, an ERP (Enterprise Resource Planning) that thinks in work orders, a spreadsheet for the set sequence, a folder of inspection PDFs, and a construction management tool for snagging.

The module record is the spine that has to exist first. One serial per module, carrying its project, its 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. Every other feature in this category is easy once that exists and impossible before.

Vertex BD and hsbCAD are strong at the front of this chain, taking design into manufacturing data for panels and frames. They are design to manufacture tools rather than production control systems, and treating them as though they were is a common and expensive mistake. ManufactOn covers prefabrication tracking and material flow credibly and is a reasonable starting point for a manufacturer whose product is simpler than volumetric.

Problem 2: the plan has to be solved against three constraints at once

Line capacity, yard capacity and set sequence. Most planning in this industry solves the first, hopes about the second and receives the third as an instruction. A build that is worth the money solves them together.

In practice that means a planner that runs backward from set dates. If module A408 must be set on the morning of 14 October, then transport is the day before or the same night depending on permits and curfews, which means it leaves the yard on a defined date, which means it must complete the line by a date that leaves the least storage time consistent with a sensible buffer, which fixes its line slot. Do that for 260 modules across three projects sharing one factory and you have a genuine scheduling problem. It is tractable: a constraint model over line stations, yard slots and set windows handles a manufacturer's real volumes comfortably, and the output is a line plan that a production manager can follow and a delivery plan the site can trust.

The important behavioural change is that yard time becomes a decision the plan makes rather than a consequence it discovers. When the plan says a module will sit for five weeks, somebody sees it in advance and can either resequence the line or have the conversation with the site about their programme.

Problem 3: every module is a variant, and the design keeps changing

Modules are not identical units. Corner modules differ from mid runs, accessible rooms differ from standard, mechanical and electrical routing differs by riser position, and client changes land mid production. A change to a room type can affect 40 modules of which 12 are already complete, 9 are in flight at various stations and 19 are not started.

That is engineering change control and it is the part manufacturers most often try to run on email. A build makes the change an object: what changed, which modules are affected, and a per module disposition depending on 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 an accepted deviation recorded against that serial. Without this, the as built record diverges from the design, and you discover it at set when a service does not line up.

Problem 4: transport is a separate discipline that breaks set days

Modules are oversize loads. That means permits per jurisdiction, route surveys, escorts, curfew windows on some routes, and sometimes police notification. The load order on the trailers has to be the reverse of the set order, because the crane takes the last one loaded first. Get that wrong and you have a crane and a set crew standing while a truck is repositioned, and a crane day is one of the most expensive days on the whole programme.

A build handles load planning as part of the same record: which module is on which trailer in which position, which permit covers that route on that date, when it expires, and who is escorting. Then the site receives a manifest that matches the set sequence they published, and the yard picks to that manifest rather than to whatever is nearest the gate.

Problem 5: nobody gates delivery on site readiness

Modules cannot be set on foundations that are outside tolerance, and they cannot be set when the crane is not erected or the road closure has not been granted. Every experienced modular manufacturer has delivered to a site that was not ready and paid for the standing time, the return trip or the temporary storage.

The fix is a readiness gate before dispatch, and it is one of the cheapest features in this whole category to build. A defined checklist owned by the site, including the foundation survey acceptance against tolerance, crane readiness, access and permits, that has to be 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 have the record that explains the delay.

Problem 6: inspection and labelling records are compliance, not paperwork

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 does not see the inside of a closed wall. That inspection record belongs to the module serial for the life of the building, along with material certifications, fire stopping evidence and commissioning results.

Keeping those in folders means that a warranty claim four years later begins with somebody hunting for which inspector signed which unit. Attaching them to the serial means the whole package exports in one action, which also shortens handover, since the client's turnover requirement is usually organised by unit.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the shape here is as follows. A first release covering the module record from bill of materials to set position, station level production tracking, the planner that reconciles line, yard and set sequence, and the delivery manifest runs $80,000 to $160,000 and ships in 14 to 20 weeks. A full platform adding transport permits and load planning, third party inspection and material certification records, engineering change control with per module disposition, site readiness gates, punch lists and warranty history runs $200,000 to $500,000 over 9 to 18 months.

What drives the number up in offsite manufacturing: taking the bill of materials directly from the design environment, which is worth doing and is specific to whether you run Revit, Vertex BD, hsbCAD or something bespoke. ERP integration for purchasing and job costing. Multiple factories, since balancing production across plants is a harder scheduling problem than a single line. Supplier line side delivery scheduling, if your model depends on just in time material. And barcode or RFID tracking on modules and major components, which is straightforward technically and needs real thought about label survivability through a paint booth and a winter in a yard.

What keeps it down: one project, one line, and the three constraints. Change control and warranty can follow once the plan is trusted.

Build versus buy, and when buying is right

Buy, or rather stay where you are, if you produce repetitive panels to a fixed catalogue with short lead times and little yard time. Your CAD to machine chain plus a disciplined spreadsheet is genuinely adequate, and ManufactOn is a sensible step up for material and prefabrication tracking without a build. 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 that 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.

How to choose a developer for modular construction software

Ask them to draw the module lifecycle on a whiteboard before you sign anything. 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 it all. 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.

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 planning to give you a drawing of the problem rather than a solution to it.

Ask what happens to modules already built when a design revision lands, and make them describe the disposition per state. That single answer separates people who have worked in manufacturing from people who have not.

Ask who owns the code, and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit, which matters here because the module records carry warranty and compliance evidence for the life of buildings you no longer own.