The Operations Platform

For the past several months I’ve been building, mostly on my own, the software that runs a small custom manufacturer. It isn’t one tool. It’s a connected platform that takes the business from a customer’s question to a costed, production-ready order. This is the work most of the writing here draws from.

It isn’t a handful of screens. Built over months and in daily use, it spans the whole stack: one engine underneath, with quoting, sales, factory costing, production data, an agentic layer, customer-facing tools, and the automation around them all:

The pieces

A product-and-cost engine. Parametric templates turn a cabinet’s dimensions into a full parts list, and a cutting-layout optimizer (MaxRects bin-packing) packs those parts onto material sheets, in one case collapsing a two-sheet layout down to a single sheet at roughly 79% utilization. From the parts list, materials, hardware, and labor, the engine derives cost and price, and keeps an audit trail of every pricing change.

Factory costing. Workstation hourly rates aren’t typed in by hand; they’re derived from labor allocation, factory overhead, machine operating cost, and consumables, with each station able to run on a manual, derived, or hybrid rate. Production costs are snapshotted when the work is actually done, so a project’s historical cost doesn’t drift when current rates change later.

Production data, fed back in. Cutting and nesting data and bills of materials are imported from the factory side (with duplicate detection) so an estimate can be checked against what the floor actually consumed, and the cost model corrected over time.

Quoting, estimates, and sales. Multi-room quotes built on the engine, including custom, configured items priced with the same finish-aware logic, on a dual one-off-vs-optimized-batch model; estimates that act as containers for several quote versions; and a sales funnel that runs from a lead through quoting to production. One sales project can spawn several factory projects (for phases, change orders, and remakes) with totals that recompute themselves as the work changes.

An agentic layer. A retrieval knowledge base plus an assistant that can read the system (through read-only, tightly-scoped database access) to generate recommendations, with a feedback loop that records whether each recommendation actually helped.

A customer portal. A self-service portal where clients build their own quotes and submit orders on top of the same pricing engine, without ever seeing cost or margin. I wrote that one up separately: one engine, two audiences.

A document-generation pipeline. Client-ready specs and catalogs are generated from the same product data the engine uses, so what goes out the door is assembled from the system rather than rebuilt by hand each time.

How it’s built

A Python/FastAPI backend over PostgreSQL and a React front end, plus the supporting pieces the agentic and automation layers lean on (a vector store, a queue and cache, a workflow runner, a file server), all self-hosted and containerized with Docker, and built incrementally, one deployable piece at a time, using Claude Code. The constraint that shapes everything is that it has to keep working for the people who use it every day while I’m still changing it.

Where it’s going

The hard part now isn’t adding features; it’s keeping a single engine correct as it serves both the internal team and outside customers, and keeping the data clean enough that the automation can be trusted. I document the pieces as they stabilize in the writing.