The person behind Yibud
About the author
An independent developer who has spent years building, shipping, and quietly invalidating his own startup ideas. Yibud is what survived the lessons.
Last updated · July 27, 2026
Short biography
Who writes here
Yibud is built and written by one person — a software developer who has been shipping small products for the better part of a decade. Some of those products found customers. Most did not. Each one taught the same thing in a different accent: building is the easy part. Knowing whether to build is the hard part.
This site is the consolidation of those lessons. The articles are long because the questions are long. The reports are structured because decision-making is structured. The product is small on purpose — the goal is not to build a platform, but to ship something that genuinely helps someone decide whether the next six months of their life are worth spending on an idea.
I prefer to write under the Yibud name rather than a personal one. Not out of false modesty — the work is what matters, and the work belongs to the project. If you are reading this and considering a similar path: I would rather you find the ideas useful than find the author interesting.
Why Yibud exists
The reason this site exists
Yibud exists because I have watched — in myself and in friends — the same pattern repeat. A clever idea. A few months of building. A quiet launch. A longer quiet. Eventually the project gets parked in a folder somewhere, and life moves on. The pattern is rarely about talent. It is rarely about execution. It is almost always about validating the wrong assumption at the wrong time.
The first version of this tool was a spreadsheet I used to grade my own ideas before committing to them. Then a Notion template. Then a small script. Yibud is what the script grew into. I keep it because every new idea I have still gets run through it — including, occasionally, the ideas that look like they might actually be good. The tool exists because I needed it. The fact that other people seem to need it too is the only reason it is public.
Philosophy
What I believe about startup ideas
Most startup ideas do not die from competition or bad luck. They die from a single false assumption that nobody tested early enough. The work of validation is the work of finding that assumption before you have built around it.
Evidence beats intuition. Not always, and not in every domain — but in the part of starting a company that affects the next six months of your life, evidence is cheaper than conviction and almost always more honest.
A structured score is not a verdict. It is a way of seeing your own idea from the outside — a way of noticing the parts you have been avoiding. The report is most useful when you argue with it.
Yibud is opinionated. The rules encode opinions about which patterns predict traction and which predict trouble. The opinions are evidence-driven but not neutral. Read them as a strong starting hypothesis, not as the truth.
Writing principles
How these articles are written
Every article is built from specific patterns I have observed across the indie launch literature and the projects I have shipped, killed, or quietly let fade. Theory is used sparingly. Practical frameworks and concrete examples are prioritized over abstract advice.
When a claim is empirical — when it can be tested — I try to test it. When a claim is opinion, I mark it as opinion. I do not invent statistics, fabricate founder quotes, or invent company names to make a point land harder. The honest version of an idea is almost always the most useful one.
Articles are updated as new evidence appears. If something I wrote turns out to be wrong, I change it and note the change. The edit history on every article is part of the article. Errors are part of the record, not hidden from it.
Areas of focus
What I write about
Pre-build validation
The cheapest, fastest ways to test whether an idea is worth the next six months of your life — before you write a line of code.
Assumption testing
How to find the single assumption that, if false, would invalidate the entire plan — and how to test it in days, not months.
Distribution & first customers
Realistic customer-acquisition channels for solo founders. No growth-hack theatre, no fake virality — just the channels that actually work for a small team.
Indie founder economics
Pricing, monetization, scope, and the day-to-day math of running a one-person product. The unsexy parts that decide whether you keep going.
Recent writing
Latest articles
How to Price a New SaaS Product: Three Decisions, Four Questions, and the Only Pricing Test That Survives Launch
The three pricing decisions a new SaaS founder actually owns (model, value metric, price points), the four Van Westendorp questions that produce real willingness-to-pay data, and the eight-week playbook that turns the answers into a defensible price.
Customer Interview Questions for Startup Validation: How to Ask Ones That Produce Evidence
Customer interview questions for startup validation, organized by what you need to learn — past behavior, current workarounds, decision context, and spending — plus the questions founders should stop asking, an interview-to-decision framework, and a realistic B2B SaaS scenario.
Startup Failure Analysis: How to Read a Failed Startup the Right Way
Startup failure analysis is the discipline of converting documented startup failures into testable assumptions. Five real cases — Quibi, Webvan, Juicero, Homejoy, WeWork — analyzed with a seven-rung framework, then turned into the validation experiments a solo founder can run this week.
Lean Startup Validation: How To Choose, Design and Interpret Validation Experiments
How to use Eric Ries's Build-Measure-Learn loop to pick the next validation experiment — including the five-question decision framework, decision-threshold thinking, three labeled hypothetical examples, and the failure modes that distort the loop before the founder notices them.
Problem-Solution Fit: How to Know Your Solution Solves a Real Problem Before You Build It
Problem-solution fit is the state where a defined customer has a defined problem and a defined solution would meaningfully improve their situation. The five rungs of evidence that prove the fit is real, the six failure modes that show it isn't, and the 14-day validation framework that separates real pain from polite enthusiasm.
Yibud is written under a project name by design. If you want to reach the person behind it, use the address on the Contact page.
HOW THIS PUBLICATION WORKS
How the writing is held to a standard
EDITORIAL POLICY
How topics get chosen
Our process for picking questions, sourcing claims, and correcting errors after publication.
CONTENT PRINCIPLES
What every article must do
The evidence-first standard every Yibud essay is held to before it ships.
SOURCES
Books and writers we lean on
The reading list that informed this publication.
Read enough? Try the tool.
If the essays above describe the kind of analysis you trust, Startup MRI runs the same scoring in under a minute — free, no signup.