Web projects rarely slip because the engineering was hard. They slip because copy arrived in week four, because nobody could say who signed off the design, or because a CMS was chosen after the templates were built. Almost every delay is a decision that was deferred.
So the schedule below is mostly about forcing those decisions early, and being explicit about what is fixed and what is not.
The stack, decided before kickoff
- Next.js App Router with React and TypeScript in strict mode. Static rendering wherever the page allows it.
- Tailwind for styling, with design tokens defined once so the palette cannot drift page to page.
- Vercel for hosting, with preview deployments on every branch so review happens on a real URL rather than screenshots.
- Content in typed files or a headless CMS, decided in week one, never after templates exist.
We do not re-litigate this per project. A stack argument in week one is a week you do not get back, and the decision rarely changes the outcome for a marketing site or a web app of this size.
Week one: decisions and the shell
Sitemap agreed, every page listed. Design direction approved on two or three key pages, not all of them. Repo set up, deployment pipeline live on day one so there is never a big-bang launch.
The important output of week one is not visible progress. It is that nothing structural is still open.
Week two: build
Templates get built against real content, not lorem ipsum. This is the single highest-leverage rule in the whole process, because placeholder text hides every layout problem that real copy will expose: headlines that wrap to three lines, empty states, lists with one item.
Design that only works with placeholder text is not finished design. It is a mockup that has not met its content yet.
Everything is reviewed on a preview URL, on a phone, by the person who has to approve it. Feedback lands as comments on a live page rather than as a document of screenshots.
Week three: the unglamorous part
This is the week that gets cut when a project is late, and it is the week that determines whether the site is actually production-ready.
- Responsive checks at mobile, tablet and desktop on every page, not just the homepage.
- Metadata, canonical URLs, Open Graph cards, sitemap, robots. Structured data where it earns rich results.
- Security headers, a Content Security Policy, and rate limiting on anything public that sends email or writes data.
- Real performance measurement on the deployed URL with a cold cache, not a local dev server.
- Forms tested end to end, including the failure path. A form that silently drops submissions looks identical to one that works.
What makes it slip anyway
- Copy that is still being written in week three.
- More than one approver, without agreement on who decides.
- Scope added mid-build. New pages are fine; they move the date, and we say so at the time rather than absorbing it silently.
- Third-party access requested late. DNS, analytics and payment accounts should be sorted in week one.
The part that matters
You get a fixed scope and a written timeline before anything starts, and you own the repo, the hosting account and the domain throughout. If the schedule moves, it moves because a decision changed, and you will know on the day it happens rather than at the end.