The Most Valuable Software I Never Built

A prototype that worked, a product that still didn't get built, and the phase of the project I had been giving away.

Recently, someone came to me with a product idea. Customers would keep a watchlist of Dutch residential addresses, and the moment one of those properties appeared for sale on a major property platform, they would get a notification. Clear business case, identifiable buyers, and an obvious reason for them to care about speed.

Technically it was not straightforward, which is usually the part I enjoy.

Knowing how to build something is not the same as knowing what will go wrong. External systems behave differently than their documentation suggests, assumptions turn out to be wrong, and the piece that looked trivial on the diagram becomes the whole project. That gap is where most of the interesting work lives.

I started at the part that could kill it

Everything in this product rested on one thing: reliably getting listing data out of a platform I did not control. Accounts, watchlists, dashboards, notifications — all ordinary work, and none of it worth anything if the layer underneath can't be made to hold.

So I built that first.

I looked at several acquisition routes with different trade-offs and prototyped the one that survived scrutiny. In Python: an undocumented acquisition endpoint, incremental polling against publication timestamps, stable listing IDs, deduplication, address normalisation against BAG (the Dutch national address and building registry), persistence with retry handling, and monitoring.

Then I deployed it to a VPS and ran it against live listings.

It worked.

That mattered. Before, I had several plausible approaches. After, I had something more useful: proof that the product could be built.

I deliberately separated data acquisition from the rest of the application. The source I was testing was never meant to become the product's permanent foundation.

The idea was to have an acquisition layer with interchangeable adapters. If one source became unavailable or commercially unsuitable, another could replace it without rebuilding the watchlists, matching logic, notifications or the rest of the platform. Over time, multiple sources — including licensed or paid providers — could run alongside each other, and their results could be compared and normalised.

That separation mattered because, at this stage, we were validating technical feasibility, not choosing a permanent commercial data provider.

A technical yes is not a business yes

At that point, I fully expected the project to go ahead. I sent the client a detailed technical report covering what I had validated, how I would structure the application, what remained uncertain, and where I saw the risks.

They took a few days to review it. When the conversation resumed, we were no longer discussing whether the product could be built. We were discussing what it would cost.

Rather than proposing the full platform straight away, I suggested another controlled step: a smaller MVP, put in front of real users, to find out whether the product and the market justified further investment. It would cover the core workflow without committing to everything the platform might eventually become. If it proved useful and customers started asking for more, those features would be the next phase and the next budget.

But a successful prototype didn't remove the risks I had documented.

The source used for the prototype relied on an undocumented interface on a platform outside our control. The endpoint could move, the schema could change, and none of those decisions would ever involve us. That made it useful for proving technical feasibility, but not something I was prepared to present as a guaranteed long-term commercial dependency.

I made that distinction from the beginning. If the product proved commercially interesting, the acquisition strategy would need to stay flexible — adapting the existing source, adding others, or moving to a licensed or paid data provider.

My job was never only to prove I could build it. It was to give the client enough clarity to decide whether it should be built at all. That is why the uncertainties were in the report rather than behind it.

Then came the no-go

The client did further research of their own and decided not to proceed. Two reasons.

The first was long-term stability: a commercial product resting on an external acquisition mechanism needs ongoing work every time the source moves. The second, and the one that settled it, was the legal and contractual position of using that source commercially.

Together, those made the business model too fragile to build on.

My first reaction was the least technical part of the entire project.

Not again.

I was disappointed. We had solved the hard technical problem. The prototype ran against live data. The report had been reviewed. We had moved on to budgets, and to an MVP designed specifically to keep the first investment small. I genuinely thought we were starting the next phase. I had put a concentrated week into research, build, testing and documentation, and the answer was no.

The prototype did not fail

That distinction is the whole point. We didn't stop because the technology didn't work — the validation succeeded. It produced exactly what it was meant to produce: enough information to make a better decision than the one we would have made without it.

The alternative is worth picturing. Take the working prototype as sufficient proof, start building the full product, spend months on the application, and find the dependency problem after the money is gone. That is a failed project. This was not one.

Reducing uncertainty sometimes points toward a product and sometimes away from one. The second outcome is far cheaper, and it is still an outcome.

What I got wrong

There is a second lesson here, and it is mine rather than the client's.

I did that week unpaid. Not because anyone asked me to — I chose to. Like a lot of developers, I had filed everything that happens before development under preparation: you look into the idea, research the approaches, test an interface, maybe build a small proof of concept, sketch an architecture. Then, once everyone knows it works, the paid project starts.

That is not what happened. The research was work. The prototype was work. Identifying the risks was work. Designing the acquisition layer so the business would not be structurally tied to any one source was work. The recommendation created value, and it created that value precisely by producing no software contract.

Phase 1: Technical Validation

When an idea carries real technical unknowns, the first phase should not be let me see whether I can make it work, and then we'll talk. It should be a project with its own scope, its own deliverable and its own fee.

What it answers depends on the idea, but usually some of:

1. Can the difficult part actually be built?
2. Which assumptions need testing rather than guessing?
3. Which external platforms or data sources does this depend on, and which of them do we control?
4. What happens when one of them changes?
5. Can the architecture be designed so that no single dependency is structural?
6. Are there licensing or contractual questions that need specialist review?
7. What is the smallest prototype that settles the critical assumption?
8. What would production architecture look like if it holds?

The deliverable is not production software. It is a prototype, the findings, an architecture, the risks and a recommendation — and the recommendation can legitimately be go or no-go.

Going forward, I will treat technical validation as a separate paid phase rather than unpaid preparation for a possible build.

What I mean by "Technical Partner"

Clients used to come to me with specifications. Increasingly they come with problems: a system that needs to scale, two platforms that need to talk to each other, an idea that doesn't exist yet. And often the first question isn't how do we build this, it's should we, and what would it actually take.

Development is still a major part of what I do, but writing the code is only one part of getting a technology decision right. Sometimes the useful contribution is challenging an assumption, or building the smallest thing that proves the risky part, or designing around a dependency you know you don't control. Sometimes it is proposing a smaller next step than the one the client was ready to pay for.

And sometimes it is laying out plainly why the thing shouldn't be built.

We are biased toward building. A client describes an idea, we see the shape of the solution, and we are already thinking about databases and interfaces. Building is the good part. But businesses don't need software because software can be built — they need software that survives contact with the constraints around it.

The product never got built. The next time someone asks me to find out whether an uncertain product can be built, though, the research won't happen before the project. It will be Phase 1 of the project.