Process

This is the delivery loop. It keeps work predictable and makes reviews and QA easier.

1. Brief

You share the essentials.

• Goals and deadline
• Sitemap or page list
• Designs or wireframes
• Content approach and CMS needs
• Accessibility target and performance budget
• Who reviews and who signs off

2. Scope and plan

I return a plan you can approve.

• Delivery plan and milestones
• Assumptions and exclusions
• Risks and dependencies
• What I need from you, and when

3. Build

I build in your repo and work through tickets or milestones.

• Repo setup and environments
• Components and templates
• Content wiring and deploy pipeline
• Written progress updates weekly, or per milestone

4. QA

We test against the agreed targets. I fix issues as we go.

• Responsive checks
• Keyboard and screen reader pass on key flows
• Core Web Vitals and page weight checks
• Bug list tracked to closure

5. Release and handover

You ship. I support the release and hand over cleanly.

• Launch checklist and release support
• Docs and handover notes
• Optional editor handover for CMS builds
• Short support window for post-launch issues, if agreed

Scope guardrails

Guardrails prevent budget drift and deadline pain. They also keep reviews simple.

Typical scope ranges

Most builds sit in one of these buckets.

• Starter site
  3 to 5 templates. Up to 10 content pages. One form.
• Standard marketing site
  5 to 8 templates. Up to 20 content pages. Two to three forms.
• Campaign or landing set
  1 to 3 templates. Multiple variations. Tight turnaround.

Templates means page types, such as home, about, service, contact, article, case study, listing, detail.

What you provide

• Final content, or placeholders with a clear delivery date
• Figma link preferred. Finalised layouts for each breakpoint you care about
• Brand assets. Logo, fonts, imagery
• Tracking requirements. Analytics, pixels, consent rules
• Legal pages copy, if needed

What I provide

• Front end build and integration for the agreed scope
• PR-based delivery with review points
• Docs and handover notes
• Accessibility and performance checks against agreed targets

What counts as a revision

A revision is a change within the agreed templates and components.

Included revisions usually cover:

• Copy tweaks and minor spacing changes
• Small component adjustments that do not change page structure
• Fixes for missed requirements in the agreed scope

Not included as revisions:

• New components not in the original designs
• New templates or new page types
• Significant layout rework after sign-off
• New integrations. Third-party widgets, booking tools, product feeds

Change requests

If scope changes, I price it and schedule it before starting. Common triggers:

• Page or template count increases
• New component types appear in late designs
• Content arrives late and shifts milestones
• New forms, new fields, or new validation rules
• CMS requirements change after build starts
• New browser support or accessibility target appears mid-project
• Stakeholder feedback introduces new requirements

Sign-off points

Sign-off points stop endless loops. They also make QA faster.

• Design sign-off before build starts
• Template sign-off once the first template is built
• Content sign-off before final QA
• Launch sign-off before release

Content ownership

• You own content quality and approvals
• I implement content and templates as agreed
• If you want me to write or edit content, price it separately

Assumptions

• One primary reviewer on your side
• Feedback returned within agreed timeframes
• Assets and content delivered by the dates in the plan