From order to commission, one closed loop — a custom-furniture manufacturing platform

In custom furniture, the margin leaks between the steps, not in them

If you run a custom-furniture shop, the work is a long chain and every link is bespoke: take the order, assign it to a designer, design the piece, quote it, cut it, buy the material, pay the salesperson. At most shops each of those lives in a different tool or a spreadsheet, and the handoffs leak. Sales quotes by hand. Design redraws the job in CAD to get real geometry. The factory works out the cut list off that drawing. Procurement guesses at material. Commission gets reconciled at month-end from numbers that have since moved. The same cabinet is effectively drawn three times, and a partition that shifts 40mm after the quote has to be chased through all of it by hand — or the shop eats a wrong quote, scraps a panel, and slips the date.

The margin on a custom job doesn’t die on the shop floor. It dies in the gaps between order, design, quote, cut, material, and commission — every one a place for a number to drift out of sync with the rest.

One closed loop on one source of truth

We built the whole chain as a single platform on one Neon serverless Postgres source of truth, deployed at the edge on Cloudflare Pages, with role-specific views for sales, design, factory, and procurement. An order is entered once and moves through the loop without being re-keyed anywhere:

• Order intake and allocation. Captured once, routed automatically to the right designer and factory queue — no re-entry, no “who’s taking this one.”
• Online design. Laid out on a parametric 2D canvas in the browser; the same model exports to DXF for the designer’s CAD and re-imports cleanly.
• Automatic quoting. Price derived from the design — panels, hardware, finishes — not retyped, so a quote can’t drift from what’s being built.
• Cutting and offcut nesting. The cut list is computed from the model, and parts nest against full stock and tracked offcuts.
• BOM-driven procurement. Material requirements roll up from confirmed orders, so you buy what the jobs need instead of a guess.
• Commission settlement. Calculated from the real order value as the order closes, without a month-end reconciliation.

Because every stage reads the same record, a dimension change updates the quote, the cut list, the material order, and the commission at once. The rest of this report covers the parts that were hard to get right, and the tradeoffs in each.

The parametric model has to survive a CAD round-trip

The platform stands on one decision: there is exactly one geometric model per piece, and every downstream stage reads from it rather than re-deriving it. The obstacle is that designers won’t give up desktop CAD, so the model has to leave the browser, get edited there, and come back without losing its meaning.

We do that with a DXF round-trip, and what makes it survive is that the model is parametric, not a bag of line segments. A panel isn’t four hard-coded coordinates; it’s a rule — panel width is (total width − side stile − head fitting) / panel count, track segments derive from the run length, hardware sits at positions computed off the carcass, snapping is a formula rather than a hand-placed offset. When the DXF comes back we re-read it against those rules instead of trusting raw coordinates, so a designer nudging a partition in CAD changes the parameter and everything keyed to it moves with it.

The alternative we rejected was flatten-and-trust: export the design as final geometry, let CAD become the master, import whatever comes back as the new truth. It’s simpler and it’s how most exports work, but it kills the loop — once geometry is the master, the quote and the cut list go back to being typed off a drawing, which is the manual re-check we were trying to delete. Keeping the model parametric on both sides of the round-trip is more work in the importer, but it’s what lets a 40mm change propagate to the saw without anyone re-measuring. That propagation is the single feature that removed the factory’s manual cut-list verification.

Nesting is a packing problem with a cost function you have to choose

Breaking a job down for the saw looks like a geometry task and is really an optimization one: lay every part onto available board to waste as little as possible. The decisions that matter aren’t in the packing algorithm — they’re in what you tell it to optimize and what stock you let it pack onto.

The first tradeoff is offcuts versus full sheets. Remnant inventory is real on the platform: every cut leaves tracked offcuts on the rack, and the nester packs the next job onto those remnants before it touches a fresh sheet — that’s where most of the saved material comes from. But you can’t only chase remnant utilization. Packing a job across a dozen odd-shaped offcuts can beat a clean sheet on raw yield and still be the wrong call, because it means a dozen saw setups, more handling, more chance of a mis-cut. So the cost function isn’t pure yield; it weighs board saved against cut complexity, and past a threshold prefers a sheet that cuts cleanly over a remnant jigsaw that saves a few percent.

The second tradeoff is utilization versus cut path. The tightest nesting often produces a cut sequence the saw can’t follow — non-guillotine layouts, awkward rotations, parts that can’t be freed without re-fixturing. We constrain the nester toward layouts the shop’s saw can actually run, trading a little theoretical utilization for a cut list the floor can execute. The right answer is shop-specific, so these weights are tunable — a beam saw and a sliding table don’t want the same tradeoff.

Procurement is the BOM rolled up, not a separate guess

Procurement used to be where a job got priced twice — once in the quote, again when someone estimated what to buy — and the two never matched. On the platform, purchasing is downstream of the same model. Each confirmed order already implies a bill of materials: the parametric model knows its panels, its edge-banding runs, its hardware counts, its finish areas. Those line items roll up across all confirmed orders into aggregate requirements, net of what’s already on the rack as tracked remnant and on-hand stock, and that net figure becomes the purchase need.

The decision worth calling out is timing — what counts as demand. We roll up from confirmed orders only, not quotes still in flight, because pulling unconfirmed work into purchasing is how a shop buys board for a job that never lands. Quoting and procurement read the same BOM, but procurement waits for the order to firm up before it commits money. Buying then tracks real, netted demand instead of a per-job estimate, and because the BOM is derived from the model, a dimension change re-nets the requirement automatically rather than leaving a stale purchase order behind.

The commission engine is rules, not a hard-coded percentage

Commission isn’t one rate. Different salespeople are on different splits, product lines carry different margins and so different commission rules, and a single order can mix lines that each pay differently. Hard-coding any of that guarantees a rewrite the first time the shop changes a rate or adds a line.

So commission is a configurable rule engine, not a number in the code. Rules are keyed by salesperson and product line and resolve against the order’s real, closed value — the same value the quote produced from the model — so the split is computed at close from numbers that can’t have drifted. Because the rules are data, the shop can re-tier a salesperson or onboard a product line without a code change; because the input is the actual order value rather than a re-keyed figure, the month-end reconciliation that used to chase moved numbers isn’t needed.

A four-role model with ownership enforced server-side

Sales, design, factory, and procurement each get their own view, and the obvious way to build that is to hide what a role shouldn’t see in the UI. We do that too — but the UI is a convenience, never a control. Before the API answers any request for a record, it re-derives server-side who owns that record and whether the caller is entitled to it, on every call.

This matters because the failure it prevents is the most common serious web bug there is. A logged-in, valid user who changes an ID in a request and reads someone else’s order is exploiting Broken Access Control, which OWASP ranks as the top web risk. The defense isn’t clever, it’s discipline: ownership is a server-side check on every read and write, applied as the default for every endpoint rather than added to the sensitive ones — because the sensitive ones are exactly the ones you forget.

Deploys don’t stop production

A shop quoting and cutting through the day can’t be handed an outage window for a deploy. Schema migrations are forward- and backward-compatible — new code runs against the old schema and old code against the new — so a migration is a rolling change, not a stop-the-line event. Design files live in object storage referenced from Postgres rather than as blobs inside it, which keeps the database fast to migrate and file delivery off the query path. CSP and CSRF hardening run throughout, and deploys go out by CI direct-upload to skip build-queue stalls.

The result

The loop closes. An order taken on Monday is allocated, designed, quoted, cut, sourced, and settled in one system, on one set of numbers. The cabinet drawn three times is drawn once, and the quote, the cut list, the netted purchase requirement, and the commission split all read that one model — so a 40mm change updates every one of them at once. Offcuts that were scrap are inventory the nester reaches for first. The gaps where margin used to leak are gone, because there are no longer separate copies of the truth to drift apart.