Back to blog
EngineeringAugust 20266 min read

How we ship a production web app in four weeks

Our week-by-week delivery cadence: discovery, design system, build sprints and launch hardening — and what we cut to keep the timeline honest.

Why four weeks?

Most early-stage products die not from bad code, but from too much planning and too little shipping. We designed our four-week cadence to force clarity: if a feature cannot be scoped, built and validated inside a month, it is either too vague or too large.

The goal is not speed for its own sake. It is a working product that real users can click, critique and pay for — fast enough that the founders still remember why they started.

Week 1: Discovery that hurts (in a good way)

We start with a ruthless prioritisation exercise. We interview stakeholders, map the user journey, and identify the one action that makes the product valuable. Everything else goes into a ‘later’ bucket with a date attached.

By Friday of week one we have a one-pager: the problem, the target user, the core loop, and the success metric. No Figma files yet. No code. Just a shared decision that everyone can argue with.

Week 2: Design system before screens

We build a tiny design system first — typography, spacing, colour tokens, button states and form patterns. Once those exist, every screen becomes faster to design and cheaper to change.

This week produces a clickable prototype of the critical path only. We test it with three to five users and rewrite the flow based on where they get stuck.

Week 3: The build sprint

Engineering starts in parallel during week two, scaffolding the stack, auth, database and deployment. By week three the team is building features against real components.

We keep pull requests small, deploy to staging daily, and measure progress by working demos, not task counts. If a feature feels risky, we ship a thinner version first and expand it in the next cycle.

Week 4: Hardening and handoff

The final week is about polish, performance and resilience. We run Lighthouse, fix accessibility issues, test on real devices, and write just enough documentation that the client can operate the product without us.

Then we launch. Not a big-bang reveal — a quiet release to a small group, with analytics in place and a list of learnings ready for the next four-week cycle.

What we cut

  • Custom admin dashboards in favour of direct database tools or off-the-shelf solutions.
  • Multi-language support and dark mode unless they are core to the value proposition.
  • Perfect copywriting; we ship clear copy and refine it with user feedback.
  • Any feature that does not directly support the core user action.
AT

AB Technologies Team

Published August 2026

Let's build something worth remembering

Bring us the product problem. We will help turn it into a clear path from first brief to shipped experience.