Updated August 2026.
A website is never finished on launch day. The organizations that get the most from theirs treat the site as something that improves on a schedule rather than a project that ends. At COLAB, that work happens in iterations: two-week cycles that each produce something complete, reviewed, and usually deployed. The benefit is not speed for its own sake. It is that progress becomes visible every two weeks, direction can change between cycles, and problems surface while they are still small enough to fix cheaply.
What an iteration is
IAn iteration is a short, fixed work cycle that builds on the one before it. At COLAB an iteration runs two weeks and ends with work that is functionally complete, reviewed with the client, and ready to deploy. The goal is progress you can see, not perfection you wait for.
Every iteration moves through the same six steps:
- Deciding which work to take on
- Agreeing on those priorities with the client
- Doing the work, including strategy, design, development, and QA
- Reviewing the result with the client and collecting feedback
- Combining the work with what came before and deploying it if the site is live
- Reviewing how the cycle went and adjusting how we work
This cycle is the Grow phase of our approach, repeated for as long as the relationship lasts. A full redesign usually takes 10 to 12 iterations before First Public Release, our term for launch. For sites already live, most iterations end in a deployment, so improvements reach users within weeks instead of at the end of a year-long plan.
What iterative delivery gives you that a fixed plan does not
Visibility you can act on
A traditional plan asks you to trust a schedule and wait. Iterations replace that with a checkpoint every two weeks where you see actual work, not a status percentage. That rhythm does two things. It lets you measure real progress against the timeline, and it gives you a regular, low-stakes moment to say something is off before it becomes expensive to correct.
This is also where most of the collaboration happens. Two meetings per iteration, one at the start to agree on priorities and one at the end to review the work, keep everyone aligned. Your team stays informed without having to manage the work.
Quality that holds up
Errors compound when they go unexamined for months. Reviewing and testing at the end of every cycle means issues get caught while they affect one component rather than the whole site.
A small example shows how this works. On one engagement, the client was entering final content and dropped a placeholder into a call-to-action link, because the off-site form it needed to point at did not exist yet. Reasonable at the time. But placeholders are invisible once the page looks finished, and that link made it nearly to launch before an iteration review caught it. Two weeks later and it would have been a broken conversion path on a live site, found by a user rather than by us. Short cycles do not prevent that kind of mistake. They shorten the distance between making one and noticing it.
The same applies to how the team works. Each cycle ends with a retrospective, so process problems get addressed in the next two weeks rather than surviving to the end of the engagement.
Room to change your mind
Requirements move. A campaign shifts, a regulation changes, a stakeholder joins with a real concern. Because priorities are set at the start of each iteration rather than locked at the start of the project, a change in direction costs one cycle of replanning instead of a change order and a renegotiated scope.
There is also a practical efficiency here. Parkinson’s Law, from C. Northcote Parkinson’s 1955 essay in The Economist, holds that work expands so as to fill the time available for its completion. Two-week boundaries create natural limits that keep scope honest.
What an iteration looks like in practice
Two examples, both from real COLAB engagements.
A microsite for an event
A client on a long-running engagement needed a microsite for an upcoming event. The brand was established, the work was well defined in the Product Roadmap, and the team had already completed the earlier stages of how we partner with you on a redesign.
| Week 1 | Week 2 | |
|---|---|---|
| Full team | Discuss priorities | Demo homepage |
| Client | Agree on priorities | Provide feedback |
| Product Manager | Add definition to priorities | Organize the backlog |
| Designer | Review brand assets, wireframe homepage | Design homepage |
| Developer | Set up environment | Review homepage design |
| QA Analyst | Build test cases | Review homepage design |
The next iteration added the registration page and a design system. The one after brought final content, full QA, and deployment. The following cycle opened with a celebration and a hotfix for a registration bug found in production, then moved to reviewing analytics and user feedback. After that the microsite went into maintenance mode, and the team returned to other priorities while new issues were triaged as they came in.
Taking over a site someone else built
A new client came to us with a live site built by another agency. We ran a business discovery to understand its purpose, and our developers completed a technical review of the underlying architecture. The issues from both were grouped into a Product Roadmap and ordered into a prioritized backlog.
| Week 1 | Week 2 | |
|---|---|---|
| Full team | Review roadmap priorities | Review infrastructure changes |
| Client | Agree on priorities | Provide demo feedback |
| Product Manager | Present infrastructure plan to IT | Coordinate content freeze, organize the backlog |
| Developer | Begin WebOps migration | Migrate using platform best practices, coordinate deployment with IT |
| QA Analyst | Review upcoming priorities | Full site QA, verify deployment |
Later iterations mixed work types deliberately: a landing page template and CMS component fixes in one cycle, performance improvements and user role updates in the next. That mix is typical. A healthy backlog holds infrastructure, features, and bugs at the same time, and the roadmap decides the balance each cycle. For clients on Proactive Support, we add a quarterly health check covering performance, accessibility, SEO, and security.
Where iterations get hard
The shift in mindset
Continuous improvement asks something different than a one-time overhaul. Clients used to the traditional model often need a few cycles before the rhythm feels natural. Confidence tends to arrive with the first delivered results. On larger engagements we open a COLAB Resource Center so stakeholders can see status without waiting for a meeting.
Sizing the work
Estimating is hardest in the first few iterations, especially on a site we did not build. An unforeseen complication can disrupt a cycle or two, but rarely the whole timeline. Because the team is structured to plan in two-week increments, a bad estimate gets corrected two weeks later instead of compounding for a quarter. Accuracy improves as familiarity grows.
Staying involved
Iterations need your attention twice a cycle, which on a two-week rhythm means roughly weekly. That is a real commitment, and it is the smallest one that works. Over time our Product Managers take on more of the advocacy inside team discussions, which lets your team step back from tactical execution and spend its attention on strategy.
.
Where to start
Iterations are not a methodology to adopt wholesale. They are a way to make sure your website keeps earning its place, two weeks at a time, instead of aging between redesigns until the only option left is another full rebuild.
If your site is live and you are not sure what the next two weeks of work should be, that is the conversation to have first. Let’s talk.
