TradeOS

TradeOS — Deep Dive

TradeOS is a fully integrated business management platform built from the ground up for retail and trade businesses dealing in high-value or bulky goods.

Why we built it

TradeOS started with a year spent working inside a furniture retailer, and was shaped by conversations with other trade businesses about what they actually needed. The same problem kept coming up: businesses growing fast but held back by disconnected software and manual processes. Spreadsheets for stock, WhatsApp for delivery coordination, a separate e-commerce platform, and a standalone accounting package — none of them talking to each other.

That is why the awkward parts are in here. Component-based stock, proof of delivery that stands up in a dispute, GB-to-NI customs paperwork, a driver app that works with no signal — those are not features anyone puts on a roadmap from a desk. They are the things that go wrong on a Tuesday.

TradeOS replaces the patchwork with one connected system.

Four screens, one database

Most of the value comes from the fact that these are not four products bolted together. They read and write the same records.

• The back office — orders, inventory, manifests, purchase orders, reports, staff, expenses. Runs on your own subdomain.
• Your shop — a customer-facing storefront on your domain, with your logo and colours.
• The till — a wall-mounted touch POS for the showroom floor.
• The driver app — a phone app for the van that works with no signal.

Sell a sofa on the till and the website has one fewer within the second. Mark a delivery done in the van and the order closes in the office. There is no nightly sync, no CSV export, and no reconciliation step where the numbers quietly drift apart.

What makes it different

Component-based inventory

Most retail systems track stock at the product level. TradeOS tracks it at the component level. A king-size bed frame, a specific fabric and a set of legs each have their own stock position. When you sell a product, the system knows which components are consumed and updates availability across every product that shares those parts.

Free-to-sell is derived — it is the quantity of the scarcest component, computed on read rather than typed in by anyone. That single rule is what makes it safe to put the same figure in front of a customer on the website. No more "we thought we had stock".

Delivery-first design

The delivery manifest is a first-class feature, not an afterthought. Staff build runs, assign drivers and track stop-by-stop completion from a purpose-built mobile app designed for a van, not a desk. It is offline-first: actions queue on the device and replay when signal returns, so a delivery in a rural blackspot is not a delivery you find out about at six o'clock.

Every drop captures a photograph and a signature, and both attach to the order. A disputed delivery gets settled with evidence rather than someone's memory of a Tuesday.

Sales order workflow built for trade

The order flow is designed around how trade businesses actually work: quote → confirmed → dispatched → delivered → complete. Walk-in customers can be captured instantly without pre-existing records. Trade accounts have full address books, credit limits and order history. Storefront orders flow in automatically, already paid.

Every transition writes an event with the person, the timestamp and what changed — and the same is true for anything touching money, stock or staff hours.

Selling more from the website

The storefront is not a brochure. It is wired into the same stock and pricing the counter uses, which unlocks a few things a bolt-on shop cannot do honestly.

• Bundles. Group products into a room set at a set price with the saving shown. The highest-leverage upsell surface on the shop, and it draws stock from the same component pool.
• Real scarcity. "Only 2 left" is the actual free-to-sell figure, not a countdown that resets on reload. Products go out of stock the moment their components do, so you never take money for something you cannot ship.
• Cash recovery. The system ranks stock that has stopped moving on 90-day sales velocity and proposes a markdown — 10%, 20% or 30% depending on how long it has sat. Applying it reprices the product, keeps the old price as the struck-through compare-at figure and puts a Sale badge on the card. Dead stock is back in front of customers the same afternoon.
• AI Room Match (Pro). A customer uploads a photo of their room; the model reads the space against your live catalogue and recommends pieces with a reason for each. It turns a browsing visit into a whole-room basket, and it can only recommend things you actually hold.
• Cart nudges (Pro). Abandoned-basket recovery emails, with subject-line variation.

Getting the stock in

Everything above depends on stock existing, so the inbound side is a first-class part of the system rather than a note in a spreadsheet.

Purchase orders run from draft to submitted to in transit to received, and receiving is partial by default — containers arrive short, and a system that only accepts all-or-nothing gets worked around within a fortnight. Booking components in recalculates free-to-sell, which puts the products those parts were blocking straight back on the website. Nobody edits the shop.

Container shipments and customs matter more here than most software admits. A Northern Irish retailer bringing goods from GB is doing customs paperwork on stock it already owns. TradeOS consolidates several purchase orders into one shipment, holds the TSS reference and UKIM eligibility, and keeps the movement log from booked to cleared to delivered — so "where is it, and what did it cost to land" has a single answer. Landed cost then carries through to the cost-at-time-of-sale figure on every order those components end up in.

Defects and vendor claims close the loop on damage. Bulky goods get broken, and the money is usually lost at the paperwork stage rather than the breakage stage — a driver photographs a split frame, it sits in a phone gallery, and the supplier is never billed. Reports are raised where the damage is found, with photos attached to the record. Escalating to a vendor claim drafts the letter from that evidence, which is the difference between a claim being made and a claim being meant to be made.

Your data, and getting at it

Every tenant can issue read-only API keys from Settings and read their own products, live stock, orders and customers over HTTPS. Point a spreadsheet at it, feed a shop you host somewhere else, or let an AI assistant answer questions about your own business.

Read-only is a deliberate choice rather than an unfinished one. An assistant reading your data is also reading text other people wrote into it — a customer's delivery note, an enquiry from your website — and text like that can contain instructions. A key that cannot write cannot be talked into cancelling an order by something a stranger typed into a form. Where a specific write is genuinely needed, we would rather scope a key to exactly that than hand over everything.

The documentation is public, at /docs/api and /docs/import, because the first thing that reads it is usually somebody's AI assistant — and docs behind a login get answered from guesswork instead.

It also settles a fair question about lock-in: your data leaves the same way it arrived, as CSV or over the API, without asking us and without a fee.

Staff, hours and margin

Scheduling, clock in and out, leave requests and payroll export cover the full team from showroom sales to warehouse to drivers. Role-based access means each person sees what they need and nothing more.

The commercial point is that clocked hours feed the labour cost your margin reports divide revenue against. Cost of goods is snapshotted onto each order line at the moment of sale, so a report run next year still reflects what that job actually cost — not what the component costs today.

Security and tenant isolation

Isolation between tenants is enforced in the database, not in application code. Every tenant-owned table carries a tenant ID and has row-level security switched on, with policies that read the tenant from the signed session token. An application bug cannot leak another business's data, because the application is not the thing holding the line.

The rest follows the same principle of putting the check where it cannot be skipped:

• Card data never touches our servers. Payments go through Stripe's hosted elements and Stripe Terminal.
• Prices are resolved server-side from the product record — on the website and on the till. A tampered client cannot discount itself a sofa.
• The till is locked down. It authenticates with a paired-device cookie plus a four-digit operator PIN, throttled with escalating backoff and a hard lockout on repeated failures. There is no address bar to navigate away from.
• Pay rates are separated into a manager-only table, so staff can see their own hours without seeing everyone's wages.
• Custom domains are verified by DNS TXT record before they go live, so nobody can point a domain at someone else's shop.
• Everything touching money, stock or hours is audited with the actor, the timestamp and the change.

Multi-tenant platform

Built for businesses with multiple showrooms, warehouses or brands from day one. Each location operates independently while management sees the full picture, and the whole platform runs as one codebase — so every tenant gets each improvement at the same time, rather than waiting on a bespoke build.

The storefront is configurable where it matters — logo, colours, typography, hero, collections, footer, email templates and domain — and deliberately not configurable where it would break things. There is no custom CSS or HTML injection, and the checkout flow is fixed. That is what keeps the shop fast, accessible and safe to upgrade underneath you.