new-app-planner

name

new-app-planner

description

Plan a tightly scoped new app from a product idea or from a URL used as inspiration. Use when the user wants Codex to clarify a V1 app concept, constrain scope, define a React/Vite/Firebase architecture, plan Stripe pricing, Resend lifecycle emails, analytics, SEO, legal pages, testing, deployment, and create GitHub issues for the implementation tasks. Also use when the user asks to clone an app in the sense of using its copy, messaging, pricing, or flows as a guide rather than copying it exactly.

New App Planner

Goal

Turn a broad app idea or inspiration URL into a narrow, launchable V1 plan that can be implemented quickly. Favor fewer surfaces, default platform decisions, clear human setup tasks, and GitHub issues that an implementation agent or developer can pick up immediately.

Inputs

Accept either:

• A product description, target audience, and desired outcome.
• A URL for an existing app to use as inspiration for V1 positioning, copy, pricing, flows, and feature shape. Treat this as inspiration only; do not copy protected assets, proprietary UI, private data, or brand identity.

If the user provides a URL, browse or fetch it when tools allow. Extract high-level positioning, CTA pattern, pricing structure, page flow, and onboarding cues. Clearly mark any inferences.

Prerequisites

Before running the planner against a repo, confirm the user has already run:

git init
# set up the GitHub remote
npm create vite@latest webui -- --template react
firebase init

The default React/Vite app directory is webui. When planning files, scripts, routes, build commands, Firebase Hosting public/build output, CI working directories, and docs, account for that subdirectory unless the repo shows a different structure.

If any prerequisite is missing, still help the user understand what is needed, but do not proceed as if GitHub issue creation, React/Vite app files, Firebase config files, or Firebase deployment tasks are ready. Add a prerequisite/human setup task for initializing Git, setting the remote, creating the Vite app at webui, and running firebase init.

Default App Contract

Plan with these defaults unless the user explicitly overrides them:

• Frontend: React app running on Vite.
• App directory: webui by default, created with npm create vite@latest webui -- --template react.
• Hosting and backend: Firebase, using Firebase Hosting and appropriate Firebase products for auth, Firestore, Cloud Functions, Remote Config, A/B Testing, Analytics, and deployment.
• Payments: Stripe, including a simple pricing plan and a pricing page.
• Lifecycle email: Resend for product emails.
• Analytics: Google Analytics baked into the first pass.
• Experimentation: Firebase Remote Config and Firebase A/B Testing baked into the first pass.
• Legal: Terms of Service and Privacy Policy pages included.
• Marketing site: story-driven landing page with snap-to sections: hook and before state hero, stakes and mentor, plan/how it works, after state with social proof and testimonials, resolution CTA.
• SEO: first-class metadata, keywords, canonical URLs, structured data where relevant, sitemap/robots, and preview images for social sharing.
• Sharing: first-pass social sharing affordances and Open Graph/Twitter preview support.
• Docs: maintain developer docs in docs/.
• Code shape: single-responsibility files; no monolith components or utility dumping grounds.
• Testing: plan unit, integration, and end-to-end tests from the outset; use Playwright for E2E.
• Config safety: do not commit Firebase config secrets or environment-specific values. Use a simple firebase.js module that reads config from env vars.
• CI/CD: deploy Firebase on merge to main.

Workflow

1. Clarify the product before planning. Ask only the questions needed to reduce scope and design ambiguity. Prefer 5-8 questions at most. If the user gives enough detail, proceed with explicit assumptions instead of blocking.

2. Constrain the V1 surface. Define the smallest useful product: one primary user, one core job, one activation path, one paid conversion path, one admin/support path if required. Push nice-to-have features into "Later".

3. Produce the design doc. Read references/design-doc-template.md before writing the design doc. Fill every section. Make tradeoffs concrete and call out assumptions.

4. Produce the implementation issue plan. Read references/github-issues.md before creating or drafting issues. Group tasks so each issue is independently implementable and testable. Separate human setup tasks from code tasks.

5. Create GitHub issues when a GitHub tool is available and the user has a repo context. First confirm Git has been initialized, a remote exists, webui exists from npm create vite@latest webui -- --template react, and firebase init has been run. Use labels if supported: p0, p1, p2, planning, frontend, firebase, stripe, resend, analytics, seo, legal, testing, ci, human-task. If GitHub tools are unavailable, output issue titles and bodies in a copy-ready format.

Clarifying Questions

When a URL is provided, derive as much as possible from the site before asking. Infer audience, positioning, core workflow, differentiation, pricing cues, trust signals, and page flow from the URL, then ask only about gaps that materially change V1 scope. Clearly mark inferred answers.

Data requirements are produced by the planned app architecture and integrations; do not ask the user to define data collection unless the app idea involves unusual, sensitive, regulated, or ambiguous data. Launch constraints are a byproduct of the setup and issue plan; derive them from required Firebase, Stripe, Resend, analytics, DNS, env, legal, and asset tasks.

Ask concise questions across these areas only when not inferable:

• Audience: Who is the primary buyer/user and what painful before-state do they have?
• Core workflow: What is the one action the app must help them complete?
• Differentiation: Why will this be meaningfully better or simpler than alternatives?
• Monetization: Free trial, freemium, one paid plan, or tiered pricing?
• Trust: What proof, testimonials, metrics, or case studies can be used now?
• Inspiration URL: Which parts should guide V1: messaging, pricing, flow, layout, or feature set?

Avoid asking questions whose answers can be reasonably derived from the URL, the app defaults, or the required setup tasks. Prefer assumptions over interruption when the decision is reversible.

Scope Rules

Prefer a narrow V1 even if the prompt is ambitious. Explicitly reject or defer:

• Multi-role dashboards unless required for the core paid path.
• Complex enterprise admin, SSO, teams, permissions, or billing seats unless the product cannot work without them.
• Custom CMS, blog engines, or community features unless the app's core job depends on them.
• Multiple pricing tiers unless pricing clarity demands them.
• Deep integrations beyond Firebase, Stripe, Resend, GA, and GitHub Actions.

Output Requirements

Always include:

• Clarifying questions or assumptions.
• A concise V1 scope and a "Later" list.
• A complete design doc using the reference template.
• Human setup tasks, especially Firebase project creation, Stripe products/prices/webhooks, Resend domain/API key, GA property, env vars, and secrets.
• GitHub issue plan or created issue links.
• Testing plan covering unit, integration, and Playwright E2E.
• Documentation plan for docs/.

Do not output implementation code unless the user asks to move from planning into implementation.