Case study · Automotive: A workshop CRM with an app the mechanic can use at the car

Jobs, invoices and payments raised on a phone at the car, replacing an old desk-only tool, with a migration that refuses to finish if the totals disagree.

On staging · cutover pending

Get a quote for one like this All case studies

We reply within one working day

Specification03 / 07

Client: A Cyprus motorsport workshop
Sector: Automotive
Status: On staging · cutover pending
Year: 2026
Services: Custom software and platforms CRM development
Stack: Next.js
TypeScript
PostgreSQL
Prisma
Zod
Kotlin
Jetpack Compose
Docker Compose
Caddy
GitHub Actions

Line drawing: brake parts and a two-post lift beside a phone app, the database behind it and a job checklist. — Illustration of the problem · not a client screenshot

A Cyprus motorsport workshop was running its customers, vehicles, jobs and invoices through a hand-rolled PHP application on a single database file. It worked, but only from a desk, and nobody could safely change it.

01The challenge

The data mattered more than the code: years' worth of clients, vehicles, invoices and payments had to arrive in the new system complete, with totals that still added up. A rewrite that loses a paid invoice is worse than the tool it replaces. The second requirement was the workshop floor, because quotes and invoices get written next to the car rather than at a computer. The third was that one person maintains all of this, so deployment had to be boring.

02What we built

One application rather than three: a Next.js monolith serving both the pages and a versioned JSON interface, PostgreSQL under a typed schema and migration tool, and a shared package of validation schemas so the web client, the server and the mobile client all agree on the shape of a vehicle, an invoice and a payment. Clients, vehicles, jobs, invoice generation and payments all live there.

For the floor, a native Android client in Kotlin and Compose, signed and installed directly rather than through a store, talking to the same interface. Invoice drafts survive being interrupted, which is what actually happens when you are holding a phone under a bonnet.

Authentication is argon2 hashing with short-lived access tokens and rotating refresh tokens; presenting one twice revokes the whole family, on the assumption that a replayed token is a stolen one. The browser keeps its tokens in cookies JavaScript cannot read, the app in encrypted storage, and the database is not exposed to the host.

The migration is a script rather than an afternoon of manual work. It reads the old file, writes the new database, then prints a reconciliation of row counts and money totals and exits with an error if source and target disagree.

03The outcome

The replacement is built and runs on staging, and the Android client points there deliberately: the production domain still serves the legacy PHP application, and the cutover has not happened. The migration is written and reconciles, but it has not yet been run for real.

What exists today is the whole flow working end to end on staging – a job raised at the car, an invoice produced from it, a payment recorded against it – and a release path where merging updates staging by itself while production waits for a person to approve it. That is what turns the cutover into a decision rather than an event.