Iterative Development: Features, Sprints, and Shipping

Building Something Real, Not Just a Demo

A demo is a single session. A real product is built over days or weeks of iterative sessions, each adding to what came before. Bolt supports this — but it requires deliberate workflow design.

This lesson covers the workflow patterns that keep a multi-session Bolt project coherent, progressively shippable, and maintainable.

The Feature-Spec-Build Cycle

Step 1: Write the Spec (in Claude or Kiro)

Before prompting Bolt for a new feature, write a kiro spec file that describes it:

# Feature: Task Filtering

## Requirements
- User can filter tasks by status: All, Active, Complete
- User can filter tasks by priority: All, Low, Medium, High
- Filters are combinable (e.g., Active + High Priority)
- Filter state persists across page refreshes via URL params
- Filtered results show count of matching tasks

## Design
- Filter controls appear above the task list as a horizontal bar
- Status filters: 3 segmented buttons
- Priority filters: 4 pill buttons that toggle independently
- Active filters are visually highlighted (blue-600)
- "Clear filters" text link appears when any filter is active

## Out of Scope
- Saved filter sets
- Server-side filtering (client-side only for now)

Step 2: Feed the Spec to Bolt

Read .kiro/specs/task-filtering.md and implement the feature as specified.
Follow all conventions in .kiro/steering/tech.md.
After implementation, show me what files were created or modified.

Step 3: Verify in Preview

Test every requirement from the spec:

• Does All/Active/Complete filtering work?
• Do priority filters toggle independently?
• Are filters combinable?
• Does the URL update?
• Does count update?

Step 4: Commit or Export

When the feature is verified, export or commit before moving to the next feature. This gives you a known-good checkpoint.

Managing Multiple Sessions

At the start of every new Bolt session on an existing project:

This is a continuing session on the [project name] project.
Read .kiro/steering/product.md, tech.md, and structure.md for full context.
The current working state: [brief description of what's been built so far]
Today's goal: [what you're building in this session]

This 30-second setup prevents Bolt from making decisions that contradict prior work.

The Sprint Model for Bolt Development

Structure work as 1–3 day sprints, each with a clear definition of done:

Sprint 1: Authentication foundation
- Login and registration screens
- Supabase auth integration
- Protected route wrapper
- Basic logged-in user state in navbar

Sprint 2: Core data model
- Projects CRUD
- Tasks CRUD within projects
- Supabase schema + RLS policies

Sprint 3: Primary UI
- Dashboard with project list
- Project detail with task list
- Task filtering and sorting

Define each sprint in a kiro spec. Build sprint by sprint. Export after each sprint succeeds.

Handling Scope Creep in Bolt

Bolt will sometimes "helpfully" add features you didn't ask for — extra UI elements, additional state, new dependencies. Train yourself to notice this:

After every significant change, scan the diff for:

• New npm packages you didn't request
• New components or files you didn't specify
• New UI elements not in the spec

If Bolt added something you didn't ask for:

In the last change you added [describe the addition]. Remove it.
It's out of scope for this feature. Only the changes described in
.kiro/specs/[spec-name].md should be included.

The Export and Version Control Habit

Bolt projects should be exported and stored in version control at key milestones:

• After each sprint completes
• Before any major refactor
• After a significant debugging session resolves

This gives you a recovery path that doesn't depend on Bolt's internal history.

Key Takeaways

• Write kiro spec files before prompting Bolt for new features — it creates a clear, auditable record
• Start every session with a context re-establishment prompt loading steering files
• Sprint structure keeps work organized and verifiable between sessions
• Scan Bolt's changes for scope creep — remove unrequested additions promptly

---

Try It Yourself: For your next Bolt feature, write a full kiro spec file first (in Claude if helpful). Then feed the spec to Bolt with: "Implement the spec in .kiro/specs/[name].md." After implementation, verify every requirement from the spec against the live preview. Note which requirements Bolt satisfied perfectly and which needed follow-up prompts.