IP / 01 · Vertical ERP · concrete-product manufacturing
One operating system for the complete factory workflow.
erprime is a purpose-built operating system for concrete-product factories. It connects a customer order to the recipe, raw material, machine, mould, production lot, laboratory decision, vehicle, weighbridge event, delivery, invoice, payment, and audit trail that fulfil it.
- Role
- Product owner · technical architect · full-stack engineer
- Period
- Independent product · active development
Product overview
The problem, users, and product decisions.
I designed erprime around the physical truth of a factory, not around generic ERP departments. The product’s job is to keep the commercial promise and the material event legible as one chain—while giving every team the view, language, and permissions required for its part of that chain.A paver, block, tile, or kerbstone order immediately creates consequences across sales, material planning, production, quality, stock, transport, and cash flow. When those teams work in separate registers, a quantity can be sold before it is made, made before its inputs are reconciled, dispatched before it is qualified, or invoiced against a physical event no one can reconstruct.
The product therefore treats the order as a living operational object. It does not disappear after entry: it gathers requested items, priority, production demand, lots and bundles, test state, gate and weighing records, delivery, inventory movement, financial transactions, and the history needed to explain what changed.
Who uses it and what they need.
Each team gets the information and actions needed for its part of the same workflow.
Sales and planning
Promise quantities and dates against products, priority, stock, production demand, and customer terms.
Stores and inventory
Control raw materials and finished goods across variants, lots, bundles, loose quantities, receipts, issues, and corrections.
Production
Turn recipes, machines, moulds, shifts, and material availability into traceable production runs.
Laboratory
Test raw materials and finished goods, release usable stock, and reject unsafe purchase or production outcomes.
Gate, weighbridge, and fleet
Verify the vehicle and order through physical arrival, weighing, dispatch, departure, and delivery.
Finance and management
Read invoices, payments, transactions, operational exceptions, and the factory’s current position from the same record.
What the product does—and does not do.
- 01
erprime is a vertical factory operating system; it is not a generic chart-of-accounts package with manufacturing labels added later.
- 02
The source of truth is the durable factory record. Dashboards, reports, and the voice agent interpret that record but do not replace it.
- 03
Physical existence and operational permission are different states. Stock can exist while still being unavailable because laboratory release or dispatch validation is incomplete.
- 04
Factory configuration is part of the product model. Variant axes, production modes, shot blasting, requested-item rules, and other capabilities are enabled only where the factory actually uses them.
- 05
AI memory may retain user or factory preferences; live stock, orders, dispatch, and production facts must come from current erprime tools and data.
Key product decisions.
Follow material, not menus.
Navigation is secondary to the domain chain. Recipes create material demand; production consumes it; lots and bundles preserve provenance; quality changes permission; dispatch closes the physical loop.
Make partial completion impossible where stock is at risk.
Multi-record inventory creation and destructive corrections are transaction boundaries. If the complete state cannot be written and verified, none of it becomes the new truth.
Derive physical stage from physical evidence.
Dispatch progress is derived from gate-pass, weighing, delivery, and validation records rather than from a convenient status label that can drift from reality.
Let configuration shape the interface.
The product does not ask every factory to pretend it has the same processes. Enabled capabilities change forms, agent context, and valid actions without fragmenting the underlying model.
How it works
From order promise to validated gate-out.
The dominant workflow follows the object the factory cares about: a sale becoming qualified, counted, physically moved product. Each stage leaves evidence for the next and preserves a path back to the material event.- 1.0
Sales · planning
Commit demand
order / requested itemsProducts, variants, quantities, customer terms, dates, vehicle expectations, and priority establish the promise.
ProducesA scoped demand record that production, stores, and dispatch can act on. - 2.0
Stores · production
Prepare material
recipe / stock / reservationRecipes and factory settings translate finished-product demand into material requirements and eligible inventory.
ProducesMaterial availability tied to the planned production outcome. - 3.0
Production
Make and trace
run / lot / bundleMachines, moulds, layers or batches, operators, consumption, output, wastage, lots, bundles, and loose quantities form the production record.
ProducesFinished goods with quantity and provenance—not an unexplained stock increment. - 4.0
Laboratory
Qualify
test / release / rejectionFinished goods and raw materials move through configured tests, sieve and moisture logic, pass/fail decisions, and rejection consequences.
ProducesAn explicit permission state for use, production, or dispatch. - 5.0
Gate · weighbridge · fleet
Move physically
gate / weigh / dispatch / deliveryThe order progresses through at gate, weighing in, dispatch, weighing out, gate-out validation, and delivery using the actual movement records.
ProducesA vehicle-linked, weight-bearing chain of custody. - 6.0
Finance · management
Close and read
invoice / payment / reportDelivery edits reconcile inventory, transactions retain the financial effect, and reports expose the completed chain and its exceptions.
ProducesA commercial record that can be traced back to qualified production.
Product modules
Six connected parts of the product.
Each module serves a different task, but all of them use the same underlying business record.Commercial control plane
Orders and factory demand
Sales · planning · managementKeep the customer promise connected to priority, requested items, vehicle arrival, production need, and fulfilment state.
What it does
An order is not a row in a sales list. It is the shared object through which the factory coordinates the consequences of a promise.
How it works
- 01
Factory-scoped products and variants define the requested item without assuming every plant sells the same configuration.
- 02
Priority and pinning are explicit, permission-controlled behaviours rather than informal sorting conventions.
- 03
Bounded label retrieval and indexed lookups keep operational order views proportional to the records being shown.
Safety checks
- One factory context per operation.
- Permission gates on consequential order actions.
- Physical state is derived from movement records rather than overwritten by the list view.
Quantity authority
Inventory and material provenance
Stores · production · laboratoryRepresent raw materials and finished goods across items, variants, lots, bundles, loose stock, receipts, issues, and audited corrections.
What it does
The useful number is not merely “stock.” It is stock with type, variant, provenance, packaging state, quality state, and a reason for every movement.
How it works
- 01
Atomic creation writes the inventory item, variants, lots, bundles, and loose state as one database transaction.
- 02
Parent quantities aggregate variant state so the product-level view cannot hide child stock.
- 03
Audited management paths and mismatch checks make reconciliation a designed workflow rather than a silent repair.
Safety checks
- Rollback on incomplete inventory creation.
- Signed transaction-net assertions before destructive repair.
- Mismatch detection after consequential stock changes.
Manufacturing record
Production, machines, and lots
Production · supervisors · managementConnect recipes, machine and mould capability, configured production mode, material consumption, output, wastage, and resulting lots.
What it does
The production screen is the point where a plan becomes material history. It must explain what was made, from what, on which equipment, by whom, and where the variance went.
How it works
- 01
Factory capability settings drive variant axes, layer or batch logic, shot blasting, and other production-specific behaviour.
- 02
Production merges preserve provenance; guarded repair operations create an audit record rather than mutating history invisibly.
- 03
Raw-material use is checked against the signed transaction net before the merged state is accepted.
Safety checks
- Mutation guards on provenance-bearing records.
- Transactional rollback when quantity assertions fail.
- Machine, shift, and operator context retained with production.
Operational permission layer
Quality laboratory
Laboratory · stores · procurement · productionTurn raw-material and finished-goods tests into decisions that change what the factory is allowed to consume, release, or dispatch.
What it does
Quality is not an attachment after production. It is a state transition with downstream consequences for inventory, purchasing, logistics, and customer commitments.
How it works
- 01
Finished-goods tests remain attached to the lots whose operational status they govern.
- 02
Raw-material workflows support basic pass/fail, sieve zones, moisture calculation, and configured acceptance logic.
- 03
Purchase-order rejection leaves a downstream logistics state instead of ending at a laboratory note.
Safety checks
- Test outcome and tested object stay linked.
- Release/rejection is explicit and permission-aware.
- Rejected material remains visible to the teams responsible for its next movement.
Physical chain of custody
Gate, weighbridge, delivery, and fleet
Security · weighbridge · dispatch · driversModel the vehicle and order through entry, weighing, loading, departure validation, delivery, service, and exception history.
What it does
The gate is not a clerical endpoint. It is the boundary where digital permission must agree with a vehicle, a weight, a load, and a responsible movement.
How it works
- 01
The dispatch pipeline is derived from gate-pass, weighing, and delivery records, each constrained to one authoritative record per order where required.
- 02
Fleet identity and movement connect vehicles to gate and delivery events while retaining documents, readings, service, and breakdown history.
- 03
Editing a completed delivery rolls back and reapplies inventory effects while preserving physical timestamps and protecting validated reports.
Safety checks
- No validated gate-out without the required physical records.
- Delivery correction reconciles stock and transaction consequences.
- Validated reporting states are locked from casual mutation.
Assisted interface
AI Lab and voice operations
Managers · operators · authorised staffLet people query and act on the factory through speech while keeping live facts, permissions, cost, and tool behaviour observable.
What it does
Voice is useful at the operational edge because hands and attention are occupied. It earns trust only when it knows its factory boundary and shows restraint when a capability is unavailable.
How it works
- 01
A live voice model uses short-lived browser credentials and a separate agent service with factory-scoped tools.
- 02
Factory capabilities are injected into the session so the assistant does not ask about disabled modules or unavailable operations.
- 03
Session, message, tool-call, provider, billable-cost, and pricing-snapshot records make the AI surface operable as a product.
Safety checks
- Long-term memory stores preferences, never current operational truth.
- Live answers come from scoped erprime tools.
- Tool failures carry explicit taxonomy and correlation for investigation.
Technical architecture
How the system is built and keeps data reliable.
I separated the interaction layer from the database authority without pretending that a manufacturing system can be reduced to CRUD. The architecture puts factory scope, atomic inventory effects, provenance, quality permissions, physical movement, and observable AI tool use at the durable boundary.- L1 / Work surfacesNext.js App Router · React · TypeScript↓
Factory-specific views for orders, gate, weighing, deliveries, laboratory, inventory, production, lots, reports, transactions, clients, machines, staff, roles, and AI-assisted work.
- L2 / Client controlTanStack Query · Zustand · validated forms↓
Server-state caching, bounded client state, typed form validation, permission-aware actions, and responsive operational readback.
- L3 / Domain boundarySupabase RPC and scoped data services↓
Transactional operations own multi-record writes, derived stage reads, audited corrections, aggregation, and consistency checks.
- L4 / Durable truthPostgres · Auth · production records↓
Factory identity, orders, inventory, variants, lots, bundles, tests, gate passes, weighing, delivery, transactions, fleet, staff, and AI observability persist as connected records.
- L5 / Assisted edgeLive voice model · erprime agent service↓
Short-lived access, factory-scoped tools, capability-aware prompts, analytical functions, and optional preference memory sit above—never inside—the source of truth.
- L6 / VerificationVitest · Playwright · type checks · database assertions
Rollback paths, mismatch detection, critical journeys, and domain invariants are tested at the layer that owns them.
Technical rules.
Rules every part of the system must follow.
Factory scope is resolved before work.
The current factory, role, and enabled capability set determine what can be read or changed before a domain action executes.
Inventory effects commit together.
A stock-bearing operation owns every related write or owns none of them. Recovery is not left to a user repeating steps in the interface.
Provenance survives reconciliation.
Production and inventory repair may correct state, but it may not erase why quantities moved or who initiated the correction.
Physical state is evidence-derived.
Gate and dispatch labels are projections of authoritative records, not a second manually edited truth.
AI is a client of the domain.
The assistant uses the same scoped facts and permissions as other interfaces. Preference memory cannot override live factory state.
Technology and responsibilities.
The main technologies and what each layer is responsible for.
Next.js App Router · React 19 · TypeScript
One typed surface for dense desktop workflows and operational mobile use.
Supabase Auth · Postgres · server-side session support
Factory identity and durable production state share an explicit data boundary.
Postgres RPCs · transactional functions · audited correction paths
Multi-record manufacturing changes either commit coherently or roll back.
TanStack Query · Zustand · React Hook Form · Zod
Remote truth, local interaction state, and validated commands remain separate.
Gemini Live · short-lived credentials · separate agent service · optional Mem0 preferences
Speech and memory can assist without becoming an authority for current factory facts.
Voice sessions · messages · tool calls · provider and billing records
AI behaviour and cost must be inspectable like any other production subsystem.
Vitest · Playwright · TypeScript checks · invariant queries
Transaction rollback, critical journeys, and stock mismatches need executable evidence.
How the system handles failure.
What happens when data is missing, incorrect, or only partly saved.
An inventory item is only partly created.
A single transactional operation writes item, variants, lots, bundles, and loose state; any failed step rolls the complete operation back.
Variant stock exists but the parent appears empty.
Product-level quantities aggregate child variants, and mismatch checks test the materialised view against the underlying stock state.
A production merge rewrites material history.
Mutation guards block casual edits. The repair path records an audit event and validates raw-material quantity against the signed transaction net before commit.
A completed delivery is edited after stock moved.
The system reverses the earlier inventory effect and reapplies completion within a controlled flow while retaining weighing and delivery evidence.
A dispatch label disagrees with the physical journey.
The displayed stage is derived from gate, weighing, delivery, and validation records; it is not trusted as an independent mutable field.
The voice agent answers from memory or invents a disabled process.
Current facts come from factory-scoped tools, capabilities shape session context, and tool errors remain explicit and traceable.
Sources
What this case study is based on.
- 01
The production application and its current Supabase-backed codebase: routes, domain services, transactional functions, factory settings, tests, and operational modules.
- 02
The order, gate-pass, weighing, delivery, inventory, lot, bundle, laboratory, fleet, staff, machine, transaction, and reporting models implemented in the product.
- 03
Rollback tests and consistency work around atomic inventory creation, stock aggregation, production-merge provenance, completed-delivery edits, and dispatch-stage derivation.
- 04
The live voice architecture: short-lived sessions, factory capability context, scoped tools, session and tool observability, billing records, and preference-only memory.