What goes wrong
What goes wrong with custom website projects?
Most website projects fail on content and approvals rather than code. The expensive failures are the silent ones: a form that stops sending, tracking that was never verified, and a site that renders for humans but returns an empty page to search engines and AI assistants.
The project stalls on content, not code
This is the single most common cause of a late website. Development finishes and the project waits weeks for copy, photographs, staff bios, or a decision about which three services go in the navigation.
The fix is unglamorous: agree at scoping who writes what and by when, and treat missing content as a scheduling risk from day one rather than a surprise at week four.
Scope drifts one reasonable request at a time
No single change breaks a build. Thirty of them do. Each addition sounds small in isolation, and the cumulative effect is a project that is two months late with nobody able to point at the decision that caused it.
A fixed scope with an explicit change process is not bureaucracy. It is the only mechanism that makes the cost of a change visible at the moment somebody asks for it.
The silent failures are the costly ones
A website can look perfect and be quietly broken in ways nobody notices for months, because nothing errors and no customer complains — they just leave.
- The contact form submits, shows a success message, and sends nothing. Nobody tests it after launch, and the first sign is a quiet quarter.
- Analytics were installed but never verified, so the numbers everyone reports from are wrong.
- Conversion tracking counts page views instead of leads, and the ad spend is optimised against the wrong signal.
- A page returns "200 OK" for URLs that do not exist, so search engines treat invented addresses as real pages.
- The site renders entirely in the browser, so search engines and AI assistants receive an empty container.
The invisible-to-machines failure
This one deserves its own heading because it is now the most consequential and the least discussed. Many modern sites build their content in the visitor's browser rather than sending finished HTML. A person sees a normal page. A crawler that does not run JavaScript receives almost nothing.
We measured this across 1,348 recently funded companies and found 8.7% serving a shell — the median one returning 55 characters of text where the rendered page had 5,358. It affects sites on modern frameworks far more than sites on hosted builders, which means the businesses with the most technical resources are the most exposed.
You can check your own in a minute: fetch your homepage without executing JavaScript and read what comes back.
How to avoid all of it
Write the content plan before the design starts. Fix the scope and price changes explicitly. Test the form by submitting it and watching for the email. Verify tracking fires rather than assuming it does. And check what a machine receives before you celebrate the launch.
Common questions
- Why do website projects run late?
- Overwhelmingly because of content and approvals, not development. Copy, photography, and decisions about structure are the usual bottleneck, and they sit on the client side.
- How do I know if my website is broken?
- Submit your own contact form and confirm the email actually arrives. Check that analytics recorded your visit. Then fetch your homepage without JavaScript and see whether any of your content is in the response.
More on web design & development
Want this looked at for your business?
Tell us where you are trying to get to. If the honest answer is that you do not need us, we will say so.