How DBS Digital Delivers Website Projects: Our Process and Quality Standards

Why Process Matters More Than Promises

When you’re choosing a website agency, it’s easy to focus on their portfolio, pricing, reviews, and case studies. All of that matters, but the factor that most directly affects whether your project succeeds is something less visible: delivery discipline.

A polished sales conversation is simple to put together. What’s harder, and far more valuable, is a formal process that keeps your project on track from the first briefing call to the day after launch. Without it, scope creeps, feedback loops stall, and quality checks get compressed because time has run out.

The most common reason website projects go wrong is not a lack of creative talent. It is a lack of process.

At DBS Digital, quality assurance is not something that happens in the final week before launch. It is built into every stage of the project. Here is exactly how that works.

What a structured delivery process gives you:

• Fewer surprises, because risks are identified early rather than discovered late
• Clearer accountability, because every stage has defined outputs and approval points
• A stronger final product, because quality is checked continuously, not compressed into a single pre-launch review

Stage 1: Discovery and Project Scoping

Every project starts with a dedicated discovery phase, typically running two to four weeks depending on complexity. This stage determines whether everything that follows is built on solid foundations or on assumptions, which is why it is never treated as a formality.

Discovery is where your business goals, user needs, required functionality, and success criteria get defined and documented. Rushing this phase to save time at the start reliably costs more time later, when changes are expensive and deadlines are close. According to the Project Management Institute, poorly defined scope is one of the leading contributors to project overruns in digital delivery.

Before design or build begins, discovery produces six documented outputs:

1. Business goals and success criteria – what your website needs to achieve commercially, and how success will be measured. Common KPIs agreed at this stage include conversion rate, enquiry volume, and cost per acquisition
2. Target audience and user needs – who the site is for, what they are trying to do, and what would make their experience better
3. Required functionality and integrations – forms, booking systems, e-commerce, CRM connections, or any third-party tools that need to work with the site
4. Content requirements – what content exists, what needs to be created, and who is responsible for supplying it
5. Technical restrictions and migration risks – existing platform limitations, domain considerations, redirect requirements, and any dependencies that could affect your timeline
6. Approval dependencies and stakeholder map – who needs to review and sign off at each stage, and what their availability looks like

This documentation becomes the reference point for every decision made during the project. If a question arises about scope, timeline, or priority, the discovery outputs provide the answer.

Discovery quality checks:

• Percentage of key stakeholders interviewed and signed off
• User journeys documented for the most commercially important paths
• Agreed goal and KPI document confirmed in writing before build begins

Stage 2: Planning, Information Architecture, and UX Direction

Once scope is agreed, the attention shifts to structure. Information architecture (IA) is the discipline of organising your pages, content, and user journeys in a way that serves both your visitors and your business goals. Done well, it makes your website intuitive. Done poorly, it produces a site that looks good but loses visitors before they convert.

As the Nielsen Norman Group notes, usability planning and task-based structure are among the most reliable predictors of whether users can find what they need and take the actions you want them to take.

This stage also covers UX direction: the wireframing and planning work that defines layout logic, content hierarchy, and calls to action before any visual design begins. Dealing with these decisions at the wireframe stage is significantly cheaper than changing them once design or build is underway.

What this stage produces:

• A site map showing all pages, their hierarchy, and how they connect
• Wireframes for key page templates, showing layout and content priority
• Defined user journeys for the most commercially important paths (enquiry, purchase, contact)
• Agreed calls to action and conversion points across the site

Stakeholder review checklist at this stage:

• Does the navigation reflect how your users think, not how your business is structured internally?
• Are the most important conversion actions visible and accessible within one or two clicks?
• Does the page hierarchy support the business goals identified in discovery?
• Are there any missing pages or journeys that need to be added before design begins?

Capturing your feedback here protects the project. Changes to structure are straightforward on a wireframe. The same changes on a built website are costly and time-consuming.

Stage 3: Visual Design and Build Handover

Visual design is where the project becomes tangible, and it is also where inconsistency between creative intent and technical execution most commonly occurs. A controlled handover from design to development is what prevents that misalignment from becoming expensive.

Design at this stage is guided by four priorities: brand consistency, usability, responsiveness across devices, and conversion intent. Aesthetics are important, but design that looks beautiful without driving conversions is not generating value for your business.

What a structured handover looks like

The difference between a smooth build and a difficult one often comes down to how clearly design is handed over to development.

With a structured handover, your development team receives:

• Approved layouts for all key templates, not just the homepage
• Documented component logic, hover states, and interactions
• Content requirements mapped to each template
• Responsive behaviour specified for mobile, tablet, and desktop
• Brand assets, typography, and colour values in a single reference document

Without a structured handover:

• Developers interpret design intent rather than follow it
• Inconsistencies appear across pages that were not explicitly designed
• Rework requests increase during QA, adding time and cost to your project
• The gap between the approved design and the built site erodes confidence on both sides

First-pass acceptance rate is the metric that reveals whether handover quality is working. A high rate means developers build accurately following the approved design. A low rate means the handover was unclear and potential reworks are needed, extending development time.

Stage 4: Development and Continuous Quality Control

Development is where your site is built, and it is the stage where a “build everything, then test” approach causes the most damage. By the time all-at-once testing reveals a structural issue, the cost of fixing it has multiplied. Continuous quality control during the build prevents this.

The development workflow follows a staged review model:

1. Scope confirmation – development begins only against approved designs and a locked scope document, so you can be confident the team is building to your brief
2. Component build and internal review – individual components (headers, cards, forms, navigation) are reviewed as they are completed, not after the full build is assembled
3. Staging environment deployment – your site is built in a staging environment, separate from any live domain, so changes can be tested without affecting your existing web presence
4. Responsive and cross-browser checks during build – layout and functionality are checked across devices and browsers progressively, not as a single pre-launch task
5. Version control – all code changes are tracked, making it straightforward to identify when an issue was introduced and to roll back if needed
6. Internal sign-off before client review – the site goes through an internal review cycle before it is shared with you, so your review meetings focus on the right things rather than catching basic errors

Requirements-to-test coverage measures the percentage of agreed website requirements mapped to at least one test case. Full coverage means nothing is being built without a defined way to verify it works correctly.

By the time your project reaches final QA, most functional issues have already been identified and resolved, so the final stage becomes a validation exercise rather than an attempt to discover problems at the last minute.

Stage 5: Final QA, User Acceptance Testing, and Launch Readiness

Before your website goes live, it goes through a structured pre-launch QA process. This is a systematic check of every area that could affect your users, conversions, or reputation, covering far more ground than a quick scroll through the homepage.

Pre-launch QA checklist

Functional testing:

• All forms submit correctly and trigger the right confirmation as well as notification
• All internal and external links resolve without errors
• Navigation works correctly across all menu states and devices
• Any integrations (CRM, booking, payment) are tested end-to-end

Responsive and browser compatibility:

• Site is tested across mobile, tablet, and desktop at multiple screen sizes
• Layout and functionality are verified across major browsers (Chrome, Safari, Firefox, Edge)
• Touch interactions together with mobile-specific behaviours are confirmed

Content and CMS:

• All pages carry final, approved content with no placeholder text remaining
• Images are correctly sized, compressed, and labelled with descriptive alt text
• Your CMS is configured so you can update content without breaking layouts

Performance and accessibility:

• Core Web Vitals are reviewed, with targets of under 2.5 seconds for Largest Contentful Paint and a Cumulative Layout Shift score below 0.1
• Accessibility checks are completed against WCAG 2.1 Level AA, including colour contrast, keyboard navigation, and heading structure
• SSL certificate, redirects, and canonical URLs are confirmed

The launch gate

The most important metric at this stage is defect escape rate: the proportion of issues found after launch compared to those caught before it. A well-run QA process drives this as close to zero as possible. Any P0 or P1 defect (a broken user journey, a failed form, a payment error) is a hard stop. Nothing goes live until critical issues are resolved.

User acceptance testing (UAT) gives you a formal, structured opportunity to validate the site against the agreed brief before it goes live. This is a sign-off process with a clear checklist and a defined resolution window for any issues you raise. Nothing launches without your UAT sign-off.

The QA Metrics That Actually Demonstrate Value

QA metrics are only useful if they connect to real outcomes for you. Tracking them for reporting purposes misses the point. The right metrics tell you whether your website is ready to launch and whether it will perform once it is live. As the GOV.UK Digital Assurance Playbook puts it, quality assurance should provide confidence that outputs match defined quality criteria, not just generate a report.

Every metric should have a target and a threshold at which work stops until the issue is resolved.

Delivery and defect metrics:

• Defect count by severity (critical, major, minor) at the point of final QA. A lower count reflects the effectiveness of continuous QA during build, not luck.
• Test pass rate across the pre-launch checklist. The target is 100% on critical and major items before UAT begins.
• Broken link count. Should be zero at launch, without exception.
• Form submission success rate. All forms tested and confirmed functional before go-live.
• First-pass acceptance rate. The percentage of deliverables accepted without rework. A consistently high rate means handovers between stages are clear and well-executed, which directly protects your timeline.

Performance benchmarks:

• Page speed scores reviewed against Google PageSpeed Insights, targeting “Good” ratings across Core Web Vitals
• Image compression and file size targets met across all pages
• Analytics tracking confirmed as active and reliably capturing your key events and conversions

Usability and accessibility:

• Accessibility issues resolved before launch, with WCAG 2.1 Level AA as the baseline standard
• Responsive layout verified across a minimum of five device and screen-size combinations
• Browser compatibility confirmed across the four major browsers

Post-launch responsiveness:

• Release success rate: the percentage of launches that do not require a rollback or emergency fix. This is a direct measure of how well the pre-launch process worked.
• Time to acknowledge and resolve any launch-day issues, within a defined support window

Each of these metrics represents a category of risk that, left unchecked, produces a broken journey, a lost conversion, or a poor first impression for your visitors.

After Launch: Monitoring, Fixes, and Continuous Improvement

Launch day is the point at which real users start interacting with your site, and that interaction surfaces things that controlled testing environments sometimes miss.

A structured post-launch period protects the investment you have made in the build and ensures any issues get resolved quickly, before they affect your users or your search performance.

The post-launch sequence:

1. Active monitoring – your site is watched closely in the hours and days after launch for errors, tracking gaps, broken redirects, or performance changes
2. Issue triage and resolution – any problems identified are logged, prioritised by severity, and resolved within a defined support window
3. Analytics review – early traffic data is checked to confirm that tracking is tracking the right events and that user journeys are behaving as expected
4. Redirect and SEO health check – for sites migrating from an existing domain, redirects are verified, and any crawl errors are identified and fixed promptly using Google Search Console

The most valuable agencies treat launch data as the starting point for improvement, not as confirmation that the job is done. Traffic patterns, user behaviour, and conversion data from the first weeks of your new site provide some of the most useful insight available for steering the next round of optimisation.

What to Look for When Choosing a Website Agency

A credible website partner should be able to explain its process in detail. If an agency cannot tell you clearly what happens at each stage, who is responsible for sign-off, and how quality is checked before launch, that is worth taking seriously.

The process described in this article applies to every website DBS Digital delivers, because the risks it protects against are present in each project regardless of size or budget.

When you are evaluating agencies, three questions cut through the noise:

• Can they describe their QA process specifically? Not “we test everything” but what they test, when they test it, and against what standard.
• Do they have a defined sign-off structure? Vague feedback loops are where scope creep and delays originate.
• What happens after launch? An agency that treats launch as the end of its involvement is not set up to protect your investment.

If you are planning a new website and want to understand how we would approach your project, get in touch and we will walk you through it.