Turning an ID card into something a customer can actually verify, instead of something they are asked to trust.
ORIGIN Independent prototype exploring how ID verification in field service could work differently. Not an employer product.
Web Development · Supabase · QR Technology · Security · UX
Most employee ID cards work on a fairly simple principle:
There's a photograph, a company logo and a name on a piece of plastic, so you trust that it's genuine.
For most situations, that's enough.
But working in field service made me think about the problem from the other side of the front door.
When an engineer arrives at a customer's home or business, how does that customer actually know the person standing in front of them still works for the company they claim to represent?
An ID card can look legitimate.
But it's static.
Once it's printed, the information on it doesn't know whether anything has changed.
That gave me an idea.
What if the ID card could verify itself?
01
Traditional employee identification is useful, but fundamentally passive.
A card can show name, photograph, company, employee information and an expiry date.
But the customer looking at it is still being asked to trust the physical card.
If someone leaves a company, the printed card doesn't suddenly stop existing.
If a card is lost, copied or photographed, the card itself has no way of communicating that.
And expecting a customer to phone an office every time an engineer arrives isn't particularly practical either.
I wanted something that retained the simplicity of showing an ID card while adding a second layer: live digital verification.
02
The concept is deliberately simple.
Add a QR code to the employee ID card.
The customer scans it using the camera already built into their phone.
No app.
No account.
No complicated instructions.
The QR code takes them to a verification page where they can confirm that the person standing in front of them corresponds with a legitimate employee record.
That changes the interaction from:
Here's my ID.
to:
Here's my ID. You can verify it yourself.
It's a tiny difference in the customer journey, but potentially a significant difference in trust.
03
I built the project as a working web application, using Bolt to accelerate the front-end development and Supabase for the backend and data layer.
The basic architecture is intentionally lightweight.
The QR code acts as the bridge between the physical and digital worlds.
Rather than trying to cram employee information into the QR code itself, the code can point towards the corresponding verification record.
That means the important information isn't permanently frozen inside the printed card.
The card points to the system.
And the system can change.
04
Imagine an engineer leaves the business.
With a purely physical ID card, somebody has to recover or destroy that card for it to stop being useful.
With a digitally backed system, the verification record can instead be changed.
The plastic hasn't magically disappeared.
But its ability to prove current employment has.
That distinction was one of the ideas that made me want to build the project in the first place.
05
The verification page also needed to pass my favourite test:
Could somebody understand it without me standing beside them explaining how it works?
A customer scanning an engineer's ID isn't interested in the database architecture.
They don't care which framework I used.
They shouldn't need instructions.
They want one answer:
Is this person who they say they are?
So the public-facing experience should be deliberately minimal.
Scan.
Open.
Verify.
Everything complicated belongs behind that interaction.
06
This became an important consideration while developing the idea.
It's tempting to think QR code = secure.
It doesn't.
A QR code is simply a convenient method of getting somebody from the physical card to the digital verification system.
It can be photographed. Copied. Shared. Printed.
So the security can't depend on somebody being unable to reproduce the QR code.
Instead, the important part is what happens after it is scanned.
Those questions transformed the project from a QR-code experiment into a much more interesting exercise in application security and information design.
07
An employment-verification system has an unusual challenge.
It has to expose enough information for a stranger to make a useful verification.
But that doesn't mean a stranger should be given unrestricted access to employee information.
That led to a principle I increasingly use when designing systems:
The public doesn't need access to the employee database.
They need a verification result.
Likewise, administrative functions for managing employee records should sit behind appropriate authentication and access controls rather than being available through the public verification route.
The public page and the management system might work together.
But they are not the same thing.
08
Another question I explored was what happens when information changes.
Do we generate another QR code?
Print another card?
Replace everything?
Ideally, no.
The better architecture is to make the QR represent a persistent verification identity rather than the current contents of an employee record.
The QR stays the same.
The information behind it can change.
So if permitted employee information changes, the database can be updated without necessarily changing the physical identifier.
That's a much more useful relationship between physical and digital systems.
09
Technically, this isn't the largest system I've worked on.
But that's exactly why I like it as a project.
The original idea can be explained in a sentence:
Put a QR code on an employee ID so a customer can verify the engineer.
Then you start building it.
And suddenly you're thinking about authentication, authorisation, privacy, database design, revocation, persistent identifiers, public versus private data, user experience, physical security and trust.
That's the bit of development I enjoy.
A simple real-world problem starts pulling on a thread.
Before long, there's an entire system attached to it.
10
I particularly like projects where software escapes the screen.
This isn't a website somebody discovers through Google.
The journey begins with a physical object.
A person arrives.
They present an ID card.
Another person takes out their phone.
They scan something printed on that card.
The physical interaction hands over to a digital system.
The system responds.
And that response helps establish trust in the original physical interaction.
There's something satisfyingly circular about it.
11
The project also reflects how I've started approaching software development more generally.
I don't necessarily begin by trying to design the perfect enterprise architecture.
I begin with the problem.
Build enough to prove the idea.
Use it.
Break it.
Ask uncomfortable questions about it.
Then improve the architecture as the requirements become clearer.
Tools such as Bolt and Supabase make that incredibly useful because they shorten the distance between:
I wonder if…
and
I've built something. Let's see if this actually works.
That ability to prototype quickly has become a huge part of how I explore ideas.
12
Ultimately, the Employment QR Verification project came from the same place as many of my other projects.
Something works perfectly well.
Then I start questioning it.
An employee ID card works.
But could it be better?
Could we connect it to live information?
Could we give customers more confidence?
Could we make verification easier?
Could we do it without making the experience more complicated?
So I built a prototype to find out.
The result is a small system connecting identity, physical hardware, databases, security and customer experience through something almost everyone already knows how to use:
Point the camera.
Scan the code.
Verify the person.
Because an ID card can tell you who somebody was when it was printed.
A connected ID can tell you whether they should still be standing at your door today.
Field Notes documenting the ideas, decisions and lessons behind this work.
Chuck Keith treats networking as something you can build, break and explore rather than memorise. He is one of the reasons I started chasing the CCNA, and a large part of why this site is a workshop rather than a CV.