← Kansu.io Live demo ↗

Parts Portal.

A procurement & prototyping portal built for a hardware product studio — every part request from CAD upload to quoted, approved, ordered, delivered and QC’d hardware, on one timeline, with an audit trail engineered for regulated medical-device work.

REACT · FASTAPI · SQLITE · DOCKER 140+ REQS · 700+ PARTS · 22 VENDORS 21 CFR PART 11-ALIGNED AUDIT CHAIN
Open the live demo ↗
The problem01

Getting one bracket printed touches a CAD file, three vendor emails, a quote PDF, an approval, a payment, a courier and an inspection form. Multiply by every part of every build.

Parts Portal replaces that sprawl with one system of record. An engineer drops CAD files into a request and specs each part from structured method/material dropdowns driven by what vendors can actually make. From that moment the part’s whole life — quoting, sign-off, purchase, shipping, customs, goods-in inspection, payment — happens on a single timeline everyone can see.

Nothing is ever deleted. Cancelled work is catalogued, not erased — every procurement attempt stays part of the audit record, because the studio builds regulated medical devices.

The lifecycle02

One timeline per request, from first click to paid invoice.

REQUESTED → QUOTING → QUOTED → APPROVED → ORDERED → SHIPPED → DELIVERED → INSPECTED → PAID

Status only ever moves forward. Each stage records who acted, when, and how long the request sat there; exceptions get flagged rather than worked around, and a design change after a vendor commitment forks a tracked revision instead of silently editing history.

A completed request: completion summary with time-per-stage bar, vendor quotes, payment record
Request detail — completion summary with time-per-stage, the quotes that came in, and the payment record.
External orders queue grouped by requester with status chips
External orders — every vendor order, filterable by stage, office and requester; anything awaiting payment folds into its own collapsed category per requester.
What’s inside03
01Spec capture Method, material, colour, thickness, post-processing, hardness and infill are dropdowns fed by a live method–material map — a spec no vendor can make cannot be requested.
02Vendors & quotes A vendor register with per-vendor capability matrices; quote requests go out with share-links and spec sheets, quotes come back, get compared and awarded.
03Approvals & finance E-signed approvals with tokenised external approver pages, payment recording, spend tracking and import-duties capture — the money story lives on the part’s timeline.
04QC & compliance Goods-receiving and dimensional-inspection forms filled in the portal, with photo evidence built in — named shot slots per part (as-received, measurement setup, marking, fault close-ups), phone photos dropped straight onto the record — plus e-signatures with identity assurance and a hash-chained audit trail that can prove it hasn’t been edited.
053D preview Every uploaded model gets a rendered thumbnail and in-browser 3D preview; a file converter turns STEP/SLDPRT into printable meshes without leaving the portal.
06Part numbering A part master issues immutable client/product part numbers with revision letters — the filename an engineer must use is decided once, by the system, not by convention.
Parts list with 3D thumbnails, spec chips, quote comparison table
Parts & quotes — spec chips, a 3D thumbnail and format conversions per part; vendor quotes compared side by side.
Part inspection form with dimensional table and named photo-evidence slots per part
Inspection records with photo evidence — each part gets named shot slots (as-received, measurement setup, marking, fault close-up) plus free photo upload, feeding the signed QC record.
Vendor register with country and office filters and capability counts
Vendor register — fictional example vendors with per-vendor capability matrices.
Try it04

The demo is the real system.

Same codebase, same database engine, same workflows as the production portal. The demo dataset is entirely fictional — invented clients, vendors, people, requests and CAD — generated over the real methods-and-materials catalogue the portal actually uses. The database resets every night.

The login page arrives pre-filled — press Sign In, or switch account with one click.

Demo UserDemo User / PartsDemo1submit & track requests
Demo AdminDemo Admin / PartsAdmin1quoting · approvals · QC
parts.kansu.io/demo ↗
Demo login page with the demo account pre-filled
Sign-in — the demo account is pre-filled; press Sign In and click around.
How it’s built05

One React app, one FastAPI service. A ~13k-line frontend and ~9k-line backend, kept intentionally monolithic — the whole system fits in two files you can read.

SQLite as the primary store, behind a shim that emulates the Google Sheets API the tool started on — the migration to a real database happened without rewriting a single endpoint, and Sheets lives on as a one-way human-readable mirror.

Docker Compose on a VPS — three containers, nginx in front, nightly backups, and separate production, staging and demo instances of the same tree.

Compliance as a feature — login lockouts, session tokens, e-signature records and a hash-chained audit trail aligned with 21 CFR Part 11, built in rather than bolted on.