The brief
An off-road suspension fabrication and install shop sells parts online, builds kits on its own floor and runs a service bay. They wanted one system for all of it, so that a part sold online, pulled for a job or built into a kit comes out of the same stock, and the books follow from what actually happened.
Starting from something that already worked
I didn’t start from a blank page. The base was the e-commerce platform I built for my own store, which already handled checkout, live shipping rates and oversell protection. In seven days and about 650 commits it grew into one Next.js and Postgres codebase that replaces the shop’s hosted storefront and runs the back office and the service bay.
What the shop got
- Storefront: a truck fitment finder, add-ons, online checkout and live shipping rates.
- Catalog and operations: kits built from bills of materials, part numbers with aliases, products listed on the website, in the shop or both, drop-ship items, a stock ledger, purchasing that answers “what do we need?”, receiving, counts, and fabrication orders with QR-coded travelers.
- Service jobs: vehicle check-in on a walk-around diagram with pins, photos and the customer’s signature; estimates the customer approves by link; standard job packages, a schedule, hand-over, and invoices with pay links.
- Time and team: a day clock and job timers, a shared-iPad kiosk with PIN sign-in, time-off and time-change requests, a payroll export, role permissions, and staff chat on every job.
- Customer portal: their vehicles, service history, estimate approval and invoice payment.
- Accounting: a costed perpetual inventory ledger and an immutable double-entry journal. Posting to QuickBooks Online is designed (one sales receipt per sale, daily summary journal entries and a tie-out report) and runs in shadow mode; the live sync isn’t finished yet.
- Scanning and labels: barcode and VIN scanning in the browser with the camera or a USB scanner, Bluetooth scanners in the app, shelf labels on a desktop label printer and 4×6 shipping labels.
- An API with an OpenAPI spec generated from the same schemas the server validates against, API keys and idempotency keys.
- An iPhone and iPad app with the same ten sections as the web, set up for private distribution through Apple Business Manager. A registry of 163 staff features tracks web and app parity, and a test fails if either side is missing one.
How it was built
- The owner’s preferences are policies, not code. Each shop rule is a setting enforced on the server, with neutral defaults and the shop’s own values in a seed. A test on an empty database fails if any of them is hard-coded, so changing how the shop works is a setting, not a release.
- Money and stock can’t race. Every ledger write takes row and advisory locks, payment webhooks are idempotent, and a seeded fuzzer runs random sequences of orders, refunds, service jobs and stock counts, then checks that stock and money still reconcile.
- Authorization is proven, not assumed. A test walks every server action and API route and shows that each one refuses a caller without the capability before any database query runs.
- Real data, repeatable imports. Imports from the old store and the accounting system are idempotent: a second run on a fresh database came out byte-identical across 124 tables.
- Independent review. Dedicated review agents covered security, authorization, money and stock, settings, and the user experience, the last from about 1,100 screenshots across six roles and four screen widths. Every finding was fixed with a failing test first.
By the numbers: 130 database models, about 430 API handlers and about 277,000 lines of code, covered by about 1,800 unit and integration tests, 132 browser end-to-end tests on desktop and phone screens, 33 security tests against a production build, and 260 app tests.
Status
The platform is on a staging server with the shop’s real data while the crew tests it. Production cutover is next.
Now a product
Other shops have the same problem, so the platform is now offered to them as ShopJig. It was built to be white-labelled: each shop’s name, logo, colours and rules are configuration, with the first shop’s values in its own seed.
The client’s own screens carry its branding, so none are shown here. shopjig.com shows the platform running a fictional demo shop.