Opinion
Responsive Design: The key to a user-friendly and seo-friendly website
A website that fails on mobile is a recipe for disaster. Discover how responsive design allows your site to adapt seamlessly to any scree...
Project delivery
Web projects that ship on time, on brief and without surprises.
Most digital projects fail not because of bad code or bad design, but because of how they were run. We've built a delivery model around the things that actually determine outcomes: clear briefs, aligned stakeholders, structured feedback, and honest communication from day one.
Most digital projects don't fail because of bad design or bad code.
They fail because of unclear briefs, misaligned expectations, feedback that arrives three weeks late, and stakeholders who weren't consulted at the right time.
This guide is about the other side of the equation: what good digital project delivery actually looks like, what it requires from both parties, and how to make sure your next web project ends with something you're proud to share rather than something you're embarrassed to explain.
"Digital project delivery" is one of those phrases that sounds self-explanatory until you try to define it.
At its core, it means the structured process of taking a digital project, a website, a web application, a platform, from initial concept to live product. That process involves the infamous '4 D's', Discover, Define, Develop (or Design) and Deliver. But it also involves something less often discussed: the management layer that holds all of those things together.
A delivery process determines how decisions get made, how changes are handled, how progress is communicated, and what happens when something goes wrong. Projects without one don't collapse all at once, they drift. Slowly and then suddenly, you're six weeks past the deadline with a product that doesn't match the brief.
Good delivery is what separates projects that ship on time, on budget, and that are on brief, from the ones that become cautionary tales.
Why
Why so many digital projects go wrong
Before we get into what good looks like, it's worth being honest about why projects fail. Because the causes are almost always predictable and preventable.
- 01The brief wasn't detailed enough
A vague brief produces a vague result. If you couldn't explain what success looks like before the project started, you can't evaluate what was delivered. The time spent on a thorough brief before any work begins is paid back many times over in reduced rework, fewer disputes, and a clearer shared understanding of what's being built.
- 02Scope crept, incrementally
“Can we just add one more thing?” can be the most expensive sentence in digital project management. Not because the request itself is unreasonable, but because every addition carries a downstream impact on time, cost, and complexity.
In traditional delivery models, these changes can quickly derail a project if they’re not properly assessed and controlled.
In agile environments, change isn’t the enemy, it’s expected. The difference is that change is managed through prioritisation, trade-offs, and structured iteration. New ideas don’t simply get added on top, they compete for space.
Scope changes aren’t inherently bad. Unmanaged scope changes are. A well-run project creates clarity around what gets included, what gets deferred, and what it costs. A poorly run one says, “we’ll sort it out as we go.”
- 03Feedback was slow, consolidated badly, or contradictory
One week of delayed feedback from a client adds one week to a project timeline minimum. And that's when the feedback is clear. When it arrives in multiple emails, from multiple stakeholders, with conflicting instructions, the delay is much longer.
Consolidated, timely feedback is one of the most concrete things a client can do to keep a project on track. It's also one of the most commonly underestimated responsibilities.
- 04Stakeholders were surprised at the end
The people who need to approve the final product are the people who need to be aligned from start to finish. When key stakeholders are brought into a project at the point of sign off, you are almost guaranteed late stage changes that are expensive to implement and demoralising for everyone involved.
- 05No clear process
Sometimes the issue is on the agency side. An agency that can't articulate its delivery process before the contract is signed doesn't have one. And a project that runs without a documented process, phases, milestones, change management, communication cadence is running on goodwill. Goodwill has limits.
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Book a call
Phases
The phases of a well-delivered digital project
A properly structured digital project moves through distinct phases. Each one has defined deliverables, clear ownership, and a handoff point. Skipping or compressing phases is where most problems originate.
- Phase 1: Brief and scope
This is one of the most important phase of the project, and the one most often rushed.
A good brief documents what you're building and why. It covers your business goals, your users, your content, your integrations, your timeline, your budget, and your definition of success. It specifies what is in scope and critically, what is out of scope.
A scope document produced from the brief becomes the contract between you and your agency. If something isn't in the scope, it's either a change request or it doesn't happen. This is protective for both parties.
What you need to do: Invest real time here. Gather input from all stakeholders before this phase closes. Agree in writing before anything is designed or built.
- Phase 2: Discovery
Discovery is the agency doing the thinking they need to do before they start building. For web projects, this typically includes: content modelling, technical specification, sitemap and architecture planning, user flow mapping, and integration planning.
Good discovery produces artefacts, documents, diagrams, specifications, that can be reviewed and approved. Bad discovery produces a phone call and a handshake.
If an agency doesn't have a discovery phase, or dismisses it as unnecessary overhead, that's a red flag. The cost of discovery is low compared to the cost of building the wrong thing.
What you need to do: Participate. Answer questions thoroughly. Review and approve discovery artefacts before design begins.
- Phase 3: Design
Design in a digital project is more than making things look good. It involves information architecture, user experience, and the visual translation of your brief into a buildable specification.
A proper design phase produces wireframes (layout without visual styling) before moving to high-fidelity visuals. This separation allows structural feedback before visual feedback, which is faster, cheaper, and less likely to produce rework.
Feedback at the design stage is the cheapest change you'll ever make. Feedback after development is the most expensive.
What you need to do: Give consolidated feedback from all stakeholders in one round per design stage. Don't introduce new requirements, if something wasn't in the brief, raise it as a change request.
- Phase 4: Development
Development is where the design becomes a functioning website. Client involvement is lighter here, but it doesn't disappear.
During development, you should be receiving progress updates and milestone reports. Major decisions, integrations, technical trade-offs, third-party dependencies, should be communicated and approved. And this is not the stage to introduce new design ideas.
What you need to do: Stay available for technical questions. Do not introduce scope changes during development without a formal change request. Begin preparing your content if you haven't already.
- Phase 5: Content population
This phase is consistently underestimated and consistently delayed. Most clients assume content will "just be added" at the end. In reality, content population is time-consuming, requires iteration, and often reveals structural issues that need to be resolved before launch.
Content should be as final as possible before this phase begins. Placeholder text in a live product is not a placeholder, it's an embarrassment.
What you need to do: Start preparing your content during the design phase. Have it ready, reviewed, and approved before development ends.
- Phase 6: Testing and quality assurance
Testing should be thorough, structured, and happen before, not after, you show the site to stakeholders. Cross-browser testing, mobile testing, performance testing, accessibility testing, and content review all belong here.
Client testing happens in staging, not in production. Review carefully and consolidate all feedback in one pass. This is the last gate before launch.
What you need to do: Involve all relevant people in the review. Consolidate feedback. Don't hold back issues you've noticed, this is the time.
- Phase 7: Launch and post-Launch
Launch is a controlled process, not a switch flip. DNS changes, redirect mapping, final performance checks, and a launch-day monitoring window are all part of a professional deployment.
Post-launch, your relationship with the agency should continue, at minimum, a monitoring period where any issues that surface can be resolved quickly.
What you need to do: Be available on launch day. Approve the launch in writing. Share the site.
The quality of your agency relationship significantly influences the quality of the outcome. Here's what makes the difference.
Consolidate your feedback. One email from one point of contact with all feedback included. Not three separate emails from three separate people two days apart.
Respect the process. If your agency has a documented process, trust it. Don't try to accelerate phases that exist for good reasons. Don't skip discovery to save two weeks and then spend six weeks in rework.
Make decisions promptly. Delayed decisions delay projects. If you don't know the answer to something, say so and agree on a timeline for getting to one — don't let the question sit unanswered.
Keep stakeholders aligned. The single most expensive late-stage event in a web project is a senior stakeholder who hasn't been involved saying "that's not what I wanted" after everything has been built. Get alignment before the brief is signed, not after.
Understand your obligations. The project brief should document not just what the agency will deliver, but what you will deliver and when. Content, photography, approved copy, third-party credentials, decision timelines — these are your deliverables. Treat them that way.
Process
What to look for in an agency's delivery process
Not all agencies are equal in how they manage projects. Here's how to assess delivery capability before you sign anything.
Not in vague terms — specifically. What phases does a project go through? What are the deliverables at each phase? How are changes managed? Who is your point of contact and how often will you hear from them?
Agencies that skip discovery are cutting a corner at your expense. A genuine discovery phase is evidence of a team that has learned, through experience, what happens when you don't do it.
Every project encounters changes. The question is whether they're handled with a documented, agreed process or informally in ways that create billing disputes and delays.
An agency that only talks about what they'll deliver, and says nothing about what you need to provide, isn't being complete. A well-run project involves both parties. Good agencies make your obligations clear from the start.
A launch is a beginning, not an end. What happens when something breaks at 11pm before a product launch? Know the answer before you sign.
We're a small studio, which means every project gets direct attention from senior people, not a project manager passing messages between you and a development team you never meet.
Our delivery model is built around a documented process: discovery before design, design before development, consolidated feedback at every stage, and post-launch support that means something. We're direct about what we need from clients, and we hold ourselves to the same standard.
If you want to see what our delivery process looks like in practice, or you're trying to figure out whether it fits what you're planning, we're happy to walk you through it.