The €1.4K Test That Stopped a €26K–€43K Mistake
Before you hand a new feature to engineering, you need more than a sense that customers want it. You need evidence that the right customers care enough to move toward buying it.
You can test that before committing a five-figure engineering budget.
For one of our clients, the answer took 10 days and €1,428 ($1,649).
The company is a B2B SaaS business based in Berlin, doing roughly €2.6M ($3M) in ARR and selling to customers across several countries. We're not naming them, at their request, but the numbers below are real.
What the team was about to build
A handful of customers had mentioned some version of a possible premium feature on sales calls.
Over time, those comments gradually turned into something more definite inside the company:
Customers are asking for this.
Engineering estimated the feature at five to six weeks of work. Fully loaded across the people involved, the sprint was expected to cost roughly €26,000–€43,300 ($30,000–$50,000).
But nobody had actually tested whether enough customers cared about the problem to justify building a paid solution around it.
What the team asked for
The request was direct:
"Check whether customers care enough about this feature before we hand it to engineering."
Before the test started, the team also agreed on a decision rule.
- Fewer than 20 qualified pilot requests: stop.
- 20–49: keep researching.
- 50 or more: enough signal to consider moving into development.
The important part was setting those thresholds before seeing the results.
That meant a disappointing outcome could not be explained away afterward because the team already wanted to build the feature.
What OpenWay AI did in 10 days
OpenWay AI started with information the company already had.
It pulled context from the CRM, previous sales calls, and earlier customer requests to understand how customers themselves described the underlying problem, rather than relying only on the product team's internal language.
From there, OpenWay AI:
- developed the offer;
- built a dedicated landing page;
- prepared two positioning angles;
- launched a small advertising test;
- emailed the segment of the existing customer base most likely to care;
- collected responses and the reasons behind them.
The paid media budget was €563 ($650).
The test ran for 10 days.
What the test actually found
The campaign produced 17 qualified pilot requests.
Under the decision rule the team had agreed on beforehand, that was below even the minimum threshold of 20.
The feature did not move into development.
But the count was not the most useful part of the test.
When the team looked at what customers had actually said, another pattern emerged.
Several customers were interested in the broader problem, but they did not want the feature in the form the company was preparing to build.
They wanted a simpler solution to an adjacent problem.
That distinction mattered.
The original assumption had been:
Customers keep mentioning this problem, so we should build this feature.
The test showed something different:
The problem was real. The proposed solution was probably wrong.
The company stopped the sprint before it started and reworked the concept around what customers had actually asked for.
The economics
OpenWay AI cost €865 ($999) for the month.
Paid media added €563 ($650).
Total test cost:
€1,428 ($1,649).
The engineering work the team decided not to start had been estimated at:
€26,000–€43,300 ($30,000–$50,000).
So the test cost roughly 3.3%–5.5% of the amount the company was preparing to commit to an unvalidated product hypothesis.
That does not mean every €1,428 experiment can reliably answer a €43,000 product question.
The point is that this one created enough evidence, against a decision rule set in advance, to tell the team not to start the sprint yet.
Sometimes the most profitable result of a growth experiment is deciding not to build something.
What happened after
The story did not end with one stopped feature.
The company stayed with OpenWay AI after the test.
Since then, the team has been among the first to try many of the new features we've released, and they continue using OpenWay AI to test new product and marketing hypotheses as they come up.
The first experiment did not prove that every idea should be tested with exactly the same process.
It gave the team something more useful: a repeatable habit of testing the market before committing the expensive part.
FAQ
How do you know if 50 requests is the right threshold?
You don't borrow someone else's number.
This team chose its threshold based on its own economics, sales cycle, target customer, and what a successful pilot could be worth before the experiment began.
For another company, 10 qualified requests might be meaningful. For another, even 100 might not be enough.
The important part is defining the decision rule before seeing the outcome.
Do 17 pilot requests prove customers wouldn't pay?
No.
Seventeen requests do not prove that nobody would buy the feature.
What they showed was that the experiment failed to clear the minimum threshold this company had set for committing engineering resources.
The qualitative responses then gave the team a second signal: customers recognized the problem, but several wanted a different solution.
That combination was enough to stop the planned build and investigate further.
Isn't €1,428 too small a test to trust?
A small test is not automatically a reliable test.
What matters is whether it reaches the right audience, whether the success threshold is defined in advance, and whether the team examines why people responded, not only how many did.
In this case, €1,428 ($1,649) produced a clear result against a decision rule the company had already agreed on.
That was enough to inform the next decision. It was not presented as proof of universal market demand.
What if the test says yes for the wrong reasons?
That is exactly why the responses matter as much as the count.
A campaign can hit a numerical target while attracting people for reasons that have little to do with the product you intend to build.
OpenWay AI does not only collect the result of the experiment. It keeps the customer feedback and context around that result, so the team can understand what people actually responded to.
Does this only work for a single feature decision?
No.
This company continued using OpenWay AI for new product and marketing hypotheses after the original test.
The more useful pattern is not one feature experiment. It is making validation a repeatable step before expensive execution.
See what $999 a month gets you
Not sure whether your next feature is worth building?
Test the demand before engineering touches it, and make the decision with real customer signal instead of internal consensus.