The order of project stages

Which decisions must be made before implementation, and why content, SEO and testing should not be left to the very end.

Website development has an order, but not a rigid staircase you can only climb. Structure affects design, design affects implementation, and the first tests sometimes force a rethink of the structure. What matters is making the decisions that are expensive to change later on time, and leaving room for checks.

For example, page types and the user journey are best defined before a detailed mockup. A button colour can be settled much later. Both decisions matter, but changing them costs very different amounts.

First agree on what the site must do

The team finds out who needs the site, what tasks visitors come with, where products and texts come from and which systems receive enquiries. These answers produce the structure, priority pages and success criteria. A specification is useful when it records such agreements rather than just listing buttons.

For a small project, a short diagram is enough. A complex one needs detailed scenarios and integration checks. The size of the document should match the risk of getting it wrong.

SEO isn't a roof you put on at launch

If search matters to the business, the page structure and section names need discussing before design. Promotion can continue after launch, but missing pages or awkward URLs will already need rework.

SEO support does not mean the specialist runs the whole project. They check decisions that affect page accessibility and content while those are still relatively easy to change.

Content is needed before the last upload to the CMS

Draft texts and real specifications help test the prototype and the mockup. Final wording can be approved later, but the whole meaning of the site cannot be left to the content stage. Otherwise the design will have to be bent around the content after the build.

For projects with a large catalogue, prepare a few typical product cards in advance, including difficult ones. They will show whether the template can handle real data.

Stages can run in parallel; dependencies remain

While the designer works on the visual direction, the developer can test the integration with the accounting system. While the first template is built, the editor prepares the next materials. Running things in parallel speeds the project up if the team knows which decisions are final and which are still being tested.

The problem is not going back to an earlier stage but going back unexpectedly without assessing the consequences. If pricing rules change after the catalogue was approved, you need to understand what that touches: the interface, data exchange, tests and deadlines.

Testing starts before the Publish button

Forms, mobile behaviour, sync errors and user permissions are best checked as they are implemented. A final check before launch is still necessary, but it should not be the first time anyone discovers that a basic scenario does not work.

A good sequence leaves a clear result after every major step: what is approved, what is tested and which questions are still open. That is more reliable than the foundation-and-roof metaphor, where any change seems to require tearing down the whole house.