What a scoped digital engagement should actually include

The buying decision

The investment should buy resolution, not a page count

Counting pages is easy, which is why weak proposals rely on it. But ten pages can be ten instances of one simple template, or ten completely different journeys with integrations, content rules and unusual states. The number alone says little about the work required or the business value created.

A useful premium engagement resolves uncertainty in sequence. It defines the commercial job, structures the information, establishes an original visual and interaction system, implements that system on the chosen platform, tests the important behaviours and transfers something the client can operate.

The proposal should make those decisions visible. If the beautiful part is detailed and the operating conditions are vague, the buyer is carrying hidden risk.

01 · Definition

A shared account of the problem and the boundary

Before interface work, both sides need an agreed answer to a few plain questions: what must change, for whom, why now, what evidence exists, what constraints cannot move and how the result will be judged.

This does not require months of abstract strategy. It requires enough definition to prevent taste from becoming the only decision system. The output might be a concise brief, audience and journey priorities, content responsibilities, technical assumptions, risks and acceptance criteria.

The proposal should also identify what is not being solved. A flagship marketing site, a commerce platform and a production application carry different responsibilities. Naming that boundary protects the budget from pretending to cover three products at once.

02 · Structure and design

An original system, not a sequence of isolated comps

The buyer should expect information architecture and content hierarchy to precede surface polish. A premium system needs a coherent type scale, colour logic, spacing, components, responsive behaviour, motion principles and image treatment. Those decisions should connect across the whole experience.

The proposal should explain which key routes, templates and states will be designed, how mobile is considered, and where client approval occurs. “Homepage design plus inner pages” is too vague when the commercial work happens in collection, product, enquiry, comparison or conversion states.

Original does not mean complicated. It means the system is derived from the brand, audience and commercial objective rather than adapted from the designer’s default aesthetic.

03 · Implementation

The production environment must be part of the promise

A design engagement and a design-and-build engagement are different products. Where development is included, the proposal should name the platform or technical assumptions, templates, integrations, content migration, analytics foundations, accessibility expectations and supported browsers or devices at an appropriate level.

It should also define who supplies accounts, credentials, data, copy, photography and legal approvals. A project can stall even when the interface is excellent if those dependencies appear only at launch.

For commerce, the catalogue model, product states, payment and shipping assumptions, applications and editorial controls matter. For a flagship website, forms, content management, analytics and deployment matter. For a prototype, the boundary between convincing interaction and production infrastructure matters most of all.

04 · Quality and launch

Acceptance should be observable

“Pixel perfect” is not an acceptance plan. A serious project should agree the critical journeys and the quality conditions under which they are reviewed: representative content, responsive ranges, keyboard behaviour, visible focus, reduced motion, error feedback, image delivery and performance priorities.

Launch responsibilities should also be divided. Who controls DNS or hosting, platform billing, application subscriptions, redirects, analytics access, final content entry and approval? What is tested before release, and what support window, if any, is included afterward?

Not every engagement needs the same ceremony. It does need an explicit route from approved design to accepted production work.

05 · Ownership and handover

The client should know what they can operate and what they receive

Ownership is a contractual matter, not a reassuring sentence on a sales page. The agreement should identify final deliverables, editable design or source files where applicable, code or repository access, documentation, account ownership, licensing restrictions and the transfer condition.

Third-party fonts, imagery, software, applications and platforms may have licences that cannot simply be reassigned. Those costs and constraints should be visible. The same applies to ongoing hosting, maintenance, analytics, campaign work and future feature development.

A strong handover is proportional. The client needs enough information to publish, administer and make ordinary decisions safely. Technical material should be organised for the people who will actually inherit it.

Rivenhall’s current starting points

How launch pricing is positioned

Brand identity begins at £500, website design and build at £700, ecommerce design and build at £1,000 and product prototypes at £1,500.

Each starting point represents a focused launch scope. Content, templates, integrations, migration, production and support can expand the final quotation.

Launch campaigns, product film and imagery, and interactive 3D experiences have their own scope logic on the Engagements page.

Published prices help qualification; they do not replace discovery. Final scope and investment should be confirmed only after the actual dependencies are understood.

Shared responsibility

Premium work still needs an active client

A closely managed studio process still depends on clear client responsibility. Someone needs authority to consolidate feedback, approve decisions and supply accurate business information. Content, catalogue data, photography, claims, policies, access and stakeholder availability can determine the schedule as much as design or development.

A good proposal states the response and approval assumptions used to build the schedule. It also identifies dependencies that can pause or resequence the work. This is not administrative caution; it is how the creative team protects focus and the buyer protects the launch.

Scope control

Revisions and new scope are not the same thing

A revision develops an agreed direction inside the stated objective. New scope introduces a new objective, route, integration, audience, platform condition or production requirement. The agreement should explain how both are handled.

Unlimited revisions sound generous and usually signal that the decision process has not been designed. A clearer model defines review points, who can approve, how feedback is consolidated and what happens when a requested change affects budget or schedule.

The important protection is mutual: additional work should not appear on an invoice without approval, and additional requirements should not be expected to disappear inside the original fee.

Proposal review

Compare the omissions, not just the totals

When two proposals differ dramatically, place their assumptions beside each other. Does one include content structure, mobile states, development, migration, integrations, quality review, analytics, launch and handover while the other names only design and page count? Are responsibilities and exclusions equally clear?

The cheapest proposal can be appropriate when the need is genuinely smaller. It becomes expensive when omitted decisions return as delays, change requests, fragile implementation or an immediate second project.

• What commercial objective and audience is the work organised around?
• Which routes, templates, components and states are included?
• Is responsive behaviour designed or merely implemented later?
• What platform, integrations and migration assumptions apply?
• How are review, approval and scope changes handled?
• What is tested, transferred, licensed and supported at handover?