Surprises in web projects are almost always expensive and almost always avoidable. A feature that takes far longer than estimated. A dependency nobody noticed until week six. A stakeholder seeing the site for the first time at launch and asking for fundamental changes. None of those happen because the work is impossible. They happen because the project was not structured to surface them early.
Over years of running Drupal projects, some small, some multi-year, some rescues, we have settled on a delivery model that keeps the surprises to a minimum. It is not complicated. It just requires the discipline to ask awkward questions at the start instead of explaining the answers at the end. The aim is simple: bring small decisions forward, while they are still cheap to change.
Phase zero: alignment before the work starts
Before any development, we spend a week or two on what we call phase zero. This is not a discovery phase in the sense of exploring open-ended possibilities. It is an alignment phase, where we answer a few specific questions out loud.
The first part is about what you are trying to achieve: business outcomes, audiences, constraints, deadlines you cannot move, and the people whose approval matters. The second part is about what already exists: the current site, the editorial team, the integrations, the technical debt, and the history of previous web projects.
Two things make this phase concrete rather than abstract:
- We agree on a single person on your side who can approve designs, content models, and feature scope within a couple of days. Slow approvals stretch the timeline, so we identify this person early and agree on how quickly we can expect a response.
- We write down what "done" means as a set of testable acceptance criteria, not a detailed specification. "A non-technical editor can create, edit, and publish a basic page in a few minutes" is testable. "The CMS should be user-friendly" is not.
From those conversations we write a short scope document, usually four or five pages, never a novel, that captures what we agreed, what is explicitly out of scope, and the assumptions behind the timeline. You see it before you sign anything. If something in it is wrong, we rewrite it. Nothing goes into the contract that has not been discussed out loud.
The first working version goes live early
We do not believe in the big reveal. Every project of ours goes to a password-protected staging URL within the first few weeks, with real content, real navigation, and at least a couple of real pages working end to end. It looks rough. It is meant to. Its only job is to give you, your team, and your stakeholders something concrete to react to, at a stage where reacting is still cheap.
The decisions that come out of that first reaction are usually the ones that save the project. "Actually the homepage needs to do this instead." "Our editors will struggle with that structure." "We forgot to mention that we need this content in German." All of those are easy to address early and painful to address late.
A two-week rhythm with one clear ceremony
From that point on, the project runs on a two-week rhythm. Each cycle has a defined scope agreed at the start, a demo at the end, and a short review of what could be improved. At the end of every second Friday we show you what we built, walk through what is still open, and agree the next two weeks of work.
That is the only standing meeting in our delivery process. No daily standups for you to attend. No status report that nobody reads. One focused hour, every other week, with real things to click and real decisions to make. The principle behind it is that every cycle produces something you can see and interact with, not wireframes or architecture diagrams, but working software. In the first cycle that might be a basic site with content types and sample content. By the third cycle it looks like a real site.
Between those meetings, you always have access to the staging site. You can share it with anyone on your side, content authors, marketing, legal, the board, and collect feedback at your own pace. We prefer written feedback in one place, because it tends to be more precise than what comes out of a call, but we take both.
A scope pressure valve
Every project experiences pressure on scope. You see the site taking shape and think of additional features. A stakeholder who was not involved at the start arrives with new requirements. Priorities shift. This is normal, and it does not have to derail the timeline.
We handle it with a simple rule: anything can be added, but to make room, something of similar size comes out or moves down a prioritized backlog. Every new request goes onto that backlog. At the start of each cycle, we pull in the highest-priority items that fit. Lower-priority items wait.
It is not rigid. If a new requirement is genuinely critical, it moves to the top of the list. But the act of prioritizing forces the trade-off into the open. "Is this more important than the search feature planned for the next cycle?" is a question that keeps scope honest without anyone having to police it.
Launch is a checklist, not an event
A launch that feels dramatic is a launch that was not prepared enough. By the time we push the button, the new site has been running on production infrastructure for a while, every major URL has been verified, every integration has been tested end to end, and a rehearsed rollback plan is sitting in a shared document. The actual go-live is a short cutover window, somewhere between fifteen minutes and two hours depending on the complexity, and it is boring by design.
The day after launch is not "handover." It is the first day of support, using the same people, the same tools, and the same clarity as the build. The phone number does not change.
The first weeks after launch are part of the project
We plan the first weeks after launch as part of the project, not as an afterthought. That includes watching how the site behaves under real traffic, fixing the issues that only appear with real users, training editors on workflows they have not used yet, and making small adjustments based on real usage data.
Projects that end on launch day leave you alone at the moment you most need support. Treating those first weeks as part of the work tends to produce better results and longer relationships.
Why this works
None of these practices is revolutionary. It is the disciplined execution of basic project-management principles: define outcomes, make progress visible, bring decisions forward, manage scope explicitly, and stay with you through launch and the weeks after it.
The projects that fail are rarely the ones with hard technical problems. They are the ones where someone assumed something that was not true, and nobody found out until it was expensive to fix. This delivery model exists to surface those assumptions as early as possible and turn them into decisions while they are still cheap. The rest of the project, we get to spend on craft.
If you have a project in mind and you are tired of surprises, tell us the shape of it. We will tell you what the first few weeks would look like, and you can decide from there.