Process
How we work
This page exists because "how do you work" is the question that actually decides whether a client can commit – and because it is the page that gets forwarded internally to whoever has to approve the spend.
Eight stages. Every one has a defined output. Nothing moves forward on an assumption that has not been written down and agreed.
Not every project runs all eight. A performance engagement starts at stage six; a discovery engagement ends at stage two. The sequence is what does not change.
Stage 01
Discovery
1–3 weeks
Understand the problem before proposing a solution.
What happens
- Interviews with the people who own the outcome and the people who will operate the result.
- Business process mapping, including the workarounds – which is where most real requirements are hiding.
- Review of existing systems, data, content, traffic and tooling.
- User research where users are reachable; analytics and support data where they are not.
- Competitor and comparator review.
What you receive
- Objectives and success criteria, stated as measurable outcomes
- Research findings and current-state system map
- Initial risk register
Stage 02
Strategy and definition
1–2 weeks
Convert findings into an agreed, estimable plan.
What happens
- Requirements written as outcomes and prioritised against effort and commercial value.
- Explicit split between first release and roadmap, with deferred items recorded as deferred.
- Technology and architecture recommendation, with alternatives and their long-term costs.
- Integration plan for the systems you already run.
- Measurement plan: what will be tracked, and which decision each metric supports.
What you receive
- Prioritised requirements and agreed scope
- Technology recommendation with reasoning
- Phased delivery plan with effort ranges and stated assumptions
- Measurement plan
Stage 03
UX and structure
2–4 weeks
Resolve structure before anything visual depends on it.
What happens
- Information architecture, navigation model and URL structure.
- User flows for the primary tasks, including the failure paths.
- Wireframes for every unique template, at mobile and desktop.
- Content requirements per template, so writing can start in parallel.
- Accessibility decisions that belong in structure: heading hierarchy, focus order, form design.
What you receive
- Information architecture and navigation model
- Annotated user flows
- Wireframes for every template
- Content requirements per template
Stage 04
Interface design
2–5 weeks
Design what will actually be built, with real content.
What happens
- Visual design across the full responsive range, not desktop-first with mobile derived from it.
- Every state each component can be in: empty, loading, error, overflowing, disabled.
- Design system: tokens, components, variants, spacing and layout rules.
- Contrast, target size and focus indication checked as design decisions rather than audited later.
- Interactive prototypes for the flows where interaction is the risk.
What you receive
- Interface designs across mobile, tablet and desktop
- Component library with all variants and states
- Design tokens and system documentation
- Prototypes for the high-risk flows
What happens
- Semantic HTML first, progressive enhancement, accessibility as an acceptance criterion.
- Performance budget agreed before design sign-off and enforced during the build.
- Content models and editorial roles configured for the team that will use them.
- Integrations built with the failure cases handled: retries, idempotency, alerting.
- Automated tests on the critical paths; regular demonstrable increments rather than one long silence.
What you receive
- Working increments on a staging environment throughout
- Source code in your repository with a documented deploy process
- Configured CMS, integrations and admin surfaces
- Test coverage on the critical paths
What happens
- Functional testing against the agreed requirements.
- Cross-browser and real-device testing, not just emulation.
- Accessibility testing: keyboard-only operation, screen reader passes, contrast, reflow at 320px and 400% zoom.
- Performance testing against the agreed budget, in lab and where possible in field conditions.
- Technical SEO verification: metadata, canonicals, structured data, sitemap, redirects, crawl.
- Security review: dependencies, headers, access control, exposed configuration.
What you receive
- Test results against the agreed criteria
- Accessibility findings and resolutions
- Performance results against the budget
- Technical SEO and pre-launch verification report
What happens
- Launch runbook agreed in advance, with a named decision maker and a rollback point.
- DNS TTL reduced ahead of the window; previous environment kept available.
- Redirects verified in bulk against the full URL inventory as the first post-launch action.
- Analytics and conversion tracking confirmed firing before anyone celebrates.
- Search Console submission and index monitoring started.
- Team training and documentation handover.
What you receive
- Launch runbook and rollback procedure
- Post-launch verification report
- Documentation and training for your team
- Monitoring and alerting configured
What happens
- Monitoring of uptime, errors, performance and Core Web Vitals, with alerting.
- Scheduled dependency and security updates, tested on staging.
- Measurement review against the plan agreed in stage two.
- Search, advertising and conversion work where those are in scope.
- Protected monthly capacity for improvements, so the roadmap actually moves.
What you receive
- Monthly report: work done, monitoring results, recommendations
- Quarterly performance, security and roadmap review
- Continuous improvements delivered against allocated capacity
Four things that stay constant
-
Nothing proceeds on an unwritten assumption Every stage ends with something written down and agreed. Disputes at the end of a project are nearly always about something nobody recorded at the beginning.
-
You see work in progress Staging access from the first development increment. Long silences followed by a reveal are how projects deliver the wrong thing on schedule.
-
One named point of contact Someone who knows your project and can answer for it, not a rotating queue.
-
Estimates are ranges with assumptions A single number implies a certainty that does not exist. We give a range and state what would move it.
Want to see how this maps to your project?
Tell us where you are – an idea, a brief, a failing site – and we will tell you which stage you actually need to start at.
Or email hello@applystudio.com – we reply within one business day.