Business goal. Research. Planning. Content. Design. Development. Testing. SEO. Launch. Measure. Improve.
That is the sequence I work through, and a version of it appears on nearly every agency site on the internet. Which makes it close to useless as a differentiator — everybody lists the steps, because the steps are not controversial.
The interesting question is not what the steps are. It is what happens to them when the project is three weeks behind and the launch date has not moved.
Because at that point the workflow stops being a plan and becomes a set of pressure valves. Some steps compress harmlessly. Some compress and take the outcome with them. Knowing which is which is most of what experience buys you.
Step one absorbs pressure early and quietly
Business goal is the step that gets nodded through. Everyone agrees the site should “generate more leads” or “make it easier to order,” the note gets written down, and the project moves on.
The failure is not that the goal is skipped. It is that it is never made specific enough to decide anything. A goal is doing its job when it settles arguments later — when someone asks whether the homepage should lead with the product range or the ordering process, and the answer is already implied.
The test I apply: can this goal resolve a disagreement I have not had yet? “More leads” cannot. “Make it possible for an existing wholesale customer to reorder without calling” can — it tells you what the homepage is for, what the navigation prioritises, and what the site does not need.
Time spent here is invisible on a timeline and shows up as decisiveness in every later stage. Time not spent here reappears as revision rounds that feel like taste disputes but are actually unresolved strategy.
Step four is where schedules actually break
Content is the step that ends most timelines, and it is almost never the step people blame.
The pattern is consistent: design and development proceed on placeholder text, everything looks fine, and the project waits. Not for a week — for as long as it takes a busy business owner to write forty product descriptions, source photography, and find their own logo files. Meanwhile the build cannot be finalised, because real content changes layouts.
Two things reduce this, and neither is chasing.
Ask for content in the smallest possible units, with examples. “Send me the About page copy” produces nothing for three weeks. “Send me three sentences on why you started the business, and the year” produces something by Friday. Assemble the page yourself from the pieces.
Build with real content from the first layout, even if it is only partial. A design that has never met real copy is a design that will change when it does. Working with whatever content exists, however incomplete, moves the discovery of layout problems forward to when they are cheap.
There is also an honest version of the conversation that helps more than any technique: telling the client, at the start, that content is the most likely cause of delay and that the launch date depends on it more than on anything I do. Said in week one it is planning. Said in week six it sounds like an excuse.
Steps ten and eleven are where the value leaks
Measure and Improve are the steps that get cut, because by the time they arrive the site is live, the invoice is sent, and everyone has moved on.
Cutting them is understandable and it is also where most of the compounding value of a project goes missing. A site that launched is a hypothesis. Measurement is the only thing that turns it into knowledge.
What makes this practical rather than aspirational is deciding what to measure before launch, while the questions are still live. After launch, “let’s look at the analytics” produces a dashboard tour and no decisions.
A workable pre-launch measurement note is short:
- The one behaviour that means the site is working. Not traffic — a behaviour. A form submitted, a menu viewed, a catalog searched, a phone number tapped.
- The two or three supporting signals that would explain a change in it.
- The point at which we look. A date, decided now.
- What we would do if the number is disappointing. Deciding this in advance is what stops a bad result from being explained away.
Short-lifespan sites change the measurement question
Not every project has a long tail to measure. I built and ran the site for The Great Lakes Cigar Festival, an event hub with tickets, schedules, sponsor information, and vendor details. Analytics recorded 287 users and 1,954 events between 4 and 31 July 2026.
A site like that inverts the usual measurement logic. There is no month-over-month trend to build, no seasonal comparison, and no opportunity to iterate based on what you learn — the event happens once and the site’s job ends.
So the questions change. Instead of “is this improving,” the useful questions are:
Did people find the thing they came for? For an event site that is usually the schedule, the location, or the ticket link. If the event count concentrates on those, the structure worked.
Where did they arrive from, and what did they expect? Traffic from an Instagram post and traffic from a Google search for the event name want different things on the landing page.
What did people look for and not find? On a short-lifespan site this is the highest-value signal, because the answer usually applies to next year’s event as well.
The purpose of measuring a site that will not be improved is to improve the next one. That reframing is what keeps step ten worth doing on projects where step eleven does not exist.
The steps that compress safely
For balance, some steps genuinely can absorb pressure without damaging the outcome.
Research can be shortened when the client operates in a category you already know well — though it should be shortened deliberately, not skipped and then reconstructed from assumptions.
Design can compress substantially when there is an existing brand with defined colours, type, and assets. Most of design’s duration on small projects is decision-making, not execution, and a settled brand removes the decisions.
SEO as a distinct step can move after launch for a site with no existing search presence, provided the technical foundations — URL structure, indexability, structured data — were handled during development. Those cannot move.
Testing cannot compress. This is worth saying plainly, because it is the step that looks most like a formality and is the one where compression is most directly visible to the client, on launch day, in public.
What this is really about
A workflow list on a website communicates almost nothing, because everybody’s list is the same. What distinguishes one process from another is knowing where the risk sits and defending those points when a schedule is under pressure.
For me that means: get the goal specific enough to settle future arguments, treat content as the critical path from day one, and decide what success looks like before there is any temptation to reinterpret it.
If you would like to see how this plays out on real work rather than in the abstract, the project pages go through several builds in more detail, and my resume covers the operations side.
