# Iteration Velocity Canonical: https://gaboesquivel.com/blog/2026-10-iteration-velocity **Published:** 2026-10-02 **Summary:** Previews, gradual rollouts, and small migrations shorten the path from an idea to evidence that it improves the product. **Categories:** Product, Engineering, Artificial Intelligence, Frontend, Institutions Shipping more often is useful when each release teaches you something. A team can deploy all day and still struggle to answer a basic question: did the product get better? Iteration velocity is how quickly a team can turn an idea into a change, learn from the result, and use that evidence to decide what comes next. Guillermo Rauch describes it as speed with direction. That framing matters to me because it connects developer tools to the reason we build software in the first place. ## Give speed somewhere to go In his [Screaming in the Cloud conversation](https://sitc.transistor.fm/episodes/how-vercel-is-improving-the-developer-experience-on-the-front-end-with-guillermo-rauch/transcript), Rauch distinguishes faster infrastructure from a faster learning loop. Reducing build time helps a team deliver changes. Knowing which change to make requires feedback about the product. Imagine a team trying to improve checkout. A faster pipeline helps them publish a new flow sooner. A preview lets colleagues try it before release. A gradual rollout limits the number of people exposed to a mistake. Measurement tells the team whether more customers actually complete their purchases. Each part removes a different obstacle to learning. ![Feedback loop from idea through preview, review, gradual rollout, measurement, and next decision](https://gaboesquivel.com/images/diagrams/2026-10-iteration-velocity.svg) Iteration velocity depends on shortening the full feedback loop, not just generating or deploying code faster. The delivery foundations still matter. In [On Continuous Delivery](https://gaboesquivel.com/blog/2015-07-continuous-delivery), I wrote about keeping the main branch deployable, automating checks, and using feature toggles to release unfinished work without exposing it. Those practices make smaller changes possible. Product feedback gives those changes a direction. Rauch explores this relationship further in his conversation at Vercel's Significance Summit: [Acquired Minisodes: A conversation with Guillermo Rauch](https://www.youtube.com/watch?v=p03mo040vAk) ## Let people review the running product A preview gives a proposed change an address. A designer, product manager, or customer-facing teammate can open it and try the interaction without setting up the repository. That changes what a review can uncover. A screenshot can show the layout, but a running preview lets someone discover that a form loses their input after an error, a mobile keyboard covers the primary action, or a loading state leaves them unsure whether anything happened. For the checkout example, I would ask reviewers to complete a purchase, recover from a declined payment, and return to a partly completed form. The review becomes a discussion about the experience people will have. This is part of [product engineering](https://gaboesquivel.com/blog/2026-09-product-engineering): carrying the intended behavior through to something another person can evaluate. A preview makes that responsibility easier to share. ## Make exposure a deliberate choice A merged change doesn't have to reach everyone at once. A team can begin with a limited audience, watch the result, and decide whether to expand. [Vercel Rolling Releases](https://vercel.com/docs/rolling-releases) applies that idea to deployments by splitting traffic between a new deployment and the previous one. Feature flags apply it to particular behavior within an application. The [Flags SDK](https://flags-sdk.dev) provides a code-based way to work with those flags in Next.js and SvelteKit. The distinction helps when choosing a release strategy. A broad application update may warrant a staged deployment. A new checkout option might be controlled independently with a flag. Either way, the team needs to know which version a person experienced to interpret the results. Before a rollout, I would define what success looks like and what would make us stop. For checkout, that could include completion rate, payment errors, and latency. The observation period and amount of traffic matter too: a handful of purchases won't establish that a small conversion change is real. Rollback also has limits. Reverting a deployment doesn't undo a payment or reverse a database migration. The release plan needs to account for the actions and data changes the new code can produce. ## Modernize in slices you can evaluate The same approach applies to migrations. Instead of replacing an entire application before learning whether the new version works, move a route or capability at a time and keep the existing system available while you evaluate it. Martin Fowler's [Strangler Fig pattern](https://martinfowler.com/bliki/StranglerFigApplication.html) describes gradual replacement of a legacy system. It accepts temporary connections between old and new code so that useful improvements can arrive before the whole migration is complete. At [American Express](https://gaboesquivel.com/project/american-express), my work included moving the frontend from Dojo to jQuery, building card marketing experiences, and wiring A/B testing and analytics. That combination is relevant here: changing the implementation and understanding the user experience are connected engineering concerns. For a migration today, I would choose a slice with a clear boundary and observable behavior. Keep the measurements comparable, check the new path, and use what it teaches you before expanding the migration. ## More generated code needs better feedback Coding agents can increase the volume of changes a team produces. Review, testing, and product feedback need to keep pace with that volume. The [2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) describes AI as an amplifier of the surrounding delivery system. More output can expose weaknesses downstream when testing and feedback are poor. [DORA's delivery metrics](https://dora.dev/guides/dora-metrics) help teams examine throughput and instability together. They measure delivery performance; product outcomes still need their own measures. For an AI feature, I would look at whether people use the generated result, how much they have to correct, and whether they return. A negative rating is a useful starting point, but understanding the reason makes it actionable. An optional follow-up can distinguish a wrong answer from an answer that was accurate but unusable. I would start with one important flow: make it easy to preview, release it gradually where appropriate, and choose a result the team will actually review. That creates a loop small enough to operate and useful enough to repeat. Faster implementation then gives the team more opportunities to improve the product.