Web projects rarely run late because programming turned out harder than expected. They run late because decisions queue up behind one busy stakeholder, because content arrives at the last minute, and because scope was written as a list of pages instead of a description of behaviour. After nearly two decades of agency work, those three causes account for most of the slippage we have ever seen — on our side of the fence as well as the client’s.

That is good news, because all three are manageable — if you set the project up for it.

Discovery is where the budget is won or lost

Before we price anything significant, we run a discovery phase: map the user flows, inventory every integration ("it just needs to sync with our ERP" is a sentence that has ended friendships), audit what content exists versus what must be produced, and write down the risks we can already see. The output is a scope document concrete enough to price honestly and — just as important — to phase. Anything still vague gets named as vague, with a plan for when it will be decided.

Skipping discovery does not save its cost. It just moves that cost into the build phase, multiplied.

Fixed price or time and materials — the honest trade-off

Fixed price buys you certainty, and you pay for it twice: once in the risk premium any sane vendor adds, and again in change-control friction every time reality differs from the document. Time and materials buys flexibility and requires trust, which is why it only works with full visibility — weekly demos, an open backlog, itemised time. We run both models; as a rule of thumb, fixed price suits well-defined first phases, and T&M suits everything that follows, once both sides know how the other works.

The cadence that keeps projects honest

  • A demo of working software on a staging server every week or two — progress you can click, not a percentage in a slide.
  • A single shared backlog, so "could we also…" requests land somewhere visible and get prioritised against everything else.
  • A decision log — one line per decision, dated. Saves hours of archaeology three months later.
  • An agreed definition of "done" that includes testing and content, not just code merged.

What we need from you — said up front because it is kinder

Every agency knows this and few say it: projects stall on the client side at least as often as on the development side. The pattern is so consistent that we now build it into kickoff. You will need a single decision-maker who answers within an agreed time (two business days is realistic), a named owner for content who treats texts and imagery as a workstream with deadlines — content is the most common launch-blocker we see — and real users with a few hours for acceptance testing before launch, because the worst person to test a system is the team that built it.

Testing and acceptance

Acceptance testing works when it is tied back to the original scope: a script of scenarios per user role, walked through on staging, with findings sorted into "defect", "change request" and "works as specified, we want it different". That last category is where fixed-price projects go to argue, which is exactly why the scope document from discovery matters. Our web application testing checklist covers the technical layers underneath — browsers, devices, performance, security.

Launch is a phase, not a date

The go-live itself should be an anticlimax: DNS, redirects (every old URL mapped — we covered why in our website migration guide), analytics, backups, monitoring. The two weeks after launch are part of the project: real traffic always surfaces something, and the team that built the system should be the one watching it. Then it shifts into a maintenance rhythm — updates, patches, small improvements — rather than ending.

A note on working with an external team

Everything above applies double when the development team is not in your building. What makes the difference in practice: a real working-hours overlap (our Riga office shares two to seven hours with the whole of Europe and the UK), fluent written English, and the demo cadence above — because with an external partner, visible working software is the only progress report worth anything. We wrote more about the selection side in how to choose a web development company.

We have managed projects this way at iConcept since 2007 — over 200 clients in more than ten countries. If you have a project brewing and want a second opinion on its scope before you commit to anyone, send it over; the conversation costs nothing.