Table of contents
Custom website projects rarely slip because developers cannot build. They slip because the handovers are undefined: design starts before requirements close, development starts before design is locked, and every problem surfaces a week before launch. Six milestones with named deliverables spread the risk across checkable points.
1. Six Milestones
| Stage | Deliverable | Acceptance | Usual delay |
|---|---|---|---|
| Requirements | Section tree, content list, roles | Every section has an owner | Client not aligned |
| Prototype | Wireframes, interaction notes | Key paths clickable | Pages added mid-way |
| Visual | Comps, component standard, narrow screens | Three widths covered | Endless first-screen changes |
| Build | Pages, admin, interfaces | Fidelity to design | Content not ready |
| Test | Defect list, compatibility report | Works on main browsers and phones | Empty pages |
| Launch | DNS, 301 mapping, backup | All old URLs reachable | Filing or certificate delays |
Requirements is the stage most often compressed. One meeting replaces a proper brief, and the prototype stage absorbs the rework. A workable rule: for each section, the client writes one sentence on who should do what there. Sections that cannot produce the sentence get cut.
2. Why the Prototype Matters
A prototype is not decoration; it fixes structure. How many entries on the home page, how specifications are organised, where the enquiry form sits — these decide everything downstream.
Produce two versions: one organised around existing content, one around the ideal business logic. The gap between them is usually the content that still needs writing.
3. Aligning Design and Build
Comps should cover desktop, tablet and phone. Desktop-only designs get invented at build time, and the result drifts from intent.
Component standards matter more than individual pages. Buttons, forms, cards and tables specified once can be reused; without that standard, every new page restarts the conversation. Missing standards are the main source of rework in custom website service projects.
4. Content Preparation
A custom build typically runs thirty to eighty pages, each needing copy, images and specifications. If content starts after development finishes, the project stalls with empty templates.
Start content work as soon as the prototype is signed off, assign an owner per page, and set dates. Content quality drives SEO directly — specification pages especially need substance, not a single photograph.
5. Test and Launch Checks
Five test items: forms submit with clear feedback, specification tables scroll on phones, images are compressed, every page has its own title and description, and there are no broken internal links.
At launch, handle legacy URL mapping. If pages with existing rankings return 404, accumulated search value is lost. Export the old URL list, map each one to its new equivalent, and implement 301 redirects.
6. FAQ
How long does a custom build take? About eight to twelve weeks for a thirty-page site, from requirements to launch.
Can requirements change during the build? Small changes yes; structural changes belong in the next phase or the schedule slides.
What happens after launch? Submit the sitemap, watch crawl errors for two weeks, and adjust page structure from the data.
Related
- See also: deciding between a custom site and a template
- See also: how a website quote breaks down
GrowLab focuses on integrated content marketing, offering brand strategy, website development and search marketing (SEO/GEO) as a full-chain service. Contact us for an assessment of your own promotion plan.
Need a professional growth plan?
Add our WeChat for a tailored strategy and annual quote.
Contact Us