Project summary
On this page
Project summary
An AI-analysed overview of your whole project, generated from the description you gave when you created it — the foundation every later step builds on. · Recommended
The project summary is the first thing VibeMap produces, and it feeds everything downstream: personas, features, user stories, schema and the business case all read from it. Review it before you go further — a few minutes here saves rework everywhere else. It's the opening step of the Research phase.
How it's generated
When you create a project and submit a description, VibeMap analyses your input and drafts a structured specification. It doesn't just restate what you wrote — it interprets, expands and organises it:
- Deconstructs your prompt — pulls out business goals, technical requirements and constraints.
- Applies domain context — reads your idea through industry-specific knowledge.
- Drafts a structured spec — organises everything into the sections below.
💡 Tip: If you started your project through your IDE over MCP rather than in the app, the summary is populated by your coding agent's first sync instead of the in-app analysis. Until that sync lands you'll see an "awaiting sync" card here — see Codebase sync & code map.
What the summary contains
The page is organised into sections, each independently editable:
| Section | What it holds |
|---|---|
| Business overview | The core problem, scope and value proposition — your project's north star. |
| Functional scope | A high-level map of the feature areas the project will need. |
| Goals & metrics | Measurable objectives and KPIs that define success. |
| Risks & dependencies | Blockers, technical challenges and assumptions surfaced early. |
| Technical architecture | Suggested stack, architectural approach and key integrations. |
| Scope & future | What's in the MVP versus what's parked for later. |
| Decisions | A read-only log of the choices you and the guided agent locked in. |
The Decisions log
If you use the guided agent, a Decisions section appears at the bottom of the summary. It's a read-only record of choices captured at three points — answered pre-flight interview questions, resolved plan proposals, and what-if outcomes — each tagged with its source. It stays hidden until there's at least one decision to show, so pre-guided projects see no change. See Interviews & decisions.
Reviewing and editing
The summary shapes every later generation, so accuracy matters. As you read, ask:
- Does the business overview capture your core vision?
- Are the target segments correct and complete?
- Do the technical recommendations match your team's skills and preferences?
- Are there missing risks you should add?
Click the edit control on any section to refine it inline. Common edits: narrowing scope to MVP-critical work, correcting a technical assumption (e.g. pinning a required stack), or adding business context the AI couldn't infer. You can also download the summary from the page header for sharing.
⚠️ Watch out: Regenerating the summary re-analyses your prompt and replaces the whole thing, including any manual edits. Copy anything hand-written you want to keep before you regenerate.
How the summary connects downstream
| Later step | What it reads from the summary |
|---|---|
| Personas | Target audience, user segments |
| Features | Functional scope, goals, technical context |
| User stories | Goals, success metrics, persona context |
| Business case | Business overview / positioning |
| Schema | Technical context, integration requirements |
Get the summary right and every downstream generation starts from a strong, accurate base.
⚡ Power-user hints
- Front-load the detail. The summary is only as good as your description. Include budget, timeline, team size and stack preferences up front and the AI produces a far more realistic spec — see Writing effective prompts.
- Re-run after big pivots, not small tweaks. Because everything downstream reads the summary, regenerate it deliberately after a real change of direction, then refresh the business case so the framing stays in sync.
- Edit surgically. For a one-line correction, edit the single section inline rather than regenerating the whole summary and losing your other edits.
↔ The traditional way
Traditionally a product manager or business analyst turns a founder's brief and a round of stakeholder interviews into a written project brief or one-pager — usually a day or two of drafting, and a document that goes stale the moment the idea moves. VibeMap produces the same structured brief in seconds, keeps it living (regenerate on a pivot), and — crucially — makes it machine-readable so the rest of the pipeline can build on it directly instead of a human re-keying it into the next tool.
What's next
- Validate the idea before you spec it: Business case.
- Or jump straight into defining users: Generating personas.