One part can touch the whole operation.

The first request

A small defense contractor asked me to find a better way to track inventory. They sent me the spreadsheet they were using, and I began developing a replacement.

But inventory was not an isolated list. To understand what each field meant and what the new process needed to support, I had to learn more about the business: the parts it supplied, how government contracts worked, where opportunities came from, and what happened after an award.

The research opened another door

As I worked, I began using public records from DLA and other government sources to understand the parts more completely. A single National Stock Number could connect to years of awards, prices, suppliers, specifications, packaging requirements, government stock, published demand, and the equipment the part supported.

That created another opportunity. Instead of retyping years of handwritten history into a modern system, we could use official records to reconstruct much of it from the original government sources.

The government data did not eliminate the paper. It could tell us that a contract was awarded, something shipped, an invoice was submitted, or a payment was issued. It could not always tell us the company’s internal job number, what a handwritten code meant, why somebody handled an exception a certain way, or what happened between the official events. Scanned records and human review still complete the story.

The smaller requests changed the direction

For a time, I thought RFQ Hunter might become a software product used by many government contractors. I continued building it with separate workspaces for separate businesses.

Meanwhile, the original client kept bringing me other problems. Some were small. Some involved paper forms, spreadsheets, emails, government downloads, or information that existed in one part of the business but was needed somewhere else. I would often build the underlying capability into RFQ Hunter, then shape it around the client’s actual process.

Inventory became connected to jobs. Jobs led to outside processing and chain of custody. Shipping connected to invoicing. Government payment records connected back to the work that produced them. RFQ Hunter gradually became more than a tool for finding solicitations. It became an operating system for one business.

The business is still revealing itself

Much of the company’s working knowledge has traditionally lived in an experienced owner’s head, on paper, or inside spreadsheets. The owner still enjoys finding solicitations, preparing bids, and winning awards. Other recurring responsibilities are gradually being handed to another person as the owner steps back from more of the daily operation.

The small team also works from different locations. Paper records and operational details therefore arrive a little at a time rather than as one complete system that can simply be copied.

Putting the operation together is often more like assembling a puzzle than importing a clean dataset. It can be frustrating. It is also deeply rewarding when another piece finds its place and the wider picture becomes clearer.

Why direct contact with the work matters

Most consulting and development projects depend on a series of handoffs. The business explains its process to a consultant. The consultant turns what they were told into requirements. A developer builds what the requirements describe. Everyone can perform their part correctly and the finished system can still miss what the business actually needs.

What gets lost is rarely the normal path. It is the unusual invoice, the handwritten notation, the exception everyone handles from memory, or the spreadsheet that remains necessary because the main system never accounted for one awkward situation.

My preferred relationship reduces that distance. When I carry agreed recurring work while developing the system, I encounter those exceptions myself. I can see where the description and the operation separate, understand why the workaround exists, and improve the system around the real work rather than only the version captured in the requirements.

Why one tenant became the right outcome

RFQ Hunter is still built as a multi-tenant platform, but today it serves one private tenant. I am completely comfortable with that.

I once imagined success as supporting hundreds or thousands of users on one product. Through this work, I learned that I prefer building alongside one business, understanding its exceptions, and staying involved long enough to see whether each improvement actually helps.

That relationship gives me more than customer feedback. It gives me direct experience with the operation the system is supposed to support. The system is not finished because the operation keeps revealing itself. That is not a failure of the model. It is the model.