Higher Education & Research
The scanner read every barcode except theirs
They had no way to say who was holding what, and a barcode scanner that would not decode their own label format; the capability was licensed separately and they had declined to buy it. Writing the decoder in C cost less than the license and made the rest of the system possible.
- Client
- A university-affiliated research complex
- Duration
- About four weeks
- Team
- 1 engineer
- Year
- 2024
The situation
What we walked into.
Inventory was not tracked in any system. Items left and came back, and the question of who currently held a given thing could only be answered by asking around.
They had settled on their own barcode format rather than paying for a commercial one. That was a reasonable commercial decision and it had a consequence nobody had priced: the off-the-shelf scanner would not decode the format, because decoding it was exactly the capability the vendor licensed separately.
So the blocking constraint was commercial rather than technical. Every path forward involved either paying for the license, changing the label format, or reading the barcodes themselves.
Approach
How we sequenced it.
Each step had to be independently valuable. That constraint is what let the client stop at any point without being stranded.
- Step 01
Decide what tracked actually means
Not a catalog of things owned, which is what inventory usually gets built as. The question being asked was who has this right now, so the record is a check-out against a person and a check-in that closes it, and the item’s identifier is unique in the database, because two rows for one physical object makes the answer meaningless.
- Step 02
Decode the labels ourselves
Firmware written in C, on Linux, to read the scanner’s output and decode their format directly. It was cheaper than the license and it removed the constraint permanently rather than renting relief from it, and it meant the label format stayed theirs to change.
- Step 03
Build the system around the scan
A web application behind single sign-on, reachable from the internal network rather than published, with check-in and check-out driven by the scanner rather than by typing. The interaction is a scan because anything slower does not get used.
- Step 04
Hand it over properly
The repository was transferred to the client, with a written handover covering what to change first: move off SQLite before production, add the test suite, and the specific columns not to touch and why. It is now maintained by them.
What was built
The parts that mattered.
- The blocking problem was a license, not a technical limit, and the cheapest fix was to write the decoder.
- Custom label format stayed under the client’s control rather than a vendor’s.
- Check-out is against a person, so the system answers who has it, not merely what exists.
- Second engagement for this client, after the vehicle data acquisition work.
- Handed over with the repository transferred and the next steps written down.
Results
What changed, and how we know.
None of these is a number, because none of them should be: they are states of the delivered system rather than measurements of it. Each says what it is and what it rests on.
- Tracked in and out, against a holder
- Every item
- Purchased to read their own labels
- No license
- Repository handed to the client
- Transferred
Built with
Services involved
More work
Related engagements.
- 2023–202520 months, four phases
One codebase for the public site and the platform behind it
A public-facing site and an internal student-tracking platform, built years apart on stacks nobody still owned. We consolidated them into one application with one design system and one authorization model, and shipped it without a production regression.
Read the case study- Production regressions across the release window
- 0
- Unit and integration tests at handover
- 600+
- 2023–2025Built over two years, still operating
A cyber range that a person can actually run on a Tuesday
Building an isolated hundred-machine training environment is a project. Running one every week, for cohorts and for a multi-institution competition, is a system. We built the second thing.
Read the case study- Concurrent isolated machines per exercise
- 100+
- Competition run across several institutions
- Multi-site
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.
- Phone
- (214) 723-2510
- Reply
- A person replies, not a sequence: within one business day, from someone who would be on the engagement.