How to Validate a Side Project Idea
By Cristian Lascu · The Sovereign Technologist · Last updated: July 6, 2026
TL;DR — What's on this page
Validation done wrong wastes weeks; done right it takes 5 days. The Sovereign Technologist covers how to test an idea before you build it.
👉 Want the next list each Thursday?
Free. No spam. Unsubscribe anytime.
To validate a side project idea, extract a real commitment from real people before you build the thing — a pre-payment, a deposit, or a booked call where they walk you through the painful workaround they rely on now. Validation is not asking friends whether your idea sounds good; everyone says yes to that, because yes costs them nothing. It is deliberately engineering the smallest situation in which someone can refuse you with their wallet or their calendar. For a nights-and-weekends project, you can run that test in about five working evenings without shipping any production code.
The failure mode that quietly eats a month is validation theater: you stand up a landing page, put a few dollars behind an ad, collect a handful of email signups, and declare the idea proven. Emails are cheap to give and free to ignore, so a pile of them measures your headline, not demand for the thing you want to build. The signal that actually predicts a side business is friction someone survived — a call they kept, a deposit they paid, a spreadsheet they handed you because they're desperate to stop maintaining it. Optimize for commitments that cost the other person something they'd rather not spend.
What does 'validated' actually mean for a side project?
Validation isn't a single yes/no gate you clear once — it's a ladder of evidence, where every rung costs the other person more than the one below it. The cheap signals a side project attracts first (a friend's 'great idea', a like, an email dropped on a waitlist) are the weakest precisely because they're free to give and free to forget. The strongest signal is someone parting with money before your product exists. The whole discipline is climbing that ladder as cheaply and quickly as your evenings allow, while staying brutally honest about which rung you're actually standing on.
For a project you're building in 5-10 hours a week, set the bar at a kept call from a stranger and, ideally, one small pre-payment. That's demanding on purpose. If you can't get someone who doesn't already like you to keep a 30-minute call about the problem, the constraint is doing you a favor — it's telling you, early and for free, that the pain isn't sharp enough to carry a side business yet, long before you've sunk weekends into an MVP.
| Signal | What it costs the other person | What it actually proves |
|---|---|---|
| Likes and 'great idea' | Nothing | That they're being polite to you |
| Email on a waitlist | About ten seconds | Mild, disposable curiosity |
| A booked and kept call | Thirty minutes | The problem is worth their time |
| A deposit or pre-payment | Real money, before you've built it | They want the outcome badly enough to pay |
| A signed pilot or letter of intent | Money plus their reputation | Durable, repeatable demand you can build on |
Get the next list before everyone else.
Each Thursday, The Sovereign Technologist ships a new framework, agent-ready workflow, or curated list — built specifically for senior engineers, tech leads, and consultants who want to compound career leverage without quitting their jobs.
Free. No spam. Currently read by 141+ senior technologists.
How do I run a five-evening validation sprint?
Time-box validation to a single week so it can't decay into the endless 'researching the market' phase that side projects die in. Five focused evenings — the hours a working technologist can realistically find after the day job — is enough to reach a real answer, but only under one non-negotiable rule: no production code until the week is over. Block the five sessions on your calendar before you close this page, because a sprint you haven't scheduled is a sprint you won't run.
Notice what the plan deliberately leaves out: no logo, no domain purchase, no picking a framework, no 40-hour weekend hammering out an MVP nobody asked for. Those tasks feel like progress because they're the comfortable, familiar part of shipping software — but for a side project they're the most expensive possible way to learn whether anyone cares. The point of the week is to spend conversations and attention, never commits, on the one question your code cannot answer for you.
- →Evening 1 — Write the problem, not the solution: one paragraph naming who hurts, when it bites, and what it costs them. If you can't name a specific person, you don't have a problem yet.
- →Evening 2 — Build a list of 20-30 real people who plausibly have that problem, each paired with a concrete way to reach them this week.
- →Evenings 3-4 — Hold 5-10 conversations. Ask about their last real attempt to solve it, not about your idea.
- →Evening 5 — Make one concrete offer: a pre-order, a paid pilot, or 'I'll build this for you for $X.' Then watch what they do, not what they say.
What questions actually reveal demand — and which ones lie?
Most side-project 'customer interviews' fail because they interrogate an imagined future — 'Would you use this?' — instead of the concrete past — 'What did you do the last time this came up?' Future questions harvest politeness; past behavior is evidence. Anchor every question to something that already happened, so the person reports what they actually did rather than predicting their own good intentions about a tool that doesn't exist.
The highest-leverage move is to say nothing about your idea for the first ten minutes. The moment you describe your solution, you convert an interview into a pitch, and the person quietly switches from telling you the truth to managing your feelings. Learn exactly how they cope today first — the tabs, the spreadsheet, the manual workaround — and only then name your offer and measure the pause or the yes that follows.
- →Ask 'Walk me through the last time you dealt with this.' Avoid 'Would you use a tool that fixed this?'
- →Ask 'What did that cost you in time, money, or a workaround?' Avoid 'How much would you pay?'
- →Ask 'What are you using now, and what did you try before that?' Avoid 'Do you like this idea?'
- →Ask 'Who else has this badly enough to pay to fix it?' Avoid 'Do you think this would sell?'
- →Watch the tell: if they've never once tried to solve it themselves, it isn't a real problem for them — no matter how much they nod along.
When should I kill the idea — and when is it just the pitch?
Kill the idea when the problem fails, not when your first pitch does — they are not the same failure. A flat response can mean the pain is genuinely there but you described the solution clumsily, aimed it at the wrong person, or priced it wrong, all of which one more loop through the week can fix. It can also mean nobody actually hurts here, which no amount of clever positioning will ever repair. Confusing the two is how side projects burn months polishing a product for a market that was never there, so make the diagnosis before you either quit or double down.
When you do kill something, write the single sentence that killed it and keep it. That note is an asset: it stops you from re-running the same dead idea six months later under a new name and a fresh coat of paint, and it sharpens your instinct for the next candidate you're tempted to spend a weekend on.
- →Kill it if, after 8-10 conversations, nobody can recall a recent time the problem actually bit them.
- →Kill it if people agree it's annoying but every current workaround is free and 'good enough' for them.
- →Iterate, don't kill, if the problem clearly lands but your specific offer or audience keeps missing — change one variable and rerun the week.
- →Green-light it if at least one stranger commits money, time, or a pilot without you having to first convince them the problem exists.
For the bigger picture, read the career sovereignty guide for technologists, or jump straight to 12 ranked side-project ideas for senior technologists. To get new frameworks like this each week, subscribe to The Sovereign Technologist newsletter.
Frequently asked questions
Do I need a landing page to validate a side project idea?
No, and reaching for one first is usually avoidance dressed up as work. A landing page tells you whether your copy is compelling, not whether the problem is worth solving. Before you build one, have 5-10 direct conversations and try to secure a single real commitment — a kept call, a deposit, a paid pilot. If those go well, a landing page becomes a useful tool for scaling something that already works. If they don't, no landing page will rescue an idea nobody wants.
How many people do I need to talk to before an idea is validated?
Fewer than you'd guess — roughly 8 to 12 focused conversations with people who genuinely have the problem, not 100 survey responses. For a side project, depth and consistency beat sample size. If the same painful pattern shows up in the first handful of talks and at least one person commits money or time, that's a strong signal. If ten conversations produce only polite interest and zero commitments, that's also a clear answer: a no worth listening to before you build.
What if I can't get anyone to pay before the product exists?
That's the most valuable result you can get in a week, even though it stings. It usually means one of three things: the problem is real but you're talking to the wrong people, your offer is too vague to act on, or the pain simply isn't strong enough to pay to remove. Change one variable — audience, offer, or price — and run the sprint again. If pre-payment stays impossible across a few honest loops, believe the market and put the weekends somewhere else.
Isn't building a quick MVP faster than all this interviewing?
It feels faster because coding is the part you're already good at, but for a side project it's the slowest way to learn whether anyone cares. An MVP can take weekends to ship and still leave you guessing why nobody signed up. Five evenings of conversations and one concrete offer answer the demand question directly, for the cost of some awkward outreach. Build the MVP after a stranger has committed to it — not to find out whether they will.
One framework. Every Thursday.
If this list was useful, the next one will be too. Subscribe and you’ll get the next agent-ready playbook the moment it ships.
Free. No spam. Currently read by 141+ senior technologists.