Dev.to AI 🤖 Ai 👁 0 📖 8 min read

Scaffold inventory management: why tube and fittings go missing, and how to track them job by job

Ask the owner of a small scaffolding company how much tube they own and you'll usually get a confident number. Ask how much of it is in the yard today, how much is on which site, and how much has quietly disappeared sinc

Scaffold inventory management: why tube and fittings go missing, and how to track them job by job

Ask the owner of a small scaffolding company how much tube they own and you'll usually get a confident number. Ask how much of it is in the yard today, how much is on which site, and how much has quietly disappeared since spring, and the answer turns into "we'd have to count."

That gap is the whole problem. Scaffolding is a rental business disguised as a construction trade. You buy tube, fittings, boards and frames once, and they earn money every week they're standing on someone's building. Every piece that doesn't come back from a strike, sits forgotten on a finished job, or gets bent and stays in the "good" pile is money leaking out, slowly enough that nobody notices until a big job needs more material than you actually have.

This article covers how that leak happens and what a scaffold inventory system needs to stop it. Near the end I'll build one with Mythex, the AI app builder I work on, but most of it applies to any tool, including a well-built spreadsheet.

Why scaffold stock is harder to track than normal inventory

Most inventory software assumes stock comes in, sits on a shelf, and goes out once to a customer. Scaffold material doesn't behave like that.

It leaves and comes back. The same 21-foot tube might go out to three jobs in a month. You don't care that you "sold" it; you care where it is right now and whether it came back.

It's counted in different units. Tube by length, fittings by type (right-angle couplers, swivels, sleeves, base plates), boards by length, frames and braces by size for system scaffold. "200 fittings" is meaningless if the job needs 80 swivels and you have 15.

Some of it isn't yours. When a job outgrows your stock, you hire material in from another firm. That material has to be tracked separately and returned on time, or you pay for weeks you didn't need.

It gets damaged. Bent tube, cracked boards and worn couplers must come out of use. If damaged items stay counted as available stock, your numbers are wrong and your crews end up sorting through bad material in the yard.

The records are made in the worst conditions. Loading a truck at 6am, in the rain, with a gang waiting. The system has to be faster than the delivery note, or it won't get used.

Where the material actually goes

When small firms finally do a full count, the missing stock usually comes from a few predictable places:

  1. Strikes that aren't counted. The erect gets a delivery note. The strike gets loaded onto the truck in a hurry, and nobody counts what came back. Short returns are invisible.
  2. Leftovers on finished sites. A few boards and a bag of fittings stay behind "for the roofer," and nobody goes back for them.
  3. Transfers between sites. A gang moves material straight from one job to the next without it going through the yard. Both sites' records are now wrong.
  4. Damaged items that stay in circulation. Nobody logs the bent tube, so the system thinks it's available.
  5. Hired-in material that gets mixed with yours. It looks the same. Either you return your own by mistake or you keep theirs and pay the hire.

What a scaffold inventory system has to do

If you're choosing software or building your own, these are the requirements that matter. Everything else is nice to have.

1. Stock by item and by location. Every item type has a quantity in the yard and a quantity on each active site. The total is the sum, not a separate number someone types in.

2. Movements, not just balances. Every delivery, return, transfer and write-off is a row: date, item, quantity, from, to, who recorded it. The balances are calculated from those rows. This is the single most important design decision. If people edit balances directly, you lose the history and can't find where things went.

3. Out versus back, per job. For each site you should see what went out on the erect (and any extra deliveries), what came back on the strike, and the difference. That difference report is where the leak shows up, and it's the report most owners have never seen.

4. Damaged and condemned stock. A simple "write off" or "quarantine" movement that takes items out of available stock, with a reason. Over time this tells you which items and which sites wear material fastest.

5. Hired-in material kept separate. Its own items or a flag on each movement, with the supplier and the due-back date, and a list of everything currently hired in.

6. Phone-first counting. A delivery or return screen a gang leader can complete standing next to the truck: pick the site, tap the items, enter the quantities. If it takes longer than two minutes, it'll be done "later," which means never.

7. Hire periods (if you invoice by time). Many firms charge a base period and then weekly hire after that. If the system knows when each scaffold went up and came down, it can list overruns that haven't been invoiced. That list often pays for the whole system.

8. Inspections alongside the stock. In the US, OSHA requires scaffolds to be inspected by a competent person before each work shift and after anything that could affect their integrity. Canada's provinces have similar rules. Inspections are a separate record from inventory, but they live naturally on the same site records, and a firm that already uses an app for deliveries can log inspections in the same place.

Off the shelf, spreadsheet, or custom

There are three realistic routes for a company with 5 to 50 people.

Rental or construction inventory software. Equipment rental platforms handle out-and-back tracking. Check that they cope with scaffold units and site-to-site transfers without workarounds by running one real job through a trial, erect to strike.

A spreadsheet done properly. One sheet of movements, balances calculated by formula, never typed. It breaks down when several people record from phones at once and when you want per-job reports without building them by hand.

A small custom app. This used to mean months of a developer. Now an AI app builder can make a working version from a written description, with a database, logins and a phone screen, shaped around how your yard already works.

Building it with Mythex

Here's how I'd build it in Mythex. You describe the app in chat, and Mythex writes the code, runs it with a live preview, and attaches a Postgres database. These are the prompts I'd type, in order.

First, the core:

Build an inventory app for a scaffolding company. Items have a name, category (tube, fittings, boards, system frames, other), unit, size or length, and a reorder level. Locations are the yard plus job sites; each site has an address, client, status (planned, erected, struck) and the erect and strike dates. Record every stock movement as a row with date, item, quantity, from location, to location, type (delivery, return, transfer, write-off) and the user who recorded it. Calculate the stock at each location from the movements; never store balances directly. Add user login.

Then the per-job leak report:

On each site's page, show a table per item: total sent to the site, total returned, written off on site, and the difference still on site. Add a "struck sites with material missing" report that lists every struck site where the difference isn't zero, with the quantities.

Then damaged and hired-in stock:

Add a write-off movement with a reason (bent, cracked, worn, lost) that takes items out of available stock. Add hired-in material: a supplier, a due-back date, and a flag on movements so hired items are tracked separately from our own. Show a list of hired-in items still out, sorted by due-back date.

Then the screen your gangs will use:

Add a phone screen for the truck: choose the site, choose delivery or return, then a list of items with big plus and minus buttons for quantities, and one Save button. Show the last five movements for that site underneath so the gang leader can check what they just entered.

The project's database in Mythex, with tables for items, locations and movements

Open the database tables while you build to check that movements are stored as rows. Then enter a real job from last month, erect to strike, and see whether the leak report matches what you suspect went missing.

Checking the app in the phone preview before giving it to the crews

Before handing it to the yard, try the phone screen on an actual phone: can a gang leader record a return in under two minutes without help?

What you end up with

  • One list of every item, with quantities in the yard and on each site, calculated from movements.
  • A per-site out-versus-back table, and a report of struck sites with material still missing.
  • Write-offs with reasons, so damaged material leaves available stock and you can see where it's being damaged.
  • Hired-in material tracked separately with due-back dates.
  • A phone screen for deliveries and returns, with logins so every movement has a name on it.
  • A public link straight away, and your own domain (for example yard.yourcompany.com) on a paid plan.

Honest limits

  • It only knows what people record. No app finds tube that was never logged. The phone screen has to be faster than the paper habit, and someone has to own the rule that every strike gets counted.
  • Barcodes and RFID are a bigger project. Tagging individual tubes is possible but rarely worth it for a small firm; counting by item type and quantity per movement gets you most of the value.
  • Accounting stays in your accounting tool. The app lists overruns to invoice; the invoice still goes through QuickBooks or Xero unless you build that link.
  • Clean the item list first. Five names for the same coupler means messy reports.
  • Test before you trust it. Run a real month in parallel with your current method before relying on it for a big job.

For teams

Once more than one person records movements, build the app in a shared team workspace rather than one person's account, so it doesn't depend on a single login when someone leaves. On Mythex's Business plan (from $50/month), the workspace has Admin, Editor and Viewer roles, per-member credit limits, and members-only apps that only signed-in colleagues can open, which suits an internal yard app. Sign-in through your company's Google Workspace or another identity provider is available once your domain is verified, and people with your company email can join automatically. Current plans and prices are on the pricing page.

If you run a scaffolding company and your yard works differently (system scaffold only, a second depot, material cross-hired between your own branches), describe it in the comments and I'll say how I'd model it.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.