← All solutionsMade-to-order production platform · Medical manufacturing

Operations platforms where every order is one of one

Made-to-order production has no catalogue and no reorder button. Every item is built for one person from measurements a computer takes off a scan, and the system has to hold that thread from the first appointment through manufacturing, delivery, and the remake eighteen months later.

The problem behind every made-to-order production platform

Mass production has a part number. Made-to-order has a person, a set of measurements taken on a particular day, and a promise that what arrives will fit them specifically. That difference breaks the software everyone reaches for first. An ordinary ERP assumes the thing being made already exists as a specification. Here the specification is created during a client appointment, by a member of staff who may be standing in a room with poor signal, and it stays attached to that one client for years — because when they come back, the question is not what did we sell them, it is what did we measure, what did we make from it, and what has changed since.

What is hard inside a made-to-order production platform

The record has to be a photograph, not a mirror

A questionnaire filled in during an appointment pre-fills from what is already known about the client, and on save it writes some of those answers back — the client record should reflect the latest measurements. But the questionnaire itself is stored as a snapshot bound to that one appointment, and it must never change afterwards. If a client is measured again a year later, last year's record has to still say what it said at the time, otherwise you cannot compare the two, defend a remake, or explain to anyone what you were working from. Getting snapshot and live data to coexist in the same form is a lot of the design work in this class of product.

Work does not stop because the network did

Appointments happen in rooms with thick walls. The platform is offline-first: clients, appointments, questionnaires, captured images and orders are all written to local tables and an operation queue, then replayed to the server when the connection returns, with a visible way to retry whatever failed. That last part matters more than it sounds — a sync that silently drops one operation is worse than no sync, because nobody finds out until the item is made wrong.

Access is not a role, it is a scope

Who may see and change what is decided across several dimensions at once — brand, branch, city, legal entity — with read and read-write as separate grants. On top of that, personal data has its own flag: a user without it sees a client's phone number masked rather than hidden, because they still need to recognise the record. Roles alone cannot express this, and retrofitting scopes onto a system built around roles is close to a rewrite.

Two people, one workstation, one shift

A workstation on the floor is used by whoever is on shift. So the platform lets a second user sign in alongside the first and switch between them without either losing their place. It is a small feature to describe and a wide one to build, because every screen, every draft in progress and every queued offline operation has to know which of the signed-in users it belongs to.

The order is not finished when it ships

Made-to-order means a proportion of items come back. Complaints, remakes and corrections are first-class objects, each traceable to the original appointment and the measurements it produced. The interesting question is not how to record a remake — it is what a remake inherits, what it deliberately does not, and who is allowed to decide that. Answering it late means reconciling history by hand.

Computer vision takes the measurements; the operator only checks them

The platform segments the subject from the background, finds each contour, places the control points itself, and derives the measurements from them — lengths, widths, an axis and a joint deviation angle — before a human has touched anything. The operator does not place points from scratch; they glance at what the system proposed and nudge a point if it is off. The reason this matters commercially is not the seconds it saves. It is that two operators in two cities now produce the same number for the same person, which is the difference between measurements you can compare across visits and measurements that only mean something to whoever took them.

A millimetre has to survive the trip from glass to machine

Capture happens on TWAIN flatbed scanners — Plustek A320L among them, with different branches running different models — and also on webcams and phone cameras. All three produce pixels; only one of them has any idea what a pixel is worth. Since the output is manufactured and printed at one to one, the scale is not a rendering detail, it is the product. So every image carries its own calibration: millimetres per pixel, the method it was established by, and a confidence value. The scanner path auto-crops against a black background without losing dimensions; the camera paths correct perspective and calibrate off markers on a mat.

The metadata lies, and you have to know that in advance

Reference output from the equipment reported 72 DPI in its own headers while the true effective resolution was around 114 — the real scale lived in the page layout, not in the file. If a system trusts the number written in the image, it produces items that are confidently the wrong size, and nobody notices until they are physically made. Carrying scale explicitly, as a value the platform computed and stored rather than one it read, is the difference between a measurement system and an expensive photo album.

You cannot click your way to a correct millimetre

A system whose output is manufactured has to be checked in numbers rather than in screens, so the tests sit where the numbers are made: 276 checks over the vision pipeline, the offline queue and the risk rules, 1,060 across the backend in three suites — unit, API journeys, and the ones that need a real database — and 717 on the web client: 2,053 in total across the three repositories, each of them running on every push. A clicked-through release cannot tell you that a contour moved by two pixels, and two pixels here is an item that does not fit.

Equipment, couriers and the finance system all speak differently

On one side there is measurement hardware; on the other a courier for shipping labels and tracking, a messaging gateway for sending documents to clients, and the accounting system for orders and reference data. Equipment is deliberately an adapter over a configurable device type rather than a hard dependency, because branches do not all buy the same scanner in the same year, and a platform welded to one model turns every hardware refresh into a software project.

How we went at it

We began from the flows rather than the screens: every user action written as screen, action, system response, result, and reviewed with the client before anything was designed. For a system this size that document is the real deliverable of the first phase — it is where the arguments happen while they are still cheap.

Two decisions shaped everything after it. The appointment record is immutable and the client record is live, which makes history defensible. And the platform assumes the network is absent rather than present, which turns synchronisation from an edge case into the main path.

Measurement was treated as a data problem rather than a drawing tool. The vision pipeline produces coordinates and derived values in millimetres, stored with the calibration they were computed against, so a measurement can be re-examined later rather than merely re-drawn.

The project is still running. We are describing it here as a class of problem rather than as a finished story, because that is what it honestly is.

8 months

and still building — the largest system we run

flow families, from intake to remake

2,053

automated checks across its three repositories

Automatic

measurement, with the operator only checking

ReactTypeScriptPostgreSQLOffline-first syncComputer visionTWAIN scanners (Plustek A320L and others)Scope-based accessCourier and accounting integrations

How it was built

The work behind this one, and what it costs

A case is easier to trust than a service page, and harder to buy from. These are the services this product was actually made of — each with a price and a scope on its own page.

from $16,000

Starting point

eight weeks to a first working version

First working version

That is one flow carrying real work — an intake, an order, the record it produces — not the whole platform. The system below is eight months in and still growing, which is the honest shape of this class of product: it earns its keep one flow at a time, and the order those flows arrive in is worth more argument than the total.

Questions people ask about made-to-order production platforms

The five that come up on nearly every first call about this kind of product.

An ERP assumes the thing being made already exists as a specification with a part number. In made-to-order the specification is created during an appointment, from measurements taken on a particular day, and it belongs to one person for years. That inverts the data model: instead of a catalogue with stock, you have a client, a history of measurements that must never change after the fact, and orders derived from them. Most teams discover this after configuring an ERP for a year.

Work carries on. Clients, appointments, questionnaires, captured images and orders are written to local tables and an operation queue, then replayed to the server when the connection returns, with a visible way to retry anything that failed. That last part matters more than it sounds: a sync that silently drops one operation is worse than no sync at all, because nobody finds out until the item has been made wrong.

A first working version starts at $16,000 and covers one flow end to end. A platform of the size in this case study is a phased build measured in months, priced per phase, with each phase useful on its own. We would rather quote you the first flow than a number for everything, because the number for everything is guesswork until the first one is running.

Eight weeks for a flow that carries real work, and by design that flow is one your team already does daily, so the platform earns trust before it earns scope. Everything after that arrives in phases you approve one at a time. Nobody should be asked to switch a production floor onto software all at once.

That is the assumption we build on. Capture in this platform runs over TWAIN flatbed scanners, webcams and phone cameras, behind an adapter over a configurable device type rather than a hard dependency on one model — because branches do not all buy the same scanner in the same year, and a platform welded to one turns every hardware refresh into a software project. Tell us what is on the floor and we will say plainly what it takes to speak to it.

Deeper on this

When roles are not enough: access across branches, brands and legal entities
Manager, admin, operator. Three roles will get you through the first year, and then someone opens a second location. What replaces roles, and why it is painful to add later.
Software that has to keep working when the internet does not
Offline-first is easy to promise and expensive to retrofit. What it actually requires, why a silent sync is worse than no sync, and how to tell whether your project genuinely needs it.
Why standard ERP software cannot handle made-to-order production
Off-the-shelf systems assume the thing you are making already exists as a specification. When every item is built for one person from measurements taken once, that assumption quietly breaks everything downstream.
What the first version should contain, and what it must not
Everyone agrees on starting small and nobody agrees on how small. The rule that has worked for us: one journey, all the way through, including its bad days.

Next caseMarketplaces where the money sits in the middleA marketplace with two sides, a payment held between them, and an AI studio that bills by the generation. The hard part is never the catalogue — it is deciding, in code, the exact moment money and files change hands.

Tell us what you are building

A person reads it and sends an estimate within 12 hours: a price range, what the first version contains, and what moves the price.