Process
Six stages, and what you get at the end of each
The same sequence whether you are building a five-page site or migrating a store with two thousand products. What changes is the depth of each stage, not whether it happens.
- Written deliverable at the end of every stage
- Your responsibilities named, not assumed
- A staging URL you can look at from week one
- A change process agreed before work starts
Why does the process matter?
Because most project failures are not technical. They are the result of an assumption nobody wrote down: who was writing the content, whether the integration was in scope, what happened to the old URLs. A defined process forces those decisions into the open early, when they are cheap to resolve, instead of surfacing in the final week when they are not.
- Every stage produces something written that you keep
- Assumptions become explicit decisions at the point they are cheapest
- You can stop after any stage and take the work elsewhere
The stages
How a project runs from first call to launch
-
01
Discover
What business result the project must produce, who the users are, what exists now, what is failing, what content and data must move, and who approves decisions. This is where the awkward questions get asked.
You receive: Written brief and recommended approach
-
02
Plan
Page inventory, content model, integrations, URL and redirect plan, content responsibilities with names against them, milestones and a change process.
You receive: Scope, exclusions, schedule and quote
-
03
Design
The templates that carry the weight, resolved mobile-first and reviewed before any build begins. We design the pages that matter rather than every page.
You receive: Approved key template designs
-
04
Build
Development against the agreed scope on a staging URL you can look at throughout, with progress visible rather than reported.
You receive: Feature-complete staging site
-
05
Test and launch
Content, forms, responsive behaviour across every target width, accessibility, performance, security and redirects. Then a planned cutover with a rollback path.
You receive: Test record and verified live site
-
06
Improve
Post-launch review against the baseline recorded before launch, then either ongoing care or a planned next phase.
You receive: Measurement report and prioritised improvements
Responsibilities
Who does what
Most delays come from an unclear split here rather than from development. So it is agreed in writing during the planning stage.
| Area | DEVIEC | You |
|---|---|---|
| Scope and estimating | Prepare scope, exclusions and estimate | Confirm priorities and approve scope |
| Content | Structure, migrate and advise on what each page needs | Supply or approve copy, images and product data |
| Design | Design and iterate the key templates | Consolidated feedback within the agreed window |
| Development | Build, test and document | Access to hosting, accounts and existing systems |
| Integrations | Build and test against the third-party system | Credentials, and the vendor contact where one is needed |
| Approval | Present work for review at each milestone | One named decision-maker who can approve |
| Launch | Cutover, redirects, verification and monitoring | Domain and DNS access, and a launch window |
| After launch | Handover, documentation and training | Decide on ongoing care or self-management |
How we communicate
What working with us is actually like
-
One named contact
The developer building your project is the person you talk to. Nothing is relayed through an account layer.
-
A staging URL from week one
You can look at progress whenever you like, rather than waiting for a scheduled reveal.
-
Written decisions
Anything agreed on a call is confirmed in writing, so nobody is relying on a shared memory of week three.
-
Early warning
If something is going to slip, you hear it as soon as it is apparent, while there is still time to react.
-
A defined change process
Changes are normal. Each one gets an impact, a cost and a schedule effect before it is accepted.
-
Async by default
Written updates rather than status meetings, with scheduled calls for decisions that genuinely need a conversation.
The honest part
What delays projects, almost every time
It is content. Not development, not design, not integrations. A build finishes on schedule and then waits three weeks for the About page copy, the product photography or the team biographies.
This is entirely normal — writing content is genuinely hard, and it competes with running your business. Which is why we name content owners and dates during the planning stage, tell you exactly what each page needs, and flag early when a content deadline is going to move the launch. Being surprised by it in the final week helps nobody.
- Content requirements listed page by page during planning
- A named owner and a date against each item
- Early warning when a content delay will move the launch date
- Realistic advice about what can launch without being perfect
Questions
Process questions
Can we skip discovery to save time?
How many rounds of design feedback do we get?
What if we want to change something mid-build?
Do we get access during the build?
What happens if we stop the project part way?
Ready to start at stage one?
Discovery begins with a conversation about the business result you need. Tell us what that is.