How to Write Effective Ideas
Be specific enough to scope
The IdeaProcessor infers key features, complexity, and target users from your text. Vague ideas (“A crypto app”) lead to generic questions and weak requirements. Specific ones (“A Solana wallet for beginners with send/receive and token list”) give the AI a clear starting point.- Do: Name the product type (wallet, landing page, dashboard, marketplace) and who it’s for (beginners, teams, freelancers).
- Do: Mention one or two core features so the AI can propose a realistic scope.
Focus on the product, not the tech
Describe what the product does and for whom. You can add tech only when it’s essential (e.g. “Solana wallet,” “REST API for inventory”).- Do: “A todo app for remote teams with assignees and due dates.”
- Avoid: “A React + Node.js app with PostgreSQL and Redis for todos.”
Keep it short and scannable
One to three sentences are enough. The AI will ask for more in Intent (target users, must-have vs nice-to-have, platform).- Do: 1–3 sentences.
- Avoid: Long paragraphs, bullet lists, or full PRDs in the idea field.
Give a concrete use case when it helps
If the domain is niche, a brief use case steers the analysis.- Do: “A waitlist tool for indie game launches: collect emails, show position, and notify on release.”
- Avoid: “A waitlist tool” with no context.
Idea Format Guidelines
Length
- Recommended: 1–3 sentences (roughly 15–80 words).
- Minimum: One clear sentence (product + at least one feature or user type).
- Maximum: A short paragraph; beyond that, save detail for the Intent answers.
Structure
A strong idea often follows:- Product type — What it is (e.g. wallet, landing page, dashboard, mobile app).
- Target users — Who it’s for (e.g. beginners, remote teams, freelancers).
- 1–2 core features — The main things it does (e.g. send/receive, assignees and due dates, waitlist and notifications).
- Context (optional) — Domain or constraint if it matters (e.g. “for Solana,” “for indie game launches”).
What to include
| Include | Example |
|---|---|
| Product type | “A landing page…”, “A Solana wallet…”, “A todo app…” |
| Users | “…for beginners”, “…for remote teams”, “…for freelancers” |
| 1–2 core features | “…with send/receive and token list”, “…assignees and due dates”, “…pricing and waitlist” |
| Domain when relevant | “for Solana”, “for game launches”, “for B2B SaaS” |
What to avoid in the idea field
- Full feature lists (save for Intent).
- Tech stack details (unless they define the product, e.g. “Solana wallet”).
- User stories, acceptance criteria, or wireframes.
- Multiple unrelated ideas in one submission.
Examples of Good Ideas
Website
- “A landing page for a dev tool with pricing, docs link, and waitlist.”
- “A static marketing site for a design agency: hero, portfolio grid, services, and contact form.”
- “A personal blog with dark mode, RSS, and MDX posts.”
Web Application
- “A todo app for remote teams with assignees, due dates, and list view.”
- “A dashboard for solopreneurs: connect bank, categorize transactions, and export for taxes.”
- “An inventory app for small shops: products, low-stock alerts, and basic reporting.”
Mobile (Android / iOS)
- “A Solana wallet for beginners with simple send/receive and token list.”
- “A habit tracker with streaks, reminders, and simple stats.”
- “A flashcard app for language learning: decks, spaced repetition, and audio.”
Cross-domain
- “A waitlist tool for indie game launches: collect emails, show position, and notify on release.”
- “A booking tool for hair salons: calendar, services, and SMS reminders.”
Common Mistakes to Avoid
1. Too vague
| Avoid | Prefer |
|---|---|
| “An AI app.” | “A chatbot for customer support that suggests answers from a knowledge base.” |
| “A crypto app.” | “A Solana wallet for beginners with send/receive and token list.” |
| “A website.” | “A landing page for a dev tool with pricing, docs link, and waitlist.” |
2. Too many features in the idea
The idea should set direction; Intent is for prioritization. Long feature lists in the idea often dilute focus.| Avoid | Prefer |
|---|---|
| “A todo app with assignees, due dates, labels, recurring tasks, subtasks, Kanban, calendar, sharing, and Slack.” | “A todo app for remote teams with assignees and due dates.” |
3. Leading with tech instead of product
| Avoid | Prefer |
|---|---|
| “A Next.js app with Tailwind and Prisma for a blog.” | “A personal blog with dark mode, RSS, and MDX posts.” |
| “A React Native app with Firebase for a habit tracker.” | “A habit tracker with streaks, reminders, and simple stats.” |
4. Multiple unrelated ideas
One submission = one product. Split if you have more.| Avoid | Prefer |
|---|---|
| “A todo app and a separate expense tracker for the same account.” | Submit twice: one idea for the todo app, one for the expense tracker. |
5. Solution before problem
Describe the product and its value; avoid framing it only as a fix for something unspecific.| Avoid | Prefer |
|---|---|
| “Something to fix how teams lose track of tasks.” | “A todo app for remote teams with assignees and due dates.” |
6. Empty or trivial ideas
The API requires a non-empty idea. Very short or filler text yields weak analysis and questions.| Avoid | Prefer |
|---|---|
| “An app.” | “A habit tracker with streaks, reminders, and simple stats.” |
| “Make something cool.” | Pick a product type, users, and 1–2 features. |
7. PRDs or specs in the idea field
Save structure for Intent and the generated blueprint. The idea is the seed.| Avoid | Prefer |
|---|---|
| Pasting a full PRD, user stories, or acceptance criteria. | 1–3 sentences: product type, users, 1–2 core features. |