July 16, 2026
Clients like to know what they’re actually paying for before the first invoice. Here’s the process I walk every website project through.
1. Discovery. Goals, audience, competitors, and content inventory. No design happens yet, this phase is about understanding the problem.
2. Wireframes. Low-fidelity layouts focused purely on structure and hierarchy, deliberately ugly so feedback stays on layout instead of color choices.
3. Visual design. Once structure is approved, the real design system comes in, typography, color, imagery, applied to the approved wireframes.
4. Build. Development happens against the approved design, with regular checkpoints rather than one big reveal at the end.
5. QA and launch. Cross-browser and cross-device testing, performance checks, and a staged rollout rather than flipping a switch on a Friday afternoon.
Skipping steps to save time almost always costs more time later in revisions. The order exists for a reason.
Skipping wireframes for visual design feels faster and rarely is. Feedback on color and imagery gets tangled up with feedback on structure, so a client ends up re-approving the same layout decision three times under three different visual skins, which costs more hours than the wireframe step ever would have.
Discovery prevents scope creep before it starts. A content inventory done properly surfaces pages, forms, and integrations nobody mentioned in the kickoff call. Finding that during discovery costs a conversation. Finding it during build costs a change order.
QA is not the same as “looks right on my laptop.” Real cross-browser and cross-device testing, not just Chrome on a MacBook, catches the layout breaks that otherwise show up as a client’s first bug report after launch. The web.dev learning path is a solid, free reference for what a thorough pre-launch QA pass should actually cover.
Staged rollouts apply to websites too, not just apps. Pointing a new build at a staging subdomain, testing forms and payment flows for real, then cutting DNS over, avoids the classic Friday-afternoon launch where a broken contact form goes unnoticed all weekend.
This process isn’t rigid for its own sake, every step exists because skipping it has cost me or a client real time on a past project. If you want to see the process applied to templates you can start from directly, my ready-made website templates already went through every stage above.
On a fixed-timeline project, we compressed wireframes and visual design into a single combined step to save a week. The client, seeing polished visuals for the first time at the same moment as the layout, kept requesting structural changes framed as “just a color thing”, when the actual issue was that the page hierarchy itself didn’t match how they thought about their business. Untangling structural feedback from visual feedback after the fact took longer than the week we’d saved by combining the steps.
The fix wasn’t more process for its own sake, it was making sure feedback on structure happens before a client has anything visually polished to react to. A deliberately plain, grayscale wireframe removes the temptation to comment on color and font choices before the layout itself has been agreed on.
Every step in this process exists because skipping it moved a cost later in the project, where it was more expensive to fix, not because the process is sacred on its own.
Not every project has the budget or timeline for a full five-stage process run at full depth, and forcing it onto a small project can waste money as surely as skipping it wastes quality on a large one. For a smaller site, I compress discovery and wireframing into a single working session rather than eliminating either step outright, and I combine QA into the build phase as a continuous check rather than a separate final stage. The stages still all happen, they just happen at a scale and pace that matches the actual size of the project, rather than being skipped entirely because the full version feels like overkill.
Clients respond well to seeing this flexibility explained upfront, rather than discovering it as the project unfolds. A simple line in the proposal, “given the scope, discovery and wireframing will happen together in one working session instead of two separate phases”, sets the right expectation and prevents a client from wondering later why a step they read about seemed to be missing. Transparency about which stages are compressed, and why, protects trust just as much as the process itself protects quality.
The five stages are a framework for thinking clearly about a project, not a rigid contract that has to be honored identically on every single engagement regardless of size.
Clients who understand why each stage exists tend to trust the timeline more, not less, even when a compressed version means a shorter overall schedule. Transparency about the process is often what a nervous first-time client is actually looking for, more than speed itself.
The process exists to protect the outcome, not to slow it down, and a client who understands that distinction rarely pushes back on it.
A defined process is ultimately a promise to a client about what happens next at every stage of a project they cannot fully evaluate themselves. Honoring that promise, even in a compressed form for smaller budgets, is what separates a professional engagement from an improvised one, regardless of how talented the person doing the improvising happens to be.
That honesty about scope is worth more to most clients than a longer feature list.
A client who has seen the reasoning behind every stage tends to become an easier client to work with on the next project too, because the relationship has shifted from managing expectations to genuinely collaborating on the outcome.
Process, done well, is invisible to the client except in the results, and that is exactly how it should feel from their side of the table.
Good process quietly earns the trust that follow-on work depends on.
That is worth remembering on every single project going forward.