In active development

LBM Stack

An ERP for lumber and building materials — built on a ledger that cannot drift.

Inventory, purchasing, pricing, sales and delivery, over a real double-entry general ledger. Typed units of measure. Stock balances derived from an immutable movement history rather than cached and repaired.

Get in touch

What it is

LBM Stack is a complete ERP for lumber and building materials dealers — inventory, purchasing, pricing, sales, manufacturing and delivery, with the general ledger underneath all of it rather than bolted on beside it.

It deploys as one system per dealer, with your companies, divisions, regions, branches, departments and stock locations modelled inside it. It is being built from the ground up on PostgreSQL and typed TypeScript, with first-class migration from legacy systems so your history comes with you.

Built by the dealers who run it

LBM Stack is taking shape as a co-operative — non-competing building-materials suppliers sharing the cost of building one good ERP, each controlling its own copy.

  • Shared engineering, not shared commerce

    The co-op exists to share code and the cost of writing it. It is not a buying group, not a marketing alliance, and not a forum for commercial coordination of any kind.

  • Every member runs its own instance

    Own infrastructure, own database, own data. There is no shared system to hold it and no cross-member reporting — a limit built into the architecture rather than configured on top of it.

  • Source-available to members

    Members get the source, can modify it for their own operations, and can send improvements back. This is not open source, and the distinction is deliberate rather than accidental.

Nothing here is settled. The charter, the licence and the governance model are drafts under review. No entity has been formed and no terms are final.

What it covers

Nine operational areas, one data model, one set of rules.

  • Inventory

    An append-only movement ledger. Loose, by-length, by-pack and by-batch balances, holds, counts, transfers and adjustments — valued by FIFO layer, moving average or purchase price variance.

  • Purchasing

    Purchase orders, suggested ordering, receiving, landed cost and supplier returns — with promise dates linked back to the sales orders waiting on them, and drift surfaced rather than discovered.

  • Pricing

    One rule engine for what you sell and what you buy. Profiles, bands, quantity breaks, promotions, price lists, tallied surcharges and internal cost rules.

  • Sales

    Quotes, orders, reservations, call-offs and templates as one document family. Sections, status derived from the lines themselves, and a credit-control gate that runs before the order does.

  • Billing

    Invoices, credit notes and customer returns — including contract, progress and installed-sales invoicing.

  • Receivables

    Cash matching, tender, statements, aging, finance charges, write-offs, disputes, liens, and till and drawer sessions.

  • Payables

    Supplier invoices, three-way match, debit notes, payment runs, aging and supplier rebates.

  • Fulfilment

    Picking, staging and loading. Journeys, manifests and stops, driver execution, and proof of delivery with signature and photo — over a vehicle and fleet master.

  • Manufacturing

    Works orders, kit and bill-of-materials expansion, sub-order trees, cutting and scheduling.

How it is built

Four decisions that shape everything above them.

  1. Balances are derived, not cached

    Stock movements are immutable and authoritative; a balance is a rollup of them. That the rollup equals the sum of its movements is an invariant checked on every build — not a nightly repair job. A repair tool that exists is a cache that drifts.

  2. Rules are data you can diff

    Which movement type produces which accounting effect is a seeded table you can read row by row and diff between releases — not a branch buried in a stored procedure that nobody has opened in a decade.

  3. Units of measure are typed

    Board feet, lineal feet, pieces, packs and squares are distinct types, and crossing between them without a conversion is a compile error. A missing factor throws. It never quietly degrades into a number that looks plausible on an invoice.

  4. One implementation per rule

    Payment terms, promise dates, tax, pricing — each has exactly one implementation, called from every screen, job and integration. Two engines for one rule is two answers to one question.

It speaks the trade

The measurements are in the core, not in a spreadsheet somebody keeps on the side.

Units and concepts modelled in the core: board feet, lineal, MBF, squares, area, tally parsing and formatting, random length, by-pack, by-length, by-batch, and tallied grades.

Where it is

LBM Stack is in active development and has not been released. The foundation is proven end to end: receive stock against a purchase order, adjust it with a reason code, run a count variance — and all three reconcile in the trial balance.

Everything above that line is being built in slices, in the order a dealer would actually need them. There is no release date to announce yet, and nobody is running it in production. When that changes, it will say so here.

The co-op is at the same stage. Its charter, licence and governance model are written and under review; the entity that would hold them does not exist yet, and the terms are still being argued over rather than signed.

Interested?

If you run a yard, build for one, or just want to follow along — say hello.

hello@lbmstack.com