When building gets cheaper, product validation should change

Last night, before falling asleep, I found myself thinking about a product idea. Specifically, about how I should find out whether it deserves more of my time.

I know the familiar sequence: research the market, speak to potential users, form a hypothesis, build a landing page, buy some traffic, and see whether anyone signs up. Adjust the offer. Run another experiment. Eventually, decide whether to build the product.

There is a good reason for that sequence. Building software can be an expensive way to discover that nobody wants what you made.

But I kept coming back to one question: if I can build a small, useful version in a few days, is a landing-page test still the best next step?

My view is that cheaper development should change how we approach product validation. When the core experience is inexpensive to build and safe to test, the first working version deserves a place much earlier in the process.

The old sequence protected an expensive investment

A landing page, a waitlist, or a fake-door test gives you a way to learn before committing to development. A fake-door test, for example, measures whether someone tries to access an offer or feature that is not yet available.

These experiments answer useful questions. Does the message attract attention? Will people leave their contact details? Will they take the next step when they see a price?

If the alternative is funding months of development, learning through a smaller experiment makes sense.

The sequence can still involve substantial work, though. You need an offer, copy, a page, a way to reach people, and a way to interpret their behaviour. Without an existing audience, you may need to pay for traffic across several rounds of testing.

After all that, you have evidence about the offer. You still need to learn what happens when someone actually uses the product.

That gap is what I now look at more closely. If delivering the core experience costs only a little more than describing it, I want to compare both experiments before choosing one.

A conversation with a product manager made it concrete

Recently, I was working with a company on its AI strategy and internal initiatives. One of those initiatives involved building a tool for people inside the business.

During a discussion, the product manager wanted more time to think through the idea before involving the developers. He wanted to make sure he understood the requirements and had organised his thinking properly.

That instinct was understandable. In this case, though, we already knew the process we wanted to improve. We knew who the users were. Resources had been allocated.

I suggested describing the idea and the end-to-end flow to an AI coding tool, using mock data, and building a rough first version. My estimate for that narrowly scoped version was a couple of days.

Then we could put something concrete in front of the people who would use it. They could show us where the flow broke, what we had misunderstood, and which additional use cases mattered.

He agreed to take that approach.

The conversation stayed with me because it exposed a mismatch: we were treating the first build as a large commitment even though we could deliberately make it a small, reversible experiment.

That was a decision about how to learn. We still needed to run the experiment and find out whether the tool helped.

The first version can be the experiment

For a narrow workflow, I can now consider an experiment that includes working software much earlier. The scope matters: one type of user, one job, and one useful result.

That changes the evidence available to us.

With a landing page, we can observe whether people respond to a promise. With a usable first version, we can also observe whether they complete the task, use the result, come back when the problem occurs again, or agree to pay for continued access.

Those signals answer different questions. A signup can justify another experiment. Successful use can tell us something about the value of the experience. Payment adds evidence about willingness to pay. None of them, on its own, proves that we have a viable business.

Here is the distinction I find useful:

The right sequence depends on which uncertainty matters most and what it costs to investigate it.

A mock-data demo and a usable product answer different questions

For the internal tool, mock data was a sensible starting point. It let us make the proposed workflow visible without first connecting every system.

But a mock-data demo can only take us so far. It can reveal confusing steps and missing requirements. It cannot establish whether the tool reliably handles real work or saves time in practice.

A market-facing experiment needs the same honesty. If people are going to try the core value, that part must actually work. The interface can be basic. Some steps can be handled manually. The first release can support a very narrow use case. The promised result still needs to be real.

For example, imagine a tool that turns a customer brief into a proposal. A useful first experiment might accept one kind of brief and produce an editable proposal. Team permissions, a template marketplace, and a reporting dashboard can wait.

The question would be whether the intended customer can get a proposal they would actually use, with an acceptable amount of correction. That gives us something specific to build and something specific to observe.

Faster development does not give you an audience

The internal-tool example has an advantage: the users are already there.

A new product on the open market still needs a route to customers. Faster coding does not remove the work of finding the right people, earning their attention, or understanding why they should switch from what they do today.

Five friends trying a demo may help you find usability problems. They may tell you very little about whether strangers in your target market will buy it.

You may still need outreach, partnerships, an existing customer base, or paid traffic. You may still need a landing page to explain the offer. What changes is that the page can lead to a useful experience much earlier.

If you are already paying to reach prospective users, that creates an opportunity to learn beyond the initial click. You can follow the path from interest to first use, task completion, and a commercial decision.

It also creates a responsibility to interpret failure carefully. If nobody reaches the useful part, you may have an acquisition or onboarding problem. If they reach it and reject the result, you have a different problem to investigate.

I would compare the cost of learning before choosing the test

I would not turn “build first” into another fixed rule. Before starting, I would write down:

1. The uncertainty: what exactly do we need to find out?
2. The smallest useful experience: what must work for the test to answer that question?
3. The users: who can try it, and how will we reach them?
4. The limit: how much time and money will we spend before reviewing the evidence?
5. The decision: what behaviour would make us continue, change direction, or stop?

The comparison should include the whole experiment: building, checking the result, recruiting users, supporting them, and observing what happens.

If a small working version fits within that limit, I would seriously consider it. If the difficult part involves sensitive data, complex integrations, or a failure that could harm someone's business, I would isolate that risk before putting the tool into real use.

An internal tool is only a cheap experiment when its mistakes are contained. Being inside the company does not automatically make it low-risk.

The validation process should reflect what a first version costs

I do not need to believe that every software project is ten or a hundred times cheaper to change how I work. I need to understand the economics of the particular experiment in front of me.

When I know the domain, can define a narrow flow, and can build a useful first version quickly, I want to get that version into users' hands sooner. Their behaviour can help shape the next round of research and development.

That is also where I help founders and businesses through Worklayer Agency: turning an idea into a focused experiment, choosing what needs to work, setting up the tools and infrastructure, and getting to evidence that supports the next investment decision.

For a suitably scoped idea, the first version may be achievable in days. The time needed to establish demand, repeat use, or willingness to pay depends on the customers and the buying cycle.

If you are exploring a new product, an internal tool, or a new revenue stream, bring me the idea and the assumption you most need to test. We can work out the smallest useful experiment and whether building it is now the fastest way to learn.