Paul
I've shipped more than ten platforms in the past 3 months with Claude Code, and one of the things that's quietly happened over that stretch is that I've developed an actual decision framework for whether a new platform idea is worth building. It started as informal gut checks but has gradually turned into a real list of questions that I run every idea through before I commit to building anything, and the list has saved me from at least a few projects that would have been wastes of time. I want to share the five questions I actually ask myself, partly because the framework is useful and partly because writing it down keeps me honest about applying it consistently.
The questions are not in order of importance because they all matter, but they're in roughly the order I run them, where the early questions filter out the obviously bad ideas quickly and the later questions sharpen the genuinely good ones into something worth shipping. None of these are clever or original individually, but the combination is what actually works for a solo founder building at the speed Claude Code makes possible, where the bottleneck isn't building the platform but choosing which platforms to build in the first place.
One: Is there a real problem here or am I just excited about the idea?
The first question is whether the idea solves a problem that actually exists in the world for actual people, or whether I'm just intellectually excited about a concept that sounds clever in my head. The distinction matters because intellectually exciting ideas are the easiest to start and the hardest to grow, where you can build something genuinely interesting and then realize months later that nobody outside of you and a few friends actually wants what you built. The way I test this is by trying to describe the problem in one sentence using the words an actual user would use, and if the sentence requires me to first explain a concept or convince the reader the problem matters, that's usually a sign that the problem isn't as obvious as I thought.
The follow-up test is whether I can name three specific people who would benefit from the platform existing, where "people who might find this useful" doesn't count but "my friend who keeps complaining about X" does. If I can't name three real humans who have the problem, the platform is probably for an imagined audience rather than a real one, and platforms built for imagined audiences tend to stay empty because the imagined audience doesn't actually log in. The discipline of forcing myself to identify real users before building anything has killed more potential projects than any technical constraint ever has, and that's usually been a good thing.
Two: Can I describe the user in one sentence?
The second question is about the audience and whether I can describe who the platform is for with enough precision that someone reading the description would immediately know whether they're in or out. Bad answers sound like "people who want to track their finances" or "anyone interested in fitness," which are so broad they don't actually narrow anything down. Good answers sound like "renters in mid-sized US cities who are about to negotiate their first lease renewal" or "private vehicle sellers in states with title transfer notarization requirements," where the description is specific enough that you can picture exactly who you're building for and what their day looks like.
The reason this question matters so much is that the user description determines basically every downstream decision, including what the platform should look like, what language it should use, what features matter, where you can find the audience, and how you should price the thing. Founders who skip this step end up with platforms that try to serve everyone and serve nobody well, while founders who answer this question precisely end up with platforms that have a clear voice and a clear audience even before the first user shows up. The one-sentence user description is the document you should be able to write before you write a single line of code, and if you can't, that's a sign that the idea needs more thinking before it needs more building.
Three: What does the SEO landscape look like?
The third question is about distribution, which I've written about here as the actual hard part of being a solo founder, and it's specifically about whether there's a path to organic search traffic that I can realistically capture. The reason this question is so important is that solo founders generally can't afford to compete on paid acquisition for most categories, which means organic search is usually the only sustainable traffic source available, and a category with no organic search opportunity is a category where I'm signing up for a much harder distribution problem than I want.
The way I evaluate this practically is by spending time on Google checking what already ranks for the searches my potential users would actually type, looking at whether those results are dominated by huge sites with massive authority or whether smaller sites are competing successfully, and getting a sense of whether the content currently ranking is good enough that displacing it would require expertise I don't have. If the front page of Google for my target terms is full of sites I could realistically out-write and out-structure, that's a green light. If it's all major publications and entrenched competitors, I either need a meaningfully different angle or I need to pick a different category entirely.
The other thing I check is whether the search volume is real but not insane, where I want enough searches that a successful platform would have a meaningful audience but not so much that every well-funded competitor has already noticed and crowded the space. The sweet spot is usually a category where the searches exist consistently but the existing content is mediocre, which is rarer than you'd think but more common than people assume if you actually look.
Four: Is there a believable path to revenue?
The fourth question is about money and whether the platform has a path to generating revenue that I can actually picture working, rather than just hoping that something will materialize once I have users. The reason I push on this early is that platforms without a clear revenue model tend to slowly drift into needing to be sold as acquisitions or content sites or community plays that depend on advertising, and those exit paths are much harder and slower than just charging users money for something they value.
The version of this question I find most useful is asking whether someone would pay a specific dollar amount for a specific outcome, where the outcome has to be concrete and the dollar amount has to feel reasonable to the user I described in question two. If the answer is yes and the amount times the realistic addressable user count produces a meaningful business, the platform is worth building. If the answer requires hand-waving like "we'll figure out monetization later" or "we'll have ads eventually," that's usually a sign that the platform doesn't have a clean revenue story and is going to be harder to operate than the idea makes it look.
The other thing I look for here is whether the revenue model fits the user behavior, where one-time fees fit transactional platforms, subscriptions fit recurring-value platforms, and percentage-based fees fit marketplaces. Mismatches between revenue model and user behavior are surprisingly common in solo founder ideas, and the consequences of getting this wrong show up months later when users churn or refuse to convert for reasons that turn out to be structural rather than executional.
Five: Can I ship a credible version in two weeks?
The fifth question is about scope and whether the platform can be shipped as something usable and credible within roughly two weeks of focused work. The reason this matters isn't that everything needs to ship fast, but rather that a platform that needs months of building before anyone can use it is a platform that's going to either eat all my time on one bet or get abandoned halfway through when I realize the idea wasn't as strong as I thought. The two-week test is partly about scope discipline and partly about validating that I actually understand the platform well enough to build a minimum version, because if I can't see the path to a shippable v1 in two weeks, I probably don't have the clarity I need to build the full thing later.
The way this question shapes the work is that it forces me to identify what's actually core to the platform versus what's nice-to-have, where the core is what gets shipped first and the nice-to-haves get cut from the v1 scope. Most platform ideas have a small surprisingly-useful core wrapped in a much larger pile of features that the founder thinks are necessary but actually aren't, and the two-week ship date is what reveals which is which. If I can't strip the idea down to a two-week shippable core, the idea isn't focused enough yet and needs more thinking before it needs more building.
The other reason this question matters is that solo founders should be testing ideas through users rather than through more thinking, and the fastest path to user feedback is shipping something real that real people can react to. A platform that takes three months to build before anyone sees it is a platform where I'm betting three months on my own intuition being right, while a platform that ships in two weeks is one where I find out in week three whether my intuition was anywhere close to the reality of what users actually want.
What I do when the answers aren't all yes
The honest truth about this framework is that very few ideas pass all five questions cleanly on the first pass, and the useful thing about having the framework isn't that it tells me which ideas to build but rather that it tells me which questions need more work before I commit to building. An idea that fails the SEO question might still be worth building if I can find a different distribution channel, an idea that fails the revenue question might still be worth building if it's a learning project rather than a business, and an idea that fails the user description question almost certainly needs more thinking before it deserves any of my building time.
The way I actually use the framework is iteratively, where I run an idea through the questions, identify which ones it fails, and either revise the idea to address the gaps or move on if the gaps are too fundamental to fix. Some ideas survive the framework with minor adjustments, some survive with major reframing into different platforms than I originally imagined, and some die quietly because they were never going to work and the framework just made that obvious faster than building them would have.
The framework also gets tighter over time as I learn from the platforms I've shipped, where the questions stay the same but the standards I hold each question to get higher with experience. The version of question three I ran on my first platform would barely register as a question on my most recent one, because I've gotten more honest about what actually works in organic search and more skeptical of categories that look promising at first glance. That kind of refinement is part of why writing the framework down matters, because the act of articulating it forces the standards to be explicit rather than implicit, and explicit standards are easier to hold yourself to than vibes-based gut checks.
If you're a solo founder reading this and feeling overwhelmed by the number of ideas you could build, having a framework to filter them is genuinely useful even if the specific questions you ask end up being different from mine. The point isn't that these five questions are the right five, but rather that having any consistent five is better than picking ideas based on whichever one happened to be exciting on a given afternoon. The cost of building the wrong platform is months of your life, and a framework that costs you ten minutes of evaluation per idea is the cheapest insurance against that cost you'll ever get.
