01 / DISCOVERY & ASSESSMENT
Assess the requirements.
A separately scoped, paid engagement to resolve priorities, assess an existing platform or define a new one.
Outputs: findings, constraints, priorities and a project brief.
APPROACH
From the brief
to the release.
The work is organised around the brief, with review stages for design, development and release. The scope determines which stages a project needs.
WHERE TO BEGIN
Define the work
before committing to the build.
A discovery engagement establishes the audiences, content, technical constraints and priorities. It can help define a new platform or assess an existing one.
02 / PLATFORM DELIVERY
Build against an agreed scope.
Strategy, design and engineering organised around defined deliverables and recorded approval points.
Outputs: the agreed platform, release evidence and handover.
03 / DEVELOPMENT PARTNERSHIP
Develop an existing platform.
A separately agreed programme of improvements, with priorities, ownership, capacity and support boundaries made explicit.
Outputs: an agreed roadmap, scoped releases and review points.
Make the problem specific.
Who needs the platform? What do they need to accomplish? What exists already, and what has to change? Surface content, data, integration and operational constraints early.
Decision to reach
An agreed problem, priority audiences and the outcomes the project should support.
Agree the scope.
Set the information structure, technical direction, responsibilities and review points. Identify the decision-maker and agree how stakeholder feedback will be consolidated.
Decision to reach
A proposal defining deliverables, assumptions, exclusions, fees, timing and acceptance criteria.
Review the design and build.
Develop the interface and technical foundations together. Use agreed review stages to resolve content and design questions before they become expensive changes.
Decision to reach
Approval against the agreed scope, with new requests recorded and assessed separately.
Check the release.
Check the relevant journeys, devices, content and technical requirements. Confirm the intended release, domain behaviour, indexing policy and any configured integrations.
Decision to reach
A documented release decision, known limitations and a recovery route appropriate to the platform.
Prepare the handover.
Clarify source access, accounts, content ownership, operating instructions and future support. A platform should remain understandable after the first launch.
Decision to reach
An agreed handover and, where needed, a separately scoped improvement or care arrangement.
COMMERCIAL TERMS
Scope before price.
Fees follow the defined work, responsibility and delivery requirements. Milestones, acceptance and payment terms belong in the agreement. Hosting, third-party subscriptions and ongoing support are agreed separately.
TECHNICAL REVIEW
Testing and release.
Distinguish a built feature from a configured service, a successful deployment from indexing, and an automated check from a full audit.
OWNERSHIP
Know what you receive.
Source, assets, licences, third-party accounts and support responsibilities should be explicit in the proposal and handover.
Our engagement framework is tailored to each brief. Activities, deliverables, checks and support commitments are confirmed in the proposal.
Design and
working practice.
Some client and partner engagements remain confidential. Project details are published only with permission; the public portfolio is a selected view, not a complete client list.
We review interfaces with the content they will carry and the tasks people need to complete. Technical review covers the agreed requirements, release process and information needed to maintain the platform.
BEFORE YOU BEGIN
A few practical
questions.
Do we need a finished brief?
No. Start with the audience, the problem and what a useful result would look like. Discovery can establish priorities and constraints before a larger build is commissioned.
Can you improve our existing website?
An assessment can establish what should stay, what needs attention and whether a redesign or a smaller set of changes is appropriate. Existing content, systems and access are part of that assessment.
How are cost and timing agreed?
They follow the agreed scope, content requirements, dependencies and review process. A proposal sets out deliverables, exclusions, fees and timing. There is no automatic quotation or booking through this website.
What should we prepare?
A short description of your organisation, priority audiences, current website if you have one, the problem to resolve, timing or budget constraints and the person who will approve the work. Keep passwords and confidential records out of the planner.
What happens after handover?
Source access, accounts, content, licences and operating instructions are identified in the agreement. Hosting, maintenance and ongoing development need a separately agreed owner and scope.