How we validate a digital business idea before building it

The most expensive way to find out that nobody wants your product is to build it first. Yet that is how many digital businesses are started: someone has an idea, falls in love with it, spends months building, launches — and discovers that the people they imagined do not exist, will not pay, or cannot be reached at a sensible cost.

At Oryvelon, Validate is the second stage of our operating model, after Discover and before Build. It is the cheapest stage in a company's life and the one with the most leverage. This note explains how we approach it.

What validation is trying to answer

Validation is not about proving that an idea is good. It is about finding out, as cheaply as possible, whether three things are true.

1. The problem is real. A specific group of people experiences it often enough, and painfully enough, to want it solved.
2. Someone will pay. Not "would find it useful" — will actually pay, at a price that can sustain a business.
3. They can be reached. There is a realistic, affordable way to put the product in front of those people repeatedly.

If any of the three is false, the idea does not become a company in its current form. It might change shape; it might wait for a better moment; it might stop entirely. All three outcomes are fine.

Behaviour beats opinion

The most important principle in validation is simple: trust what people do, not what they say.

People are kind. Show them an idea and many will say it sounds great. Ask in a survey whether they would use it and a surprising number will say yes. Neither tells you much. The signals that matter are the ones that cost the person something — time, attention, money or reputation.

We design validation so that people have the chance to show strong signals.

Step one: talk to people with the problem

Before building anything, we talk to people who have the problem. Not about our idea — about their situation.

For an idea like MerchNivo, that meant conversations with store owners about how they actually run their day: which screens they open, what they check, what they forget, what they would hand to someone else if they could. For KeşifAtlası, it meant understanding how people currently research visa options, where they get stuck and what they end up paying for.

Good questions are about the past, not the future:

• "When did this last happen to you?"
• "What did you do about it?"
• "What did that cost you — in time or money?"
• "What have you tried already?"

If people struggle to remember the last time the problem occurred, it probably is not painful enough. If they have already tried to solve it — with spreadsheets, freelancers, workarounds — the problem is real.

Step two: write the offer before the product

Next we write the offer as if the product existed: a clear description of what it does, who it is for and what it costs. This is harder than it sounds, and the difficulty is informative. If we cannot describe the value in a few sentences a customer would understand, the idea is still too vague.

The offer becomes the core of the phase-zero site: a real page with real content explaining the problem and the solution, and a way to register interest.

Step three: put the offer in front of real people

A phase-zero site lets us measure how strangers respond to the offer. We look at:

• how many visitors understand it well enough to act (join, reply, request access);
• which messages and headlines produce more action;
• where visitors come from, and which channels bring people who act;
• what questions people ask when they get in touch.

Because the site is built properly — clear structure, fast pages, sensible search markup — it also starts building discoverability long before launch. See Search and AI-assistant visibility.

Step four: run a manual version

One of the most useful validation techniques is to deliver the value manually before automating it. Sometimes called a "concierge" test, it means doing by hand what the product will eventually do by software.

For a store-operations product, that might mean reviewing a handful of stores' data manually and sending each owner a written weekly briefing. For an eligibility product, it might mean evaluating a small number of cases by hand against the rules and producing a report.

Manual versions teach things that no survey can:

• what people actually value in the output;
• which parts they ignore;
• what they ask for that we had not thought of;
• whether they come back for more;
• how long the work really takes, which informs pricing and automation priorities.

Step five: test the price

Price is where many ideas quietly fail. We test it directly rather than assuming.

The simplest test is to state a price and see what happens. On a phase-zero site, that might be a clearly stated price on the offer page. In conversations, it might be asking whether someone would pay a specific amount — and, better, whether they would pay now for early access.

Reactions to a price are more useful than reactions to an idea. "That's too much" followed by an explanation tells you what value the person perceives. "Can I pay annually?" tells you something else entirely. A deposit, a pre-order or a paid pilot is the strongest validation signal there is.

For subscription products we also test the unit: per store, per seat, per student, per report. The right unit often matters more than the exact number. We discuss pricing in more depth in Subscription plus usage: pricing logic for AI SaaS.

Step six: check the channel

The third question — can we reach these people affordably? — is often left until after launch, which is too late. During validation we try at least one or two acquisition channels at small scale:

• search, by publishing genuinely useful content on the phase-zero site;
• communities where the target users already gather;
• partnerships with businesses that already serve them;
• the group's own reach, such as founder authority sites and oryvelon.com, measured carefully with consistent UTM parameters;
• small paid tests, where the economics make sense.

We are not looking for a perfect channel. We are looking for evidence that at least one channel can bring the right people at a cost the business can support.

The signals we deliberately ignore

Some signals feel meaningful and are not.

Total visitors. A spike of traffic from a lucky post says little about whether the right people care.

Compliments from friends and family. Kind, but not evidence.

Competitor funding. A well-funded competitor suggests the problem may be real, but tells you nothing about whether you can win.

Our own excitement. The founders being excited is necessary but nowhere near sufficient.

Feature requests from people who would not pay. Useful for understanding the problem; dangerous as a roadmap.

How validation fits the protocol

Validation runs alongside the early steps of our 10-step protocol. Conversations inform the one-sentence problem. Pricing tests inform the revenue mechanism. Repeat behaviour in manual pilots informs the recurring loop. The phase-zero site is step eight in the protocol, but a simple version of it often appears during validation.

By the time an idea reaches the Build stage, we expect to have:

• a clearly stated problem, confirmed by people who have it;
• an offer that strangers understand and act on;
• evidence that someone will pay, ideally money already committed;
• at least one channel that can bring the right people affordably;
• notes from a manual version showing what users actually value.

If we cannot say those things, the idea is not ready to build.

How long validation takes

Less time than most people expect, and more time than most people spend. A focused validation phase is usually measured in weeks, not months. The goal is not certainty — there is no certainty in a new business — but enough evidence that building is a reasonable bet rather than a hopeful one.

The risk to watch for is validation that never ends. If we keep running "one more test" because we are afraid of the answer, we are not validating any more; we are procrastinating. The continue, stop or scale discipline applies here too: at a pre-agreed point, we decide.

When validation says no

Many ideas fail validation. That is the point. A few common outcomes:

• The problem is real but nobody will pay enough. Sometimes this means a different customer segment will. Sometimes it means the idea belongs as a feature in another product rather than a company of its own.
• People will pay but cannot be reached affordably. This often calls for a partnership model or a different entry point.
• The problem is smaller than it looked. People manage well enough with what they have.
• The idea is right but the timing is wrong. A regulation, technology or market shift may change the picture later. We write down what would need to be true and revisit it.

In every case, the work is not wasted. Conversations, offers and experiments become knowledge the group keeps. More than once, a failed validation for one idea has sharpened the understanding of a problem another company solves.

Validation in a company builder versus a single startup

Validating inside a group has a few advantages we try to use well, and a few risks we watch for.

Advantages. The foundations already exist, so a phase-zero site with proper measurement can go live quickly. The group has experience across several markets, which helps with channel and pricing tests. And the founders' existing networks — e-commerce operators, brands, creators, educators — make it easier to find people to talk to.

Risks. It is tempting to skip validation because launching is easy. It is also tempting to use the group's reach to create a flattering early signal — traffic from oryvelon.com is not the same as demand from strangers. We separate those sources in our measurement so we are not fooled by our own audience.

A validation checklist

For anyone validating an idea, here is the short list we use.

• [ ] We have spoken to people who have the problem, about their past behaviour.
• [ ] We can describe the offer in a few sentences a customer understands.
• [ ] A real page with that offer is live and measured.
• [ ] We have delivered the value manually to at least a few people.
• [ ] We have stated a price and seen real reactions — ideally payments.
• [ ] At least one channel has brought the right people at a sensible cost.
• [ ] We have written down what we learned and what would make us stop.

If most boxes are ticked, the idea is ready for the Build stage. If not, the missing boxes are the work.

Conversation guides by business type

The questions we ask change with the type of business. Here are the guides we start from.

For software sold to businesses (the MerchNivo type): - Walk me through the last time you dealt with this. Which tools did you open? - Who else in the business touches this work? - What do you pay today — in software, freelancers or staff time — to handle it? - If this disappeared tomorrow, what would break first?

For marketplaces (the CastLyra type), we run two guides, one per side: - Businesses: how did you find the last person you hired for this? How long did it take? What went wrong? - Talent: where do your best opportunities come from? How do you tell a serious request from a waste of time?

For consumer products (the ZodiVela type): - When did you last use something like this? What made you open it? - What did you like about it, and what made you stop? - Have you ever paid for something similar? What made it worth it?

For decision-support products (the KeşifAtlası type): - Where did you look for information? Which sources did you trust? - What decision were you trying to make, and what was at stake? - Did you pay anyone for advice? What did you get for it?

For education and services (the EduRelia and Sinem Keser Beauty Academy types): - Who decides to buy, and who uses it? Are they the same person? - What does progress look like to you, and how do you know it happened? - What would make you recommend this to someone else?

The guides are starting points, not scripts. The best conversations follow the person's story.

Write the stop criteria before the test

The most useful habit in validation takes five minutes: before running any experiment, write down what result would make you stop, change course or continue. Once the results arrive, it is too late. Every number can be explained away by someone who wants the idea to live.

We keep the format simple:

The thresholds behind "most" and "some" are set per idea, in writing, and agreed before the test starts. A narrow B2B product may need only a handful of committed customers to justify building; a consumer product needs evidence at a larger scale. What matters is that the line is drawn first.

It also helps to estimate, roughly, whether the business can work at the price being tested. A few lines on what it will cost to serve one customer — hosting, AI usage, support time, payment fees — often reveal that a promising price leaves no margin. We cover that arithmetic in Unit economics per product.

Validation experiments by business shape

The conversation guides above are the same for every idea in spirit. The experiments that follow them differ, because different kinds of business fail in different ways.

Marketplaces must validate both sides, and the order matters. For a business like CastLyra, talent interest without business demand is a directory, and business demand without verified talent is a disappointment. Validation asks which side is harder to attract and whether the first participants on that side can be recruited by hand. See Solving the cold-start problem.

Decision-support products can let the free step do the validating. For KeşifAtlası, a short free eligibility test is both a useful tool and a validation instrument: it shows how many people complete it, which situations are most common and how many ask for more detail. The step from that test to a paid report is the price test. We describe the design in From free test to paid report.

Commerce brands validate with small, real orders. For a product brand like Noveniq, the honest test is a limited run of real products, sold to real customers, with every cost counted — including returns and delivery problems. A store that runs for real also teaches lessons that feed the group's software. See Using a real store as a testbed.

Consumer subscriptions validate retention, not sign-ups. Signing up for a free reading or a trial is easy. The signal that matters for a product like ZodiVela is whether people come back on their own the following week, and whether some choose to pay for more.

In each case the experiment is chosen to test the most likely reason this particular kind of business would fail. That is the whole idea: find the weak point cheaply, before it is built into the product.

Summary

Validation is where good companies save the most money and where weak ideas should end quietly. At Oryvelon we look for behaviour over opinion, test offers and prices before code, deliver value manually before automating it, and check that customers can be reached before committing to build. It is not glamorous work, but it is the reason the companies on our Companies page are companies rather than experiments.

Questions and answers

How does Oryvelon validate a new business idea?

By testing whether the problem is real, whether people will pay and whether they can be reached affordably — using conversations, a phase-zero website, manual pilots and pricing tests before building the full product.

What signals does Oryvelon trust during validation?

Behaviour: people signing up, replying, paying or pre-ordering, returning and recommending. Compliments and survey enthusiasm count for little.

What happens to ideas that fail validation?

They stop or change shape. Stopping early is one of the main purposes of validation.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Company Building

NextPhase-zero sites: launching a brand before the product exists →