The 7 Questions That Kill Bad App Ideas Before You Waste Six Months

These seven questions take fifteen minutes to answer honestly and can save you six months. Write your answers down, do not just think them. 1. Is this a recurring problem or a one-off annoyance? A problem someone hits every week deserves a tool. A problem someone hits once a year does not, no matter how annoying it is in the moment. If you cannot describe how often your target user runs into this, you have not found the problem yet. 2. Does something already solve this reasonably well? A spreadsheet, a paper form, a competitor's app, even a clunky workaround all count as existing solutions. If people are already coping fine, your app needs to be dramatically better, not just newer. If nothing solves it at all, ask why: sometimes that is opportunity, and sometimes it is a sign the problem is not big enough for anyone to have bothered. 3. Would solving this actually change something meaningful in the person's life or work? Saving someone four minutes a week is not meaningful. Saving someone four hours a week, or stopping a mistake that costs them money, is. If the honest answer is "it would be nice to have," that is a warning sign, not a green light. 4. Would you use this yourself for the next six months? Not would you use it once to test it. Would you genuinely keep opening it every week for half a year. If the honest answer is no, that tells you something important about how compelling the problem really is, because you presumably understand it better than any stranger you will pitch it to. 5. Is the problem painful enough that someone would go out of their way to learn a new tool to fix it? Adopting new software is real friction. People will only push through that friction for a problem that genuinely bothers them, not one they can shrug off. Ten open browser tabs is annoying, but almost nobody goes looking for a tool to fix it, because it is not painful enough to justify the effort of learning something new. 6. Do you have any real unfair advantage in solving it? An unfair advantage is domain experience most people building apps do not have: you have done this job, you have felt this exact friction, you already know the workarounds people use and why those workarounds fail. Building from the outside looking in is a much harder game than building from the inside looking out. 7. Is there a specific person you can name today who has this exact problem? Not a category like "small business owners" or "tradies." An actual name, someone you could message this afternoon and describe their problem back to them accurately. If you cannot name anyone, you may be solving a problem that exists mostly in your head.

The strongest app ideas usually come from people who already work inside the problem, not from people searching for a problem to solve. A project manager who has spent years drowning in status update meetings has a genuine edge over a generic founder who read that project managers hate status meetings. The PM already knows which parts of the process are actually broken, which fixes teams have already tried and abandoned, and which colleagues would test a new tool tomorrow if asked. A generic founder shopping for an idea has none of that. They have to research the problem from zero, guess at what a real workflow looks like, and hope their guess is close enough. This advantage shows up constantly outside software too. An ops person who has manually reconciled invoices for three years knows exactly where the process breaks. A tradie who has chased unpaid quotes for a decade knows precisely which follow-up actually gets a reply. A bookkeeper who has triaged a client's messy books for years knows which document is always missing first. None of these people think of themselves as "founders," but each one is sitting on a problem most outside builders would take months to even properly understand. If your unfair advantage question came back weak, that does not mean abandon the idea. It means go find someone with the advantage you lack and work with them, or pick a different problem where your own background actually counts for something. Question six is the single strongest predictor in this whole checklist, because domain knowledge fills in the hundreds of small decisions an AI tool cannot make for you.

Answer all seven questions honestly, on paper, before you write a single prompt, and treat any weak answer as a signal to dig deeper rather than push through. The temptation is to skim the list, feel generally good about your idea, and open Cursor anyway. Resist that. Write out a one or two sentence answer to each question. If you find yourself hedging on a question, that hedge is the real answer. "Kind of a recurring problem" usually means it is not one. "I think I'd use it" usually means you would not. A weak answer on one question is not necessarily fatal. A weak answer on three or more questions almost always is. If questions one, five, and seven all come back shaky, no amount of good execution during the build will rescue the idea, because the problem never had enough demand behind it to begin with. This is deliberately separate from planning your build. Once your idea survives these seven questions, the next document you need is a one-page spec that tells an AI tool exactly what to build: the screens, the data, the AI feature, and what is explicitly out of scope. Validation and specification are two different documents solving two different failure modes, and skipping either one leads to the same place: a finished app nobody asked for.

buildAcademy runs this exact validation step before anyone touches an AI coding tool, because the most expensive mistake in app building happens before the first line of code. Most vibe-coding tutorials and courses start with the tool: open Cursor, open Lovable, start prompting. That order teaches you to build fast in the wrong direction. Week one of buildAcademy starts with your idea, not your prompt. You work through this exact checklist with mentors in the room who will push back on a vague answer instead of letting it slide, because a stranger asking the hard question is far more useful than asking it of yourself alone. By the end of week one, you leave with a validated problem, a named first user, and a clear unfair advantage you can point to, before week two even begins on the build itself. If your idea does not survive the checklist, that is not a wasted week. It is five months saved. You can run this checklist alone with this guide, and you should, today, before you open any AI tool. If you want it done properly, with people in the room who will not let a weak answer through, that is exactly what week one of buildAcademy is for. Details are at 13labs.au/buildacademy.

How long should app idea validation actually take? Fifteen to thirty minutes to answer the seven questions honestly, plus a few days if you need to go find and talk to the specific person you named in question seven. Validation should never take longer than a small fraction of the time you plan to spend building. What if my idea fails two or three of the seven questions? Treat that as real information, not a reason to feel bad. A weak answer on one question can often be fixed by narrowing the idea. Weak answers on three or more, especially questions one, five, and six, usually mean the problem is not big enough to carry an app, no matter how well you build it. Can I validate an idea without any coding or design skills? Yes. None of the seven questions require technical knowledge. They are about the problem and the person who has it, not about the software. Answering them honestly is the one part of the whole process that has nothing to do with AI tools at all. Is talking to friends and family enough to validate an idea? No. People close to you tend to be encouraging rather than honest, which is why question seven asks for a specific person with the exact problem, not a friend being polite about your app. Look for someone who is currently living with the problem, ideally a stranger, and ask what they actually do about it today. Do I still need a written spec if my idea passes validation? Yes, and it is a different document. Validation tells you whether the problem is worth solving. A one-page spec tells your AI tool exactly what to build once you know the answer is yes. Skipping the spec after passing validation just moves the guessing from "is this worth building" to "what exactly am I building," which causes its own version of wasted months.