Website Development Process | Ship On Time

The website development process that works is seven phases: discovery, signed scope, design, foundation, build, QA, and launch — with dates committed in week one and a demo every Friday. Projects run 3 to 14 weeks depending on scope. Below is the actual SOP we use, including the failure modes it prevents.

Want a number before the process? Run the instant quote calculator for a fixed-price estimate, or read how core web development services engagements are structured.

Why Do Most Website Projects Blow Their Deadlines?

The data is brutal. PMI's Pulse of the Profession research found that organizations waste 9.9% of every project dollar through poor performance, 31% of projects never meet their original goals, and 48% are not completed on time. As PMI's former CEO Mark A. Langley put it: "Project management is the driver of strategy, but organizations are failing to bridge the gap between strategy design and its delivery." (PMI Pulse of the Profession 2018)

Web projects fail in specific, repeatable ways: discovery gets skipped to "save time," the scope of work has loophole language, design and build drift apart, QA gets compressed into the last 48 hours, and launch happens on a Friday afternoon. A real process exists to make each of those failures structurally impossible. That is what the seven phases below do.

If you are comparing how agencies structure engagements, read fixed-price vs retainer vs time-and-materials — the pricing model you choose shapes the process you get. And if a current project is already off the rails, web development consulting includes rescue diagnostics.

What Happens in Discovery — and Why Can't You Skip It?

Discovery is the phase where the project gets understood before it gets built. For projects above roughly $30K it runs one to two weeks; for smaller builds, two to three days. The deliverables are concrete: stakeholder interviews, an audit of the current stack if this is a migration, a route map of every page and template, a data model sketch, a list of third-party integrations, and a hosting plan. The output is a written scope of work the client signs.

The failure mode discovery prevents is the week-six surprise: the missing requirement that surfaces when it is ten times more expensive to add. Every skipped discovery interview becomes a change order later. The discovery investment pays for itself in change orders you never have to write.

A useful test: if an agency will quote you a fixed price without asking about your integrations, content, and hosting, they have not done discovery — they have done guessing. For rapid engagements, our two-week website sprint timeline shows how a compressed discovery still covers the essentials. Complex or regulated builds should start with web development consulting before any build commitment.

How Does a Signed Scope of Work Prevent Scope Creep?

The scope of work is the contract, and it must read like one: named features, named team members, calendar dates, a USD price, a change-order pricing structure, and IP transfer terms. Both sides sign it, and a 50% deposit clears before design starts. Vague scope language — "additional features as needed" — is the loophole agencies use to bill more later. Insist on explicit scope.

The change-order clause is the part most clients skip and most disputes are about. A fair clause states how new requirements are priced, the minimum billable unit, and whether post-signature work carries a rate markup. Read it before signing, not after the first "small addition" appears mid-build.

Scope creep without change orders is one of the two biggest project-failure modes we have seen in over a decade of shipping. We have watched six-week SOWs become fourteen-week deliveries because small additions accumulated with no written control. The process answer is mechanical: every out-of-scope request gets a written change order — price and timeline impact stated — before any work begins. No exceptions, no matter how small the ask sounds.

Compare engagement models in fixed-price vs retainer vs time-and-materials. For a number on your specific scope, the quote calculator gives an instant fixed-price estimate.

What Do the Design, Foundation, and Build Phases Actually Look Like?

Design (5–10 days). Figma at component level: design tokens first, then primitives, then composed routes. Clients review at component granularity, not as page-level mockups — reviewing components catches inconsistency that page mockups hide. Output: a signed-off Figma file, accessibility annotations, and responsive variants. The classic failure here is designing pages in isolation without designing the underlying system; that inconsistency is far cheaper to prevent in design than to repair during the build.

Foundation (3–5 days, parallel with the end of design). Repository, CI/CD pipeline, environment scaffolding, layout primitives, the font and image pipeline, schema components, and observability hooks. This is the unglamorous infrastructure, completed up front so it never blocks the rest of the build. Deferring infrastructure is how sites accumulate technical debt that is visible on day one in production.

Build (3–6 weeks for typical scope). Routes are built in priority order, with a demo every Friday. A Lighthouse performance budget is enforced in CI so speed does not slide as features ship. Issues are tracked in Linear or the client's tracker, and every pull request gets senior review before merge. The failure mode is feature creep without change orders — handled by the rule from the previous section.

Performance budgets are not vanity metrics. Google's research shows 53% of mobile visits are abandoned when a page takes longer than three seconds to load, and bounce probability rises 32% as load time moves from one to three seconds. Enforcing the budget in CI is what keeps those numbers from drifting. Engagements run through core web development services; compressed timelines follow the two-week sprint timeline.

What Does QA Cover Before Launch?

QA runs five to ten days and covers six areas: cross-browser testing (Chrome, Safari, Firefox, Edge); mobile testing on real devices across seven viewport widths from 320px to 1920px; an accessibility pass with axe-core plus manual screen-reader testing; schema validation in Google's Rich Results Test; hreflang verification for bilingual sites; and real content loaded into the CMS — by the client, or by us as a scoped line item.

The failure mode is skipping accessibility "until later." There is no later: litigation exposure is real, especially in California and New York, and retrofitting accessibility into a finished build costs multiples of building it in. A WCAG AA baseline is non-negotiable, and the EU's accessibility rules now extend the same pressure to European-facing sites — see our European Accessibility Act readiness guide.

The other classic QA failure is client-side content delay: the site is ready and the copy is not. We have shipped pages with placeholder content because final copy never arrived. The process answer is to put content delivery in the SOW with calendar dates, exactly like any other deliverable. Pre-launch technical verification is also available as a standalone technical SEO audit.

What Does "Done" Mean in the Contract?

"Done" is a checklist in the SOW, and the second invoice does not issue until every item passes:

If any item fails, we keep working until it passes. That is the entire commercial logic of a fixed-price process: the agency's incentive is to finish, not to bill hours.

Launch itself (2–3 days plus 30 days of support): DNS cutover, analytics wiring, a 301 redirect map for migrations, and full transfer of the repository and credentials — then a 30-minute Loom hand-off recording and 30 days of included bug fixes. Launches happen Tuesday or Wednesday morning, never Friday afternoon, so the team is available all week for anything that surfaces. The full transfer checklist is documented in the website handover ownership checklist, and ongoing engagements start from core web development services.

FAQ

How long does a typical website build take?

Three to fourteen weeks depending on scope. A focused marketing site with clean content readiness lands around three to five weeks; a custom application with integrations runs eight to fourteen. The honest answer for a serious business website, including testing and revisions, is six to ten weeks total. Anyone promising three weeks regardless of scope is selling templates or change orders.

What causes the most common project delays?

Missing client content is number one — sites are delayed by absent copy roughly twice as often as by engineering. Number two is scope creep without change orders: small additions that accumulate silently. Both are process problems with process answers: content delivery dates in the SOW, and written change orders before any out-of-scope work.

Do you work Agile or Waterfall?

Neither, strictly. The process is phased with fixed gates — discovery, signed scope, design, foundation, build, QA, launch — but the build phase runs in weekly iterations with Friday demos. PMI's research shows that organizations using a formal delivery approach, agile or otherwise, meet their goals far more reliably than those improvising; the methodology matters less than the discipline. (PMI)

What happens if we need changes mid-build?

You get a written change order stating the price and timeline impact, you approve it, and then the work happens. Small requests follow the same path as large ones — that uniformity is what keeps a six-week project from becoming a fourteen-week one. The change-order pricing structure is agreed in the SOW before the project starts, so there are no surprises.

Who provides the website content?

You do, on a calendar agreed in the SOW — or we scope content production as a separate line item. What does not work is "we'll send copy when it's ready" with no date; that is the single most common cause of stalled launches. We build the site to receive copy; the copy itself needs an owner and a deadline.

What happens after launch?

Thirty days of bug fixes are included, with a defined escalation path. After that, maintenance is available in fixed 90-day blocks — never auto-renewing retainers. You own the repository, the hosting accounts, and the credentials from day one, so you are never locked in. See exactly what transfers in the handover checklist.

Start With a Number, Then a Process

A good process only matters if the price is honest first. Run the quote calculator for an instant fixed-price estimate — then submit your project brief and we will return a scoped proposal with calendar dates within 24 hours.