Purlin Design Software: Days of Work, Done in Minutes.

For most of the last two decades, the honest answer was a day. Sometimes two. Here is where those hours went, and why they no longer need to.

Ask any structural engineer who came up through a steel-framed building practice, and they will tell you the same thing: purlin design was a rite of passage. Slow, fiddly, and expected to be slow and fiddly.

When I first started, as an intern, I remember being told it was ok to spend a day or even two days on a purlin design.

Matt Ford — Temporary Works, Peritas

That expectation was reasonable when the tooling was a spreadsheet, a frame analysis package and a PDF of manufacturer capacity tables. It is no longer reasonable. And the gap between what the work is worth and what it costs is exactly where budget quietly disappears.

Where the hours actually went

The traditional workflow for a large roof was not one task. It was six, chained together, each one handing off to the next:

1. Populate a spreadsheet with geometry, bay spacing and loads for each purlin zone.
2. Run a script to generate a frame analysis model of each zone.
3. Fix the outputs inside the model by hand, because the generated version was never quite right.
4. Compare the bending moment diagram against manufacturer design tables, visually, line by line.
5. Record utilisations in a separate spreadsheet so nobody could claim a zone had been missed.
6. Sketch it up for the drafter, because none of the above is a drawing.

Every one of those handoffs is a place where a number gets retyped. Every retyped number is a chance to be wrong in a way that no downstream check will catch.

The revision problem

None of that would matter much if buildings were designed once. They are not. Bay spacing moves. The architect adds a metre to the ridge. The wind classification changes when the site survey comes back. And then:

As soon as there was a change to the design, whether it be bay spacing, building dimensions, wind loads, the whole process would need to be repeated, or you would need to adjust the model manually, which increases opportunities for errors.

Matt Ford — Temporary Works, Peritas

So the engineer faces a bad choice on every revision. Rebuild the model properly and spend the hours again, or patch it by hand and accept the risk. Most people patch. Most of the time it is fine. "Most of the time" is not a defensible position on a signed set of calculations.

What changes when it is one tool

Purpose-built purlin design software collapses the chain. Geometry, loads, analysis, capacity checks and the report are a single model, not five files that agree with each other on a good day. Change the bay spacing and the utilisations update. Change the wind region and the uplift case updates with it.

The measured effect, from engineers running it on live jobs, is not marginal:

• Ten times faster on full purlin designs, compared with the spreadsheet-and-model workflow.
• Design time halved on large industrial roofs, where a job previously ran one to two days.
• A thorough third-party review in about half an hour, on an existing warehouse, where a full review would once have been a budget conversation.

That last one deserves attention, because it is not really about speed.

When checking other people's work, it makes a real difference to be able to do a thorough check without having to weigh up whether you have the time or budget.

Matt Ford — Temporary Works, Peritas

Speed is a risk control, not a convenience

Two things happen when a design takes twenty minutes instead of two days.

You can afford to check properly

Thoroughness stops competing with the fee. A reviewer who can re-run the design from first principles is doing something categorically different from a reviewer skim-reading someone else's spreadsheet.

You can afford to price properly

Concept and tender work is unpaid until it is won. Hours spent on speculative purlin design are hours at risk. Compress them, and the exposure compresses too.

The hours PurlinIQ saves directly reduces financial and reputational risk during these early project phases.

Matt Ford — Temporary Works, Peritas

The standardisation dividend

There is a quieter benefit that only shows up on the second project. When every engineer builds their own checking spreadsheet, every engineer's work is a small archaeology problem for whoever inherits it. A non-standardised check is hard to review, hard to hand over, and hard to defend three years later when the certifier asks a question.

A common method produces a common output report: zones defined, loads listed, utilisations tabulated, ready for the drafter and legible to the next engineer. The person who benefits most is the one who did not do the design.

Frequently asked