TL;DR: Araç Sağlık Karnesi (Vehicle Health Record) lets a repair shop log every service they do on a car, and lets the car's owner — or the next mechanic who touches it — pull up the full history with nothing but an 8-character code. No account, no password, no app install. Here's the access-control model behind that.
The problem with "just make an account"
Every vehicle history tool I looked at before building this one starts with a sign-up flow. That's fine for the shop, which is a repeat user. It's a terrible match for the customer, who interacts with the system maybe four times a year and will not remember a password for an app they open twice.
The actual requirement, once I wrote it down, wasn't "authenticate the user." It was "let the right person see the right car's history, and nothing else." Those aren't the same problem, and treating them as the same problem is why so many of these tools end up with a login screen nobody wanted.
What the code actually is
Every vehicle gets one row in a vehicles table and one generated code — 8 characters, uppercase alphanumeric, excluding visually ambiguous characters like 0/O and 1/I. The code is the effective primary key for read access: anyone who has it can look up that vehicle's service timeline, and the shop can hand it to the customer printed on a receipt or texted after service.
function generateVehicleCode(): string {
const alphabet = 'ABCDEFGHJKMNPQRSTUVWXYZ23456789'; // no 0/O/1/I
let code = '';
for (let i = 0; i < 8; i++) {
code += alphabet[Math.floor(Math.random() * alphabet.length)];
}
return code;
}
With a 32-character alphabet and 8 slots, that's roughly 1 trillion combinations — enough that brute-forcing a specific code isn't practical, especially with basic rate limiting on the lookup endpoint.
Where I drew the security line
I want to be upfront about the trade-off here, because it's a real one: this is a bearer-token model, not authentication. If you know the code, you can see the history. That's an acceptable trade for service records that are, honestly, low-sensitivity — mileage, what was replaced, when. It would be the wrong model for anything financial or medical.
Two decisions kept it from being naive:
Read vs. write are separate permissions entirely. The customer-facing code is read-only. Adding a new service record requires a shop-level login tied to that shop's account — the vehicle code never grants write access, so a customer sharing their code with a new mechanic can't accidentally (or maliciously) let that mechanic edit history from a different shop.
Codes are per-vehicle, not per-customer. If a car changes hands, the history — and the code — travels with it. That was actually a feature request from an early user: used-car buyers wanted a way to verify service history before purchase, and a code that outlives the original owner is exactly what that needs.
The honest limitation
There's no revocation story yet. If a code leaks, the only fix today is regenerating it, which breaks any receipt or link that already has the old one printed on it. For the current scale — a handful of shops, low-stakes data — I've decided that's acceptable. It's the first thing I'd build if a shop asked for it.
If you're building something similar and the users on one side of your product will never want an account, it's worth asking whether the "modern" answer (OAuth, magic links, passkeys) is actually solving their problem, or just the one your framework nudges you toward by default.
Araç Sağlık Karnesi is free for repair shops — link's in my profile if you want to see it.
Top comments (1)
Bearer codes are a clean trade for low-sensitivity service history. When a shop texts the code after a visit, normalise that phone to E.164 before sending, and keep staging on fiction ranges (555-0100 to 555-0199) so a test text can't leave the workshop.