Start before you are ready
I used to be a perfectionist. Everything I shipped had to be polished, buttoned up, and ready for scrutiny. If it wasn't perfect, it wasn't going out the door. Then I started paying closer attention to the products I actually used every day, and something clicked. Even billion-dollar companies ship imperfect work. Anthropic's Claude desktop app, for example, was missing basic UX features for months. Navigation felt sluggish, the interface didn't always make sense, and a recent update actually made things worse for a lot of users. I ended up going back to the CLI and VS Code. If a company with that much talent and funding ships rough edges, maybe perfection was never the bar I thought it was. That realization changed how I approach building things.
The real cost of waiting
Perfectionism is sneaky. It disguises itself as high standards, but what it really does is stop you from moving. You spend weeks refining an idea in your head, months planning out a roadmap, and by the time you're "ready," the window has closed or your motivation has evaporated. Y Combinator has written about this extensively. Psychological factors like pride, perfectionism, scope creep, and fear of criticism all conspire to delay shipping. The longer you wait, the more you optimize for a version of reality that doesn't exist yet. You're essentially building on assumptions, not evidence. The lean startup methodology captures this well: validated learning beats theoretical planning. Eric Ries argues that the unit of progress for startups isn't polished features, it's learning. And you can't learn if you never put something in front of people.
Validate demand, then worry about supply
In the current era of AI agents and rapid tooling, a lot of what you build can be replicated quickly. The barrier to entry for most software is lower than ever. So the real advantage isn't in building the most polished product first, it's in confirming that people actually want what you're making. I learned this firsthand with a hackathon I tried to organize earlier this year. It was called the Payday Hackathon, and I was co-hosting it with two friends. We had the event scheduled for May, but we launched the event page back in January with just a description. No sponsors lined up, no venue finalized, no detailed agenda. Just the concept and a signup form. Sixty-seven people signed up. The demand was clearly there. We ended up postponing the event because the timing wasn't right for all three co-hosts, and we didn't want to deliver something half-baked. But here's the thing: nobody lost anything. We announced the postponement honestly, encouraged people to pursue their ideas regardless, and moved on. The validation was real, and whenever we're ready to revisit it, we already know there's an audience. This is the core idea: you don't need everything figured out before you start. Launch the landing page. Open signups. See if anyone shows up. If they do, great, now you have a reason to build. If they don't, you just saved yourself months of wasted effort.
Demand shows up on its own timeline
Two years ago I launched a small business selling customized NFC name cards. The pitch was simple: in an era where people are trying to cut down on paper waste, why not have a personalized, reusable card that shares your details with a tap? I put up a website, advertised personalized designs, and waited. For two years, almost nothing happened. A few potential clients showed interest, but none of it converted. I figured the idea had quietly died. Then in the past few days, out of nowhere, I got around ten messages from different people asking about personalized name tags. No marketing push, no relaunch, no new content. The demand just showed up. Here's the kicker: I had advertised personalized designs without ever testing whether I could actually deliver them. When someone finally sent me designs to customize, I couldn't do it. I told them honestly that I was having issues and refunded the design fee. Was it a little embarrassing? Sure. Did anyone actually lose anything? Not really. I didn't charge for what I couldn't deliver, and I learned in a single afternoon what two years of planning couldn't have taught me: the demand was real, but my supply pipeline wasn't. Now I know exactly what to fix. You genuinely never know when or how things will turn out. The only way to find out is to put something out there and see what comes back.
Build the minimum, find the signal
Another example from my own experience: last year I built an app called Dance, a local meeting note-taker that ran entirely on local AI models. I had a basic MVP, nothing fancy, and I went out to find potential users before investing more time into it. The response was encouraging. People were genuinely interested in having a privacy-first, local-first meeting assistant. But the local model ecosystem wasn't mature enough at the time. Transcription quality was inconsistent, and the experience wasn't reliable enough for daily use. So I shelved it. Was that a failure? I don't think so. I validated the concept with real people, discovered a genuine technical constraint, and made an informed decision to stop, all without spending months in a vacuum building features nobody would use. That's a win disguised as a cancellation. I'm applying the same approach to what I'm building now, <mention-page url="https://app.notion.com/p/4512c7d1a50b4cc8bd0f4d9005867653"/>. I'm not building blind. I already have signal from the previous version of Ryu that there's real interest in agent orchestration, and it's obvious the industry is moving hard into the local AI and agentic era. Before writing serious production code, I've been talking to potential users, gauging interest, and looking for clients who want what I'm planning to make. The building only starts once the demand is clear.
The gold rush is over
There's a particular trap I see a lot of people falling into right now. Everyone's racing to build AI-powered tools, treating the current moment like a gold rush. Build fast, ship something, capture market share. But the gold rush playbook has a flaw. When everyone is building, the supply side gets crowded fast. What actually matters is whether there's real demand for your specific thing. The people who win aren't necessarily the ones who built first. They're the ones who confirmed someone would pay for what they were making before they wrote a single line of production code. This is exactly what the lean validation framework advocates: demo, sell, then build. One founder validated a VR platform concept by getting 12 out of 15 architects to commit to paying $5,000 a month before writing any code. That's an 80% conversion rate on a product that didn't exist yet. Compare that to Google Glass, which sounded brilliant on paper but failed because nobody bothered to check whether customers actually wanted it at that price point.
Isn't this a bit dishonest?
People sometimes push back on this approach. Isn't it scummy to advertise something you haven't built? Isn't it misleading to open signups for a product that doesn't exist yet? I don't think so, and here's why. I'm not claiming to have something I don't. I'm saying, this is what I'm planning to build, would you be interested? That's a completely different statement. It's market research, requirements gathering, and customer development rolled into one honest question. Compare it to the alternative: spend six months building in a vacuum, launch to crickets, and then realize nobody wanted it in the first place. That's the path most builders take, and it's how you end up with a graveyard of features nobody uses. Worse, you often end up shipping the same thing everyone else is shipping, because you never paused to check if it was the right thing to make. Neither side loses by asking first. The potential user gets early visibility into something they might want, often with a chance to shape it. You get evidence about whether to build at all. That's not scummy, that's just doing your homework before you commit.
Just start
I've shipped event pages with no logistics behind them. I've built apps that got shelved after a few weeks. I've launched ideas that didn't go anywhere. And none of that was wasted. Every time I started before I was ready, I learned something I couldn't have learned from planning alone. The hackathon taught me that community interest is real but timing matters. Dance taught me that being early to a technology wave isn't always an advantage. And all of it reinforced the same lesson: the cost of starting and failing is almost always lower than the cost of waiting and never trying. So if you have an idea sitting in your notes, stop refining the plan. Put it out there. See if anyone cares. If they do, figure out the rest. If they don't, you just freed yourself to move on to the next thing. You don't need permission. You don't need a perfect plan. You just need to start.
References
- Y Combinator, "The Art of Shipping Early and Often" https://www.ycombinator.com/blog/tips-ship-early-and-often/
- Eric Ries, "The Lean Startup Methodology" https://theleanstartup.com/principles
- Lean Foundry, "How to Validate Any Startup Idea in 90 Days" https://www.leanfoundry.com/newsletter/jul-31-2025
- Itamar Novick, "Startup Anti-Pattern #8: Analysis Paralysis" https://www.itamarnovick.com/startup-anti-pattern-8-analysis-paralysis/
- Deloitte Insights, "Bias Toward Action" https://www.deloitte.com/us/en/insights/topics/talent/prioritize-action-over-discussion.html
- URL Launched, "Value Hypothesis & Growth Hypothesis: Lean Startup Validation" https://www.urlaunched.com/blog/lean-startup-validation-value-growth