OPERATIONS UNDER THE STOREFRONT
Assemblio
Year
2024 → present
Role
Sole engineer
Status
Rebuild in progress
Stack
Next.js 16 · Supabase · Shopify
Assemblio started as a fix for inventory drift in Shopify stores that assemble products from components. The rebuild is broader. It runs BOMs, component inventory, purchasing, goods inwards, stocktake, costing, staffing, and capacity — against Shopify as the sales channel.
Shopify still owns the catalog and the demand signal. Everything else lives in Assemblio: which components are on hand, which are reserved, what came in from suppliers, what got counted on the floor, what a job should cost, how loaded each department is on a given day.
The problem
A manufacturer selling through Shopify has two systems pretending to be enough. Shopify knows orders. The floor knows components, receipts, cycle counts, and labour. The moment products share sub-components, buy-to-build timing matters, or margin depends on who did the work, that split gets expensive.
Assemblio sits between them. Variants tie to BOMs, orders to component reservations, purchase orders to goods inwards. Stocktakes apply variance back into the same ledger. Planned work rolls up into costing and capacity.
The shape of the system
Shopify order → Active BOM — webhook resolves the variant
Active BOM → Reservation — recursive explode down to components
Reservation → Movement + Balance — append-only, transactional
Movement + Balance → Availability — derived, refreshed on a short tick
Assemblio is the operational layer under the storefront, tenant-scoped from the schema up. A Shopify order lands via webhook, resolves its active BOM, and reserves components before Shopify's own counters have been touched. The reservation writes into an append-only movement ledger, and the derived availability view is what the rest of the app reads.
Goods inwards, stocktake variances, and manual adjustments all enter the same ledger through the same invariant. Every balance has a movement behind it.
Shopify inventory is reference only. Assemblio doesn't write stock levels back. It keeps its own movement ledger and balance tables, so availability, reservations, receiving, and reconciliation all live in one place.
The hard bits
Keeping inventory truthful
Supabase is the inventory source of truth. Shopify stays the sales channel, but operational availability lives in Assemblio. Every receipt, stocktake variance, manual adjustment, and reservation writes an append-only movement record and updates the derived balance for that component and location.
That invariant matters because the app has to hold up under audit, reconciliation, and recovery. If a balance ever changes without a movement behind it, the system is lying. The rebuild has one code path for inventory math. No side doors.
Allocating components from live Shopify demand
Orders sync in from Shopify and land as local orders and order lines. Each line immediately drives component reservations through the active BOM for the ordered variant. Availability stops being "how many finished goods are left" and becomes "are the required components on hand once already-reserved stock is taken out."
That turns Assemblio into a planning surface. Missing BOMs, weak component coverage, and over-reservation all show up before the floor feels them.
Stocktake and goods inwards on the same ledger
Stocktake sessions run by location. They capture expected vs counted quantities, move through approval states, and apply the variance back into the ledger. Purchase orders and goods inwards receiving use the same model, including partial receipts line by line.
There's no side channel for warehouse ops. Receiving, counting, and manual corrections all land on the same balances and movement history. Reports and audits read from one source.
Financial planning tied to the job
Inventory isn't the end of the model. Open order lines can generate frozen cost snapshots pulled from the active BOM, labour routing, rate schedules, admin load, utilities, and overhead. The snapshot is the estimate the job was quoted against.
Actual time entries roll back into actual labour cost, margin, and department utilisation. That ties customer demand, material consumption, and shop-floor capacity into one model, where before they lived in three disconnected spreadsheets.
The result
The rebuild has working surfaces for components, products and variants, BOM management, orders, inventory, suppliers, purchasing, goods inwards, stocktake, costing, staffing, actual time, capacity, reports, and activity logging. Wider than an inventory-drift fix.
v1 proved the demand for component-aware inventory. v2 is the operating system built around it. One place for materials, inbound supply, counted stock, planned margin, actual labour, and department load.
Tenant isolation runs in Postgres with RLS. Shopify ingest is idempotent. Every inventory mutation rides the movement-plus-balance invariant.