Iterative Development

Building software in small, repeated cycles — each cycle produces a working increment, validates assumptions, and informs the next cycle.

---

What is it?

Iterative development is a way of building software where you don’t try to create the entire product at once. Instead, you work in short cycles. Each cycle has a clear, small goal. You plan it, build it, test it, learn from it, and then start the next cycle with better knowledge than you had before.

This stands in contrast to the “waterfall” model, where you complete one entire phase (all the design, then all the coding, then all the testing) before moving to the next. Waterfall sounds orderly, but it means you don’t discover problems until very late — when they’re expensive and painful to fix.

The key insight behind iterative development is that you can’t know everything upfront. Requirements change, assumptions turn out to be wrong, and users want things you didn’t anticipate. Short cycles let you course-correct continuously instead of discovering you’ve built the wrong thing after months of work.

Every modern software methodology — Agile, Scrum, Lean, XP — is built on iterative principles. The differences are in the details (how long is a cycle, what ceremonies surround it, how strictly do you plan). The core idea is always the same: build a little, learn a lot, repeat.

In plain terms

Iterative development is like sculpting from clay instead of carving from marble. With marble, every cut is permanent — you’d better get it right the first time. With clay, you rough out a shape, step back, evaluate, adjust, and refine. Each pass gets closer to the final form, and mistakes are cheap to fix.

---

At a glance

The iterative cycle (click to expand)

graph LR
    P[Plan] -->|set a small goal| B[Build]
    B -->|produce working software| T[Test]
    T -->|verify it works| L[Learn]
    L -->|adjust understanding| P
    style L fill:#4a9ede,color:#fff

Key: Each box is a phase within one iteration. The arrow from Learn back to Plan is the crucial part — what you learned changes what you plan next. The cycle repeats until the product is complete. Each full loop typically takes 1-4 weeks.

---

How does it work?

Every iteration follows the same four-phase pattern. The magic is in the repetition — each loop builds on what the previous one taught you.

1. Plan

Define a small, concrete goal for this cycle. Not “build the app” but “build one feature end-to-end” or “prove the database can talk to the frontend.” The goal should be achievable in days, not months.

Good iteration goals are:

• Testable — you can verify whether you achieved them
• Self-contained — they produce something that works on its own
• Valuable — they teach you something or deliver something useful

Think of it like...

A road trip where you plan one leg at a time. You know the final destination, but you plan the next stop, not every stop. If traffic or weather changes, you adjust the route — but you’re always making progress.

---

2. Build

Execute the plan. In software, this means writing code, creating designs, setting up infrastructure — whatever the goal requires. The key constraint: build only what the plan calls for. Resist the urge to add extras.

Example (click to expand)

Your goal for this iteration is “display a list of items fetched from a database.” You build:

• A database table with sample data
• An API endpoint that queries the table
• A frontend page that calls the endpoint and displays the list

You do NOT build: sorting, filtering, pagination, styling, user authentication. Those are future iterations.

---

3. Test

Verify that what you built actually works. This means:

• Running the software and checking it does what you intended
• Writing automated tests that confirm the behaviour
• Showing it to someone else (a user, a teammate, a stakeholder)

Testing in each iteration catches problems while they’re small. A bug found in the same week it was written takes minutes to fix. A bug found three months later can take days.

---

4. Learn

The most underrated phase. After testing, ask:

• What assumptions turned out to be wrong?
• What was harder than expected? What was easier?
• What should change in the next plan?

This is where iterative development pays off. Each cycle doesn’t just produce software — it produces knowledge that makes the next cycle better.

Concept to explore

See feedback-loops for how the learn phase connects to broader systems thinking.

---

How strategies fit within iterative development

Different strategies address different parts of the iterative process:

Strategy	What it solves	When to use it
walking-skeleton	”Does the architecture work at all?”	First iteration of a new project
vertical-slices	”How do we scope each iteration?”	Every iteration after the skeleton
spec-driven-development	”How do we define what ‘done’ means?”	When precision matters
vibe-coding	”How do we explore quickly?”	Early exploration, prototyping

Concept to explore

See walking-skeleton for how to structure your very first iteration — the one that proves the whole architecture works.

---

Why do we use it?

Key reasons

1. Early problem discovery. Each cycle reveals problems while they’re still small and cheap to fix. Building everything at once means discovering integration failures, wrong assumptions, and missing requirements at the end — when fixing them is expensive.

2. Continuous validation. Each iteration produces working software that can be shown to users, stakeholders, or yourself. You get real feedback on real software, not theoretical feedback on documents.

3. Managed uncertainty. Software projects are inherently uncertain. You don’t know the final requirements, the technical challenges, or the user’s real needs. Short cycles let you adapt as understanding grows, rather than committing to a plan made in ignorance.

4. Steady progress. Instead of months of invisible work followed by a big reveal, iterative development produces visible progress every cycle. This builds confidence and maintains momentum.

---

When do we use it?

• When building any software product beyond a single-use script
• When requirements are unclear or evolving (which is most of the time)
• When working with AI coding assistants — each iteration is a natural unit of work for a focused session
• When learning a new technology — iterations let you build understanding incrementally
• When the cost of being wrong is high — short cycles limit how far you can drift before correcting

Rule of thumb

If the project will take more than a few days, iterate. The only time not to iterate is when you fully understand the problem, the solution, and the technology — which almost never happens.

---

How can I think about it?

The sculptor's studio

A sculptor working in clay doesn’t start with the left earlobe and finish with the right shoe. They rough out the whole form first — a vague human shape. Then they refine the proportions. Then the major features. Then the details. Each pass over the whole sculpture improves it.

• Roughing out = walking skeleton (prove the overall shape works)
• Proportions = vertical slices (get each major part working end-to-end)
• Features = adding functionality within each slice
• Details = polish, optimisation, edge cases

At every stage, the sculpture “works” — it’s recognisable and complete at its current level of detail.

The newspaper edition

A daily newspaper is iterative by nature. Every day, the team produces a complete edition — a working product that goes to readers. Tomorrow’s edition doesn’t start from scratch; it builds on today’s. Breaking news changes the plan. Reader feedback shapes future coverage.

• Each edition = one iteration (complete and shippable)
• The editorial meeting = the Plan phase (what goes in tomorrow?)
• Writing and editing = the Build phase
• Proofreading = the Test phase
• Readership data = the Learn phase (what resonated? what didn’t?)

No newspaper waits until they have a year of articles before publishing. Neither should software.

---

Concepts to explore next

Concept	What it covers	Status
walking-skeleton	The first iteration: proving the architecture works end-to-end	complete
vertical-slices	Scoping each iteration as a complete feature across all layers	complete
spec-driven-development	Using written specifications to define iteration goals precisely	complete
vibe-coding	Rapid, AI-assisted exploration — useful for early iterations	complete
agile-methodology	The broader family of iterative methodologies (Scrum, XP, Lean)	stub
feedback-loops	How learning from each cycle connects to systems thinking	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

---

Check your understanding

Test yourself (click to expand)

1. Explain why iterative development discovers problems earlier than a waterfall approach. What specifically changes about when problems surface?
2. Name the four phases of an iterative cycle and describe what each one produces.
3. Distinguish between iterative development and “just winging it.” What structure does iterative development add that unstructured work lacks?
4. Interpret this scenario: a team builds their entire database schema in month one, all API endpoints in month two, and the frontend in month three. They discover in month three that the API returns data in a format the frontend can’t use. How would iterative development have prevented this?
5. Connect iterative development to the concept of a walking-skeleton. Why is the skeleton the ideal first iteration?

---

Where this concept fits

Position in the knowledge graph

graph TD
    SD[Software Development] --> ID[Iterative Development]
    SD --> SA[Software Architecture]
    ID --> WS[Walking Skeleton]
    ID --> VS[Vertical Slices]
    ID --> SDD[Spec-Driven Development]
    ID --> VC[Vibe Coding]
    style ID fill:#4a9ede,color:#fff

Related concepts:

• prd — defines the overall project scope; iterations deliver it piece by piece
• technical-specification — formalises what each iteration should achieve
• agile-methodology — the broader family of practices built on iterative principles

---

Further reading

Resources

• Iterative Development: Model, Benefits & Steps (Ramotion) — Clear walkthrough of the iterative model with practical steps
• What Is Iterative Development? A Practical Guide (RapidNative) — Jargon-free introduction for product teams
• The Iterative Process: 5-Step Guide + Examples (Shopify) — Beginner-friendly guide with real-world examples
• Agile Manifesto — The original 2001 manifesto that established iterative principles
• Iterative Feature Development with Small, Concrete Steps (Zenn) — How pseudocode, walking skeletons, and specs support iterative work