The prototypes are now production code.

Products and Manufacturers — two of the most complex sections in the platform — are fully functional. Real PostgreSQL backend, real APIs, real data, inline editing on every page. Not mockups. Not demos. Working software.

April 1, 2026 · Phase 4: Trading OS Launch

Two sections. 12 tabs. 47 API endpoints. Zero shortcuts.

In the last update, we showed eight sections redesigned as interactive prototypes. This time, we're shipping production code. The backend runs on Fastify with Drizzle ORM, the frontend is Vite + React + TypeScript, and every piece of data comes from a PostgreSQL database with 60 tables.

We started with the two hardest sections — Products and Manufacturers — because everything else depends on them. An order references a product. A shipment references a manufacturer. Pricing flows from manufacturer cost through product margin to client sell price. If the foundation is wrong, every section built on top of it inherits the problem.

The result is two sections that feel complete. You can create a product, set its buy and sell prices across multiple manufacturers and clients, track inventory across warehouses, monitor compliance certificates against regulatory requirements for three markets — and do all of it without leaving the page you're on.

The foundation every section references.

Products is the most connected entity in the system. Order line items pull from it. Shipment weights come from it. Finance margins are computed from it. Compliance requirements are tracked against it. Six navigation tabs — each one a different lens on the same product data.

The supply side — from scorecards to ESG.

Manufacturers is the section nobody else builds properly. Most platforms treat suppliers as a field on a purchase order. We built a full relationship management system — 6 tabs with 21 sub-views covering performance, capacity, pricing, and compliance.

Ten manufacturers in the demo dataset across Malaysia, Thailand, India, Sri Lanka, and China. Each one with real capacity allocations, quality scores, delivery performance, pricing history, and compliance certificates. The data is realistic because it's modeled after actual glove industry operations.

Nine engineering documents govern every line of code.

Before we wrote a single endpoint, we locked the engineering standards: architecture rules, code standards, frontend component architecture, service contracts, state machines, system events, security rules, semantic HTML standards, and testing requirements. Every implementation is checked against these documents. No business logic in UI components. All database writes through service methods. State machines enforce valid transitions. Events are emitted by services, never by UI code.

The design system was extracted from the first completed screens and enforced across every page. A shared component library — buttons, badges, cards, tables, modals, form controls, KPI cards, filter bars — ensures that the 47th page we build looks and behaves exactly like the first. One stylesheet governs all of it.

The database schema has 60 tables covering the full trade lifecycle. The seed data isn't placeholder text — it's 10 real manufacturers with actual capacity figures, 20 products with variant matrices, 38 certificates with realistic expiry dates, 53 regulatory requirements with approved labs and cost ranges, pricing histories, production contracts, and live order data. When you open the app, it feels like a business that's been running for months.

The design principle that changed everything: edit where you see.

In most enterprise software, seeing data and changing data are different workflows. You find a problem in a report, then navigate to a different screen to fix it. We eliminated that. Click a certificate row in the audit history — an edit form expands inline. Click an ESG cell — you see the backing certificates and can add a new one right there. Click a price in the comparison matrix — edit it in place. Every page is both a view and an editor. The operator never has to leave their context to take action.

What's running right now.

Clients, then the rest of the chain.

The next section to go live is Clients — the demand side. Five tabs covering directory, deal pipeline, client pricing, financials, and relationship intelligence. At 742 paragraphs, it's the largest spec in the platform. After that: Production, Shipments, Orders, Finance, and the supporting sections.

The build order follows the data flow: Products defines what you trade. Manufacturers defines who makes it. Clients defines who buys it. Orders connects the three. Production tracks how it's made. Shipments tracks how it gets there. Finance tracks what it costs and earns. Each section we build connects to the ones already running — and the connections are already in the database schema, waiting to be wired up.