Webapp Planner

Create delivery plans as small, implementation-ready specifications.

Use This Workflow

1. •Capture product intent.
2. •Define delivery constraints.
3. •Generate an incremental spec ladder.
4. •Expand each step into build-ready specification cards.
5. •Validate coverage of technical foundations and operations.

1) Capture Product Intent

Extract:

• •App goal and target users.
• •Primary jobs-to-be-done.
• •Success criteria for MVP.
• •Explicit non-goals for the first release.

If domain details are missing, state assumptions and continue.

2) Define Delivery Constraints

Confirm or assume:

• •Runtime and package manager.
• •Frontend stack.
• •Backend/API shape.
• •Data storage and migration tooling.
• •Deployment target.

When the user does not provide a stack, use the baseline in references/stack-baseline.md.

3) Generate Incremental Spec Ladder

Create 7 to 12 specs ordered by customer value and risk burn-down.

For each spec:

• •Ship visible user value.
• •Include any enabling technical work required for that value.
• •Keep the slice small enough for one short iteration.

Always include explicit phases for:

• •Project bootstrap and CI.
• •Data platform setup and migrations.
• •Authentication/authorization when multi-user data exists.
• •Core domain CRUD or equivalent primary workflow.
• •Quality gates (tests, lint, format, typecheck).
• •Observability and production hardening.

4) Expand Into Spec Cards

For each step, output one spec card using references/spec-card-template.md.

Keep each card implementation-ready:

• •User-facing outcome first.
• •Concrete technical scope second.
• •Acceptance criteria written as verifiable outcomes.
• •Out-of-scope list to prevent scope creep.

5) Validate Plan Completeness

Run this checklist before finalizing:

• •Every spec contains customer value, not only infrastructure.
• •Database schema changes have migration tasks.
• •Routing/navigation impact is captured.
• •Authorization rules are explicit where needed.
• •Telemetry and error handling are included.
• •Test strategy exists per slice.
• •Deployment and rollback considerations are present.

If any item is missing, patch the relevant spec card before returning.

Output Rules

• •Start with a short assumptions block.
• •Present the spec ladder as numbered items.
• •Use concise wording; avoid vague tasks.
• •Prefer verbs such as "Implement", "Add", "Validate", "Deploy".
• •Do not output generic backlog themes without acceptance criteria.

Optional Variants

• •For greenfield apps, start from bootstrap.
• •For existing apps, add "Current State" assumptions and begin at the first missing capability.
• •For monolith-first teams, keep one deployable service.
• •For service-split teams, defer service extraction until the core workflow is stable.

References

• •Baseline stack defaults: references/stack-baseline.md
• •Card format: references/spec-card-template.md