Clients see the kickoff call and the launch announcement. Agencies live in everything between: slipping timelines, backed-up dev queues, content that arrives in a shape that doesn’t fit the design, and projects that quietly run weeks longer than planned.
This post walks through the phases of a website build as they actually run inside an agency, and looks at what changes when the build is component-based rather than custom-coded from scratch. The shape of the project changes. So does where the hours go.
The build everyone knows
Most agency website projects follow the same five-phase arc: discovery, design, build, population and QA, launch. Anyone who has run more than a handful of projects can recite it. The phases feel natural because they have been the default for so long.
They were not designed. They accumulated through years of workarounds, handoffs, and inherited assumptions from a fully custom-code era. Each phase carries those assumptions forward, and they are the reason so much time disappears into rework, dev queues, and content-fit problems that nobody planned for.
Agencies did not choose this workflow because it produces better work. They inherited it.
The reframe is worth holding through the rest of this post: a website is not a one-time output. It is the start of a system that will keep changing for years. When the build phase is set up to produce a finished artifact, late-stage changes feel like a risk. When the build phase is set up to produce a living system, late-stage changes are routine. That shift changes what each phase is actually for.
1. Discovery and scoping
Discovery is where the project gets shaped, and where most of the bad assumptions get baked in. Scope is written against a custom build, so estimates carry padding for unknowns the team has not even seen yet. Will the dev bench be free? Will the client want a layout the system has not produced before? Will the homepage hero have one variant or four? Nobody knows, so the number goes up.
The classic discovery dilemma kicks in here. Wireframe and design without final content to keep momentum, and pay for it later in rework when the copy arrives and does not fit. Or wait for content first and watch the project stall while clients try to write copy for a layout they cannot picture. Most agencies have lived both versions and neither one feels right.
A component-based build changes the math. The library is the constraint, so scoping happens against known assemblies rather than invented ones. The padding does not disappear, it just moves. Less of it covers “what if dev can’t get to this.” Most of it covers the parts of the brief that genuinely go beyond the system, which is where the agency’s real value lives anyway.
2. Design
Design in a traditional build happens in Figma, often weeks before anyone on the build team weighs in. Designers produce screens. The build team receives them later and translates as best they can within the budget. The translation gap is where late-stage friction starts. A layout that took an hour to design might take a day to build. Nobody planned for that gap because the design phase was running in its own track.
The other failure mode is the opposite. Designers, knowing the build team will push back on anything ambitious, default to safe patterns they have seen built before. Creative work calcifies into recognizable shapes. The output is functional. It is also forgettable.
Component-based design closes the gap. Designers work from the same library the build team uses, so what gets designed is what gets built. The library becomes the shared vocabulary. Creative energy redirects from reinventing card grids and basic layouts toward the parts of the brand and user journey that actually need it. Hero treatments, signature interactions, the few moments on the site that have to feel specific to this client and nobody else.
3. Build
| Before | After |
|---|---|
In a traditional WordPress build, developers translate Figma into code page by page. Custom CSS, theme files, careful coordination of every variant. The longer the project runs, the more fragile it becomes. By the time QA starts, the codebase has accumulated enough one-off decisions that small changes carry real risk.
In an agency context, we have measured what this actually costs. A typical mid-sized site build used to take us 80 to 120 hours of development time, with QA adding another 40 to 100 hours on top. Two hundred-plus hours on a single project was normal.
A component-based build looks different. The same site build runs 40 to 50 hours. QA runs 20 to 25. Same scope, same brand quality, same client expectations. The work that used to happen by writing custom code now happens by assembling pre-tested, accessible components and extending the genuinely custom parts where they belong. Pages are not built. They are composed.
The hours do not vanish. They move. Less time in repetitive build work means more time in the parts of the project that actually move the needle: strategy, content fit, accessibility, the custom flourishes that make the site feel specific to the brand.
4. Population and QA
Population is the phase agencies most often underestimate. Final copy arrives, images get sized, microcopy gets adjusted, the site fills out. In a traditional build, this phase exposes every gap between the design and the content. Copy that was estimated at fifty words runs to a hundred. A section designed for three columns gets four items. Photography that looked clean in the moodboard fights with the layout in production.
Each of those gaps becomes a developer ticket. Spacing tweaks, layout adjustments, mobile fixes. The dev bench becomes the bottleneck for work that has nothing to do with development.
QA in this model is a developer-dependent process by default. If something looks wrong, only the dev can fix it. The dev queue stretches. The project slips.
A component-based workflow changes who can do what. Population happens visually, in the editor, by the people closest to the content. PMs, writers, and designers adjust sections in place. QA accelerates because more people can fix more things without writing a ticket. The dev bench is freed up for the actual development work, which is usually the part of the project most at risk of running long.
5. Launch and beyond
In the inherited model, launch is the finish line. The site ships, the team rolls onto the next project, and any post-launch change gets scoped as a new mini-project. The client has limited ability to evolve the site on their own without breaking it. Six months later, when a campaign needs a new landing page, the agency gets a call and a small budget. The cycle repeats.
A component-based launch is the start of an evolving system. Late-stage changes are no longer high-risk events that require careful regression testing. Clients can update sections in the editor without breaking the layout. The agency’s role shifts from rebuild-on-request to ongoing strategic partner. The site grows with the business instead of falling further behind it until the next redesign.
The build does not break under change, it absorbs it.
Where the hours actually go now
Saved time is the wrong measurement. Where the recovered time actually goes is the one that matters. If the answer is more projects with the same margin, that is fine. If the answer is better strategy, sharper design, tighter content fit, and post-launch iteration, that is the version that compounds.
The shape of a website project was inherited from an era when every site had to be built from scratch in code. That era is over. Component-based building gives agencies the chance to redesign the shape itself, and to spend the recovered hours on the work clients actually remember.
See the shift in practice
If you want to see what a component-based build looks like end to end, the Refoundry sandbox is the fastest way to do it without committing to anything. Spin one up, assemble a page, and see how much of the usual build friction simply never appears.
For agencies thinking about how this fits into a broader operational shift, the agency maturity model walks through the stages of agency growth and where low-code adoption fits in.
