How we work

Our WordPress process, explained step by step.

Good work is not luck — it is a process you can see coming. Every Dotance project runs on the same backbone: discover, plan, design, build, test, launch. Below is exactly what happens at each stage, and how that backbone changes for the five things clients ask us to do most — design, custom development, redesigns, online stores and speed.

  • One transparent backbone across every project, no black boxes
  • A defined process for design, development, redesign, WooCommerce and speed
  • You always know the current stage, the next stage and what we need from you

The approach

Every project runs on the same six stages.

Whatever the brief, the work moves through the same six stages. What changes between a design job, a custom build or a speed engagement is the depth of each stage — not the order. Keeping the backbone constant is what lets us give you an honest timeline on day one and hit it.

  1. Discovery & audit

    We learn your goals, users and constraints, and audit what already exists — content, code, analytics and rankings — so decisions are based on evidence, not assumptions.

  2. Strategy & scope

    We turn findings into a written scope: what we are building, in what order, on what timeline, and how we will know it worked. No surprises later because everything is agreed up front.

  3. Design & prototype

    Structure before decoration. We wireframe, then design against real content and every state — hover, empty, error, long-content — so what you approve is what gets built.

  4. Development

    Clean, standards-based WordPress. Editable blocks with guardrails, a performance budget from the first commit, and code you or anyone else can maintain afterwards.

  5. QA & testing

    We test on real devices, real content and real load: accessibility, cross-browser, Core Web Vitals, forms, checkout and security — on a staging copy, before anyone else sees it.

  6. Launch & aftercare

    A planned launch with redirects and monitoring, then a settling-in period. We watch the numbers for the first weeks and fix anything the real world surfaces.

The five sections below show how that backbone plays out for the work clients ask for most. Each one is a real, repeatable sequence — not a sales pitch.

01 · Website design

How we design a WordPress site.

Design service ↗︎

Design starts with what you publish and who publishes it — not with a colour palette. The goal is a system that still looks designed two years and a hundred edits later.

  1. Content model first. We map the real content — headline lengths, product counts, image availability — so the design is built for what you actually have, not for lorem ipsum.
  2. Structure & wireframes. Low-fidelity layouts settle hierarchy, page templates and navigation before any visual polish, when changes are cheap.
  3. Visual design & system. Colour, type and spacing become reusable tokens feeding components and patterns — a design system, not a set of one-off screens.
  4. Prototype & review. You review a clickable prototype with every state defined, so approval means the build has no gaps to guess at.
  5. Build-ready handoff. Documented components, breakpoints and edge cases go to development — whether that is us or your own team.
Design workflow diagram

What you get: a documented design system, responsive layouts for every template, and specifications for every interaction state.

02 · Custom development

How we build custom WordPress.

Development service ↗︎

Custom development is where a design becomes something editors can actually run without breaking it. We build to WordPress standards so the site outlives any one developer.

  1. Technical planning. We define the architecture — post types, fields, blocks, integrations — and set a performance and accessibility budget before writing code.
  2. Environment & tooling. Local, staging and production environments with version control, so every change is tracked and nothing is edited live.
  3. Block & theme build. Editable blocks with locked patterns and a fixed palette: freedom where content needs it, guardrails everywhere else.
  4. Integrations & data. CRMs, payment, ERP, APIs and migrations — connected and tested with real data, not happy-path demos.
  5. Code review & QA. Every change is reviewed against the performance budget and tested on staging before it ships.
  6. Documentation. A short handbook of how the blocks, fields and integrations work, so your team is never stuck.
Development workflow diagram

What you get: a standards-based theme, editable blocks with guardrails, tested integrations and documentation your team can use.

03 · Redesign & migration

How we redesign without losing rankings.

Redesign service ↗︎

The biggest risk in a redesign is not design — it is losing the traffic the old site already earns. Our process protects rankings as a first-class requirement, not an afterthought.

  1. Baseline audit. We record current rankings, top-performing pages and traffic sources, so we know exactly what must be preserved.
  2. Content & URL inventory. Every existing URL is catalogued and scored — keep, merge, improve or retire — before anything is rebuilt.
  3. Redesign & rebuild. The new design and build follow our standard design and development stages, on a staging copy alongside the live site.
  4. Redirect mapping. A one-to-one 301 map from old URLs to new, so link equity and bookmarks survive the move.
  5. Pre-launch parity check. Metadata, headings, structured data and internal links are checked against the baseline so nothing regresses.
  6. Launch & monitor. We launch at a low-traffic window, submit the new map to search engines and watch rankings closely for weeks.
Migration map diagram

What you get: a full redirect map, a pre-launch SEO parity report, and a monitored launch with rollback ready.

04 · WooCommerce & online stores

How we build a WooCommerce store.

WooCommerce service ↗︎

A store is only as good as its checkout and its integrations. We build the parts closest to revenue first, and test them under real conditions before launch.

  1. Catalog & requirements. Products, variations, tax, shipping and payment rules are mapped up front — this is where most store projects go wrong.
  2. Store architecture. We structure products, categories and pricing for the way you actually sell, including B2B or subscription models where needed.
  3. Checkout & UX build. The path from product to paid is built and streamlined, because every extra step is lost revenue.
  4. Integrations. Payment gateways, ERP or inventory, email and analytics — connected so stock and orders never fall out of sync.
  5. Load & security testing. We test checkout under load and harden the store, since logged-in and cart traffic bypasses ordinary caching.
  6. Launch & optimise. After launch we watch conversion and checkout drop-off, and tune what the data shows.
Store build flow diagram

What you get: a tested checkout, synced integrations, load and security checks, and conversion analytics from day one.

05 · Speed optimization

How we optimize WordPress speed.

Speed service ↗︎

A green score in a lab tool is not a fast site for real users. Our process is a measurement loop that fixes causes at the source, so the gains survive the next plugin update.

  1. Measure with field data. We start from real-user Core Web Vitals, not a single lab test on an empty cache — because that is what Google and your customers actually experience.
  2. Diagnose the causes. Render-blocking assets, database queries, plugin bloat and un-cacheable pages are identified specifically, with evidence.
  3. Fix at the source. We fix the underlying cause rather than stacking another caching plugin on top of the problem.
  4. Caching & delivery. Page, object and asset caching plus a delivery layer are configured to match how your site is actually used.
  5. Re-measure & verify. We confirm the improvement in field data, with before-and-after numbers you can show your board.
  6. Guardrails. A performance budget and monitoring so speed does not quietly erode three months later.
Optimization loop diagram

What you get: a before-and-after field-data report, fixes at the source, and guardrails that keep the site fast.

Questions

Process questions, answered plainly.

If your situation isn't covered here, send us the details and we'll reply with a straight answer.

How long does a typical WordPress project take?

Most projects run between four and twelve weeks, depending on scope. A focused design or speed engagement is usually a few weeks; a full custom build or a WooCommerce store with integrations is longer. Because every project moves through the same six stages, we can give you a realistic, stage-by-stage timeline in the scope document before any work starts.

What do you need from us to start?

To begin discovery we need access to your current site and analytics, a clear picture of your goals, and one decision-maker who can give feedback and approvals. We do not need finished content or design assets on day one — the process is built to work from a realistic outline and develop the detail with you as we go.

How involved do we need to be during the project?

Your heaviest involvement is at the start, during discovery and scope, and at the review points in each stage. Between those, we work independently and check in on an agreed rhythm. You will always know the current stage, the next stage and exactly what, if anything, we need from you — so the project never stalls waiting on a surprise request.

Can you work with our existing site instead of starting over?

Often, yes. The discovery and audit stage tells us whether it is smarter to improve what you have or rebuild. Speed, security and maintenance work almost always builds on the existing site. A redesign may rebuild the front end while preserving your URLs, rankings and content. We recommend the option that serves the goal, not the bigger project.

Do you use page builders or custom code?

We build with the native WordPress block editor and custom code, not heavy third-party page builders. That keeps the site fast, standards-based and maintainable by any WordPress developer afterwards. Editors still get flexible, editable blocks — but with locked patterns and a fixed palette, so the layout cannot be accidentally broken.

How do revisions and feedback work?

Each stage has a defined review point where you give consolidated feedback in one place, and we revise before moving on. Catching decisions at the right stage — structure during wireframes, look during design, behaviour during build — is far cheaper than changing them after launch, which is exactly why the process is ordered the way it is.

What happens after launch?

Launch is not the finish line. We monitor the site for the first weeks and fix anything the real world surfaces, then offer ongoing maintenance and support — updates, backups, monitoring and continuous optimisation — so the site stays fast, secure and current instead of slowly decaying.