Parts Desk

The original problem was simple.

What parts do I have?

How many?

Where are they?

If I use something, can I record it quickly enough that I'll actually bother doing it while I'm working?

My van already has a physical organisation system, with parts stored in numbered bins.

So the first principle was obvious:

Parts could be organised around where I actually kept them.

Stock could be counted.

Quantities could change when parts were used.

And I could see what was available without digging through boxes.

Useful.

But then I encountered the next problem.

A part number tells me what is sitting in the van.

It doesn't necessarily tell me what it's for.

So I started connecting the stock to the equipment I work on.

That changed the project completely.

Instead of asking:

Do I have part 123456?

I wanted to be able to ask:

I'm working on this machine. What parts relate to it, and do I have any of them with me?

That required considerably more information.

Equipment models.

Different builds.

Serial-number prefixes.

Parts lists.

BOMs.

Technical drawings.

Callout numbers.

Compatibility between different generations of equipment.

Suddenly my little stock counter had developed opinions about engineering data.

I began importing and organising manufacturer parts information.

Thousands of individual relationships started appearing.

A single part might belong to several machines.

One machine might have several builds.

Two machines with similar names might not use the same component.

A part shown on an exploded drawing might only apply to certain versions of the equipment.

And sometimes the same component appears in several completely different places across the product range.

A conventional inventory system can tell me:

You have two of these.

I wanted mine to tell me:

You have two of these, they're in this bin, and here's where they're used.

That Used On information became one of the most useful parts of the project.

A random part number stops being random when I can immediately see the equipment it belongs to.

Parts lists are useful.

Exploded-view drawings are better.

When I'm trying to identify a component, I often think visually.

I know where the part sits on the machine.

I might recognise its shape.

I might know the callout number on a drawing without knowing the manufacturer part number.

So I started bringing technical drawings into the system too.

Now the challenge wasn't simply storing PDFs.

The system needed to understand the relationship between:

Machine → build → drawing → callout → part.

That's a much more interesting problem.

It also meant dealing with the reality of engineering documentation.

Duplicate files.

Different filenames for the same document.

Drawings covering several builds.

Parts that appear across multiple products.

Naming inconsistencies.

Missing information.

Legacy equipment.

Documents that are technically different files but contain exactly the same bytes.

One of the lessons from building the catalogue was that a model name isn't always enough.

Equipment evolves.

Components change.

Revisions happen.

A part that fits one generation may not fit another machine carrying essentially the same model name.

So serial-number prefixes and build information became part of the system.

The goal is to get closer to answering the question an engineer actually cares about:

Will this part fit the machine standing in front of me?

Not probably.

Not because the names look similar.

Because the available engineering information says it does.

While the catalogue grew, I kept developing the original inventory side.

If I use a tracked part, the quantity should reduce immediately.

If I move something out of my van, there should be a record of it.

If I uplift a part from site, I want to know where it came from and which job it related to.

If something needs quarantining, I want to record that.

If I'm commissioning the system against what's physically in my van, I want an auditable opening balance rather than numbers magically appearing in a database.

There are also things I deliberately don't want to count.

Screws.

Nuts.

Washers.

Bolts.

Other everyday fasteners.

Tracking every M6 washer individually would technically make the inventory more accurate.

It would also make me stop using the inventory.

That's an important distinction.

Building something exclusively for myself gives me an unusual advantage.

I don't have to design for an imaginary user.

I know the user.

He's usually kneeling next to a piece of gym equipment, has probably put his screwdriver down somewhere stupid, and doesn't want to complete six forms to record that he used a bolt.

So the system distinguishes between stock worth tracking and everyday consumables that don't need that level of administration.

If I decide a particular fastener matters, I can track it.

Otherwise it stays out of the way.

That's become one of the principles behind the entire project:

The phone in my pocket is also part of my toolkit.

So barcode and QR scanning became another obvious addition.

Rather than typing identifiers every time, I wanted to be able to point the camera at something and let the system do the boring bit.

That sounds like a small feature.

In the field, removing ten seconds of friction from something you might do repeatedly is exactly the sort of improvement that determines whether a tool becomes part of your workflow or gets abandoned.

The physical organisation and digital organisation now mirror each other.

Bins aren't abstract database locations.

They're actual places I can reach into.

Stock movements aren't accounting exercises.

They're things that happened during real engineering jobs.

Equipment relationships aren't theoretical product data.

They're there because I might be standing in front of that machine trying to work out what I need.

That connection between the physical and digital versions of my toolkit is probably my favourite part of the project.

The app knows about the things in the van because I use the things in the van.

At some point I realised I'd crossed a line.

I had started by building something to answer:

What's in my van?

But the system was increasingly capable of answering:

What is this part?

Where is it?

What machines use it?

Which builds does it apply to?

Do I have one?

Where is it shown on the drawing?

What else should I know about the machine I'm repairing?

That's not really inventory anymore.

It's closer to a personal engineering parts intelligence system.

And I never actually set out to build one.

There are plenty of commercial inventory platforms.

I'm not trying to compete with them.

They have to accommodate thousands of users, multiple industries, purchasing departments, warehouses, permissions, finance systems and countless workflows that have absolutely nothing to do with me fixing fitness equipment from a van.

My application has one user.

Me.

That means every feature gets judged against a very simple question:

Does this make my job easier?

If the answer is no, I don't need it.

That freedom has made this one of my favourite projects.

There was no specification.

No product roadmap.

No request from management.

It grew because every time I used it, I found another little problem worth solving.

And that's probably the best description of how I like to build things.

Find the annoyance.

Understand why it exists.

Fix it.

Use the fix.

Then notice the next thing.

I just wanted to know what was in my van.

I ended up teaching a web app what the parts were for.

Built from curiosity. Made with purpose.