From Side Project to Startup: A 90-Day Validation Plan

Most side projects do not fail loudly. They fade. Six months of evenings and weekends, a launch to a ripple of polite interest, then a traffic graph that goes flat and stays flat. The uncomfortable part is usually not the code. It is that the problem you were solving with such care turned out to matter mostly to you.

Ninety days is long enough to learn something real and short enough that you do not lose a year to it. The aim is not to build a miniature version of your startup. It is to find out whether anyone will change their behaviour — and part with money — before you commit your savings, your evenings or your career to it.

Validation means behaviour, not compliments

Encouraging emails are not validation. Neither is a waitlist, a survey where people rate your idea 4.2 out of 5, or a friend who says they would definitely use it. Those things cost the person saying them nothing.

Real signals cost something. A deposit. A signed pilot agreement. A subscription that renews. Someone cancelling a tool they already pay for because yours is better. An hour of their time given freely to walk you through the mess they are currently living with.

“Would you pay for this?” is a question. An invoice is an answer.

Days 1–30: narrow the problem and find ten people

Start by writing one sentence, and do not let yourself off with a vague one: [specific person] struggles with [specific problem] when [specific situation], and currently solves it by [workaround]. If you cannot fill in every blank, that is your first week's work.

Then find ten to fifteen of those people and talk to them. Not a survey — conversations. Look where they already gather: trade forums, Slack and Discord communities, subreddits, local meetups, professional associations, your own network (as long as you ask about their experience, not their opinion of your idea).

Questions that produce useful answers:

• Walk me through the last time this happened. What did you actually do?
• What did it cost you — money, time, stress, missed work?
• What have you already tried, and why did you stop?
• Who else gets affected when this goes wrong?
• If the current workaround vanished tomorrow, what would you do instead?

Banish “would you use something like this?” from your vocabulary. Hypotheticals generate polite lies; past behaviour generates data. By day 30, write a one-page summary of what you heard, including the bits that contradict your idea. If fewer than five of your fifteen conversations describe the problem without prompting, treat that as a serious warning rather than a research gap.

Days 31–60: build the smallest thing that can be sold

Choose the lightest option that genuinely tests whether someone will pay for the core value:

1. A promise and a conversation. Sell the outcome, then deliver it manually.
2. A one-page site with a real price and a working checkout. Count completed payments, not visits.
3. A concierge version. Three customers, spreadsheets and email, you doing the work by hand.
4. A thin tool that automates only the most painful step.
5. A full build. Usually the last resort, and often not something for these 90 days at all.

Put a number on it. Free users cannot validate anything, because they have nothing to lose. If you are unsure what to charge, look at what they already pay for the workaround — a freelancer, an agency retainer, a clunky subscription they complain about — and price in relation to that. Then say the number out loud and watch what happens to the conversation.

The one number that matters

Sign-ups are a vanity metric. What matters is repeat use or payment. Two customers who pay and come back beat two hundred who registered and drifted away.

Track three things: how many people paid, how long they stayed, and how much of your time each one consumed. Support load is a real cost. If five customers are eating ten hours a week, that is a business problem, not a rounding error.

Days 61–90: ask for money, then keep asking

Now the uncomfortable part. Return to your warmest conversations and ask for a commitment: a paid pilot, a deposit, a three-month agreement, or a signed letter of intent if you are selling into organisations. Run it properly.

• Agree in writing what a good outcome looks like for them, before you start.
• Charge something, even a modest amount. Free pilots attract people with no stake.
• Set an end date and a decision point.
• Ask for honest feedback weekly rather than saving it all for the end, when nobody wants to be blunt.

Two or three paying pilots give you something no amount of market research can: evidence that money moves. If nobody will pay, you have still learned a great deal, and you learned it for the cost of a few evenings rather than a few years.

How the 90 days usually go wrong

• Building first. Code feels like progress and is an excellent way to avoid talking to strangers.
• Asking friends. Friends are kind. Strangers with the problem are useful.
• Confusing interest with demand. “Send me the link when it's live” is not a commitment.
• Chasing every idea. Pick one problem sentence and hold it for the full three months.
• Ignoring delivery cost. A brilliant sales conversation that eats your weekends is not yet a business.
• Treating a no as failure. A clear no is the cheapest result available to you.

Set your decision rules before day one

Before you write a line of code, write a dated page for yourself. It states the problem sentence, the signals that mean go, the signals that mean stop, and what you will do with each outcome. Something along these lines:

• Green: five people paid, three used it more than once, support load is manageable — commit to a proper launch plan.
• Amber: a handful are interested but nobody has paid — extend by 30 days with one specific change, then re-test.
• Red: nobody describes the problem unprompted and nobody pays — stop, keep your notes, move on.

If committing means leaving a job, borrowing money or bringing in investors, take proper advice from an accountant or solicitor before you sign anything. Validation lowers risk; it does not remove it.

A project that has survived 90 days of real customers, real invoices and at least one awkward conversation is a far better bet than one that has survived 90 days of your own enthusiasm. Start with the conversations. The rest gets easier from there.

Photo: Pexels / Pixabay