LaunchMind
Inspiration
We're three students at universities in Pakistan — the kind of place where you have real ideas and zero access to the people who could tell you whether they're any good. No mentors. No accelerators. No "let me introduce you to someone who's done this before." Just an idea, a laptop, and a lot of uncertainty about what you don't know you don't know.
We've watched friends spend months building things nobody asked for — not because the ideas were bad, but because nobody ever sat down with them and asked the one question that would have changed everything. Generic planning tools didn't help. They hand you a task list — "define your audience, build an MVP, get users" — which is technically true and completely useless if you don't already know what's wrong with your thinking.
We wanted to build the thing we wished we'd had: not a checklist, a thinking partner.
What it does
LaunchMind takes a vague startup or social-impact idea — one sentence or a paragraph, no structure required — and runs it through a four-stage reasoning chain:
Context extraction — a handful of adaptive clarifying questions, generated specifically for this idea, not a fixed template Assumption excavation — 3-5 hidden assumptions the founder is making without realizing it, each tagged as either a common risk pattern or specific to this founder's own answers Kill-shot risk — the single biggest risk that could end the idea, framed as an open question to investigate rather than a verdict First step + validation plan — one concrete, zero-cost action for this week (always: talk to real people), plus a two-branch plan for what week two looks like depending on what that conversation reveals
Every assumption is also clickable — founders can expand any individual assumption and see a tailored way to go test that exact risk, rather than the same generic "talk to users" instruction repeated four times.
A founder using LaunchMind on an idea like "an app connecting households with recyclable waste to local scrap dealers" doesn't get "define your target market." They get told they're assuming dealers actually want a new sourcing channel when their existing door-to-door system might already work fine for them — a risk specific to their own stated context, not a generic startup truism.
How we built it
We built the reasoning chain first, before any UI — because the entire value of this product lives in whether the reasoning is actually sharp, not in how it looks. We wrote and rewrote the prompts across several real test ideas (a tutoring app, a recycling marketplace, an internship platform) until the kill-shot risk reliably changed in kind — not just in wording — depending on what the founder actually told us, rather than reverting to the same generic advice regardless of input.
Once the reasoning was solid, we built the interface around it: Streamlit for the frontend, Gemini 2.5 Flash for the reasoning, deployed on Streamlit Community Cloud. We designed the visual identity around the product's actual subject — excavation, surfacing things buried out of sight — rather than a generic SaaS template, because the metaphor of "digging something up into the light" is literally what the product does to a founder's blind spots.
We also built a lightweight local history feature, so a founder can come back after actually talking to users and revisit what LaunchMind originally flagged — closing the loop between the AI's prediction and what really happened.
Challenges we ran into
The first real challenge was making the AI's reasoning genuinely adapt instead of just sounding adaptive. Early prompt versions produced output that felt specific but was structurally identical across different ideas — the same shape of assumption, just with nouns swapped. We fixed this by explicitly instructing the model to distinguish common risk patterns from context-specific ones, which forced the reasoning itself to actually differentiate rather than just vary its wording.
The second challenge was infrastructure, not AI: working entirely on the free tier of Gemini's API meant navigating rate limits, model deprecations, and a quota ceiling that occasionally meant retrying or falling back gracefully. We built automatic retry logic with backoff, a model fallback chain, and a deterministic stub response so the product never breaks for a user even if the live API call fails — which matters a lot for a tool aimed at founders who, like us, don't have a budget for paid infrastructure.
The hardest design challenge was Responsible AI — not as a checkbox, but structurally. The real risk isn't that the AI gives bad advice; it's that a founder treats any AI output as permission to commit months of their life to an idea that was never actually tested. We addressed this by making the system structurally incapable of declaring an idea good or bad — every output is a question to investigate, every first step is a mandate to talk to a human, and every analysis closes with an explicit reminder that the only real validation is real users, not us.
Accomplishments that we're proud of
We're proud that the reasoning actually holds up under stress-testing, not just on the demo example. We ran the same product through several genuinely different ideas — an AI tutoring app, a peer-to-peer recycling marketplace, an internship-matching platform — and the kill-shot risk changed in kind each time, not just in wording. For the tutoring app, the risk centered on whether students would pay when free alternatives exist. For the recycling marketplace, it shifted entirely to whether scrap dealers would adopt a new sourcing channel at all. That's a real signal the system is reasoning from the founder's specific situation, not pattern-matching to a template.
We're also proud of how seriously we took Responsible AI as a design constraint rather than an afterthought. The confidence-tagging system — labeling each assumption as a common pattern versus something specific to the founder's own answers — wasn't in our original plan. We added it because we realized a founder needs to know which kind of insight they're looking at to calibrate how much weight to give it, and that distinction is now load-bearing in how the product builds trust.
And we're proud we kept moving as a small team with zero budget, working entirely within free-tier constraints, and still shipped a fully working, deployed product with a real interactive interface — not just a static mockup or a single hardcoded demo path.
What we learned
We learned that making an AI tool feel genuinely intelligent is less about the interface and almost entirely about whether the underlying reasoning differentiates correctly. Our biggest improvements in this project weren't visual — they came from rewriting prompts until the model stopped giving "good enough" generic answers and started actually reasoning from the founder's specific context.
We also learned how much Responsible AI design benefits from being structural rather than cosmetic. A disclaimer at the bottom of a page is easy to ignore. A system that is architecturally incapable of saying "your idea will succeed" — because that's a hard rule at the prompt level, not a suggestion — does more to actually protect the user.
On the practical side, we learned a lot about working within free-tier infrastructure limits: rate limits, model deprecation, and the importance of graceful fallbacks so a real user's experience never breaks even when the underlying API has a bad moment.
What's next for LaunchMind
We'd want LaunchMind to close the loop — let founders log back in after they've actually run their validation step, and tell the system what they learned, so future reasoning gets sharper based on real outcomes, not just the original input. We're also thinking about multi-language support, since many of the students who'd benefit most from this aren't thinking in English when the idea first forms in their head.
The goal has never been a smarter chatbot. It's getting closer to what an actual mentor gives you: not information, but judgment.
Log in or sign up for Devpost to join the conversation.