High-value inventory, and the software business hiding inside it

No software was built. No new company was stood up. The work produced two decisions the board could act on: a scored implementation path with honest costs, and a market-tested read on whether the internal system was worth turning into a standalone product.

The client

A multi-site hospitality operator handling high-value specialty stock across locations. No strong tool exists built for exactly this kind of business, so every operator in the category improvises, and improvisation gets expensive as sites multiply.

The work, part one: specification and vendor selection

The specification was written to the domain's real complexity: the logic of storing and moving high-value stock across locations, ownership and provenance that must never blur, and operational reality at the floor level. Requirements came out of structured interviews and a prioritized backlog, ranked by value.

Implementation was a selection problem. I ran a systematic scan of more than fifty-five vendors across the stack, point-of-sale systems, specialist platforms, and custom-development shops among them, scoring each on fit, cost band, and reputation, including the ones worth avoiding for reliability or security reasons. It rolled up into a Good, Better, Best decision board: three options, each with a real cost range, a real timeline, and a clear statement of what the client would and would not get for the money.

The work, part two: is this a standalone business?

Then the board asked a second question. The bespoke system they would build to fix their own operation looked a lot like a product other operators in the same category would pay for. Was there a real software company hiding inside the internal build, and if so, what would it be worth going after?

Most companies skip the market test. So the second phase was a design and market-test study, presented to the board: the evidence for a decision the board would make with its eyes open.

Four parts. The market sizing, built from the ground up, every input a stated assumption a board member could push on. Real-world evidence: targeted outbound to a pool of ideal-fit operators and direct discovery conversations, replacing assumed demand with observed demand. The funding and structuring design: the relevant public grant routes in the client's jurisdiction mapped against its situation, what each covers and which one the business would need to be built around. And the ownership model: alternative structures from straight fee-for-delivery to an equity-linked operating-partner stake, each with the unit economics worked through.

The outcome

An implementation path with a scored vendor shortlist, honest costs, and three sequenced options. And an eyes-open read on the standalone software company: market sized with assumptions exposed, demand tested against real prospects, funding mapped to grant reality, ownership modelled. Both showed the downside as clearly as the upside.

What this shows

A system specified for a domain nobody has built well for, an implementation path chosen on evidence, and a loose "we should productize this" instinct turned into a board-ready decision with the market, the demand, the funding, and the economics worked out.

One of a set of engagement and systems case studies. If a problem like this is on your desk, start with a conversation.