JetCustoms: the whole shop on one system, in three months.
The challenge
A custom car shop with ten collaborators ran on Excel, hand-made PDFs and paper timesheets, reprinted every time a plan changed. The same job lived in several of them with nothing joining it up, so figures could not be correlated or validated easily.
What we did
One senior engineer, three months, first conversation to production. ERP, finance, HR, CRM and a CMS as one product on one database, over a single data model: each hour, part and vehicle recorded once and joined rather than copied, so the numbers reconcile by construction and business analytics has a foundation to build on. Delivered with a handbook and an engineering guide, so the shop is not dependent on us.
What it covers
| Module | What it does | Replaced |
|---|---|---|
| ERP | Projects, vehicles, hours, materials, approvals | Excel, WhatsApp |
| Finance | Settlement notes, rates per section, PDF statements | Hand-made PDFs |
| HR | Timesheets, schedules, holidays and time off | Paper, reprinted |
| CRM | Clients, key account owners, automatic follow-ups | Memory |
| CMS | Public content in two languages; drafts, preview, one-click publish | An agency |
How it is built
| Area | Implementation |
|---|---|
| Authorisation | Row-level security on every table. Five domain-relevant roles, more than one per user |
| Authentication | Password or magic link, swappable provider. A new account reads nothing until approved |
| Data integrity | Totals are generated columns and triggers, not application arithmetic. Settlement lines immutable once issued, with a parity test on every total |
| File transfer | Single-use signed URLs direct to object storage. No file bytes through the app server |
| Schema changes | Dev first, always. Ordered, recorded migrations, never edited by hand. Types are generated from the schema in the same commit, and CI fails if the two disagree |
| Tests | Unit tests, an RLS matrix and the parity test, in CI against a real database. Lint at zero warnings. Destructive scripts are tested to refuse in production |
| Environments | Two: production, and a disposable development clone of its schema and data. Copies flow one way only. The clone stays out of search results |
| Build and deploy | One workflow per branch: checks, migration, type regeneration, SQL tests, build, deploy. The pipeline triggers the deploy, not the commit, so no release lands before its migration |
The result
- 3 months
- from first call to production
- [−80%]
- admin time per invoice
- [2×]
- faster from job done to cash in
The technical write-up
The same build, written for the engineer who has to maintain it: why five business domains went into one schema, what that buys, and what it costs.
Read it on Corvale EngineeringStart with a straight answer.
A fixed-price technical assessment, with no commitment afterwards. Or simply book a call.