The pattern is consistent enough to plan around. Technical work is estimable because it is bounded, and the estimate is usually close. What is not estimable is how long somebody takes to write the descriptions of their services, gather photographs, decide on a price, or obtain approval from a partner who was never in the conversation. Those tasks look small and reliably consume weeks.
Content is the largest single cause. Businesses underestimate it because writing about yourself is harder than it appears, and because the request arrives alongside running the business. A project waiting on five service descriptions is a project waiting indefinitely unless somebody scheduled the writing, and the request usually goes out without a date attached.
Decisions are the second cause and they are frequently the same problem in a different form. A choice that requires you to establish what you actually charge, or who you are actually for, is not a quick answer. It is a piece of thinking that was deferred, and it surfaces during the build because the build cannot proceed without it.
Third parties add delay that nobody controls. A hosting provider processing a transfer, a payment processor completing verification, a domain propagating, a supplier providing an integration. These are usually short and occasionally are not, and building the schedule as though they are instant is what turns a two day wait into a missed date.
Scope changes cause less delay than people assume when they are handled explicitly and considerable delay when they are not. A request agreed at the time, priced, and added to the timeline is a manageable adjustment. The same request absorbed silently, repeated four times, is why a project quietly runs three weeks over with nobody able to identify when it happened.
The remedy is unglamorous and it works. Decide at the start who supplies what and by when, in writing. State which items block which stages, so the consequence of a delay is visible rather than discovered. And send the content request in week one rather than at the point it is needed, because the lead time on somebody writing five paragraphs is the actual variable.
Build a buffer into the quoted date rather than quoting the best case. Every project meets something unexpected, and a date that assumes nothing goes wrong will be missed. Quoting a date you can hold comfortably and delivering earlier is a considerably better pattern than the reverse.
Then say something when a date is at risk rather than when it has passed. Almost every complaint about a late project is really a complaint about finding out late, and a message a week beforehand converts a failure into a scheduling conversation.
Watch for the delay nobody names, which is a decision waiting on somebody who was never in the conversation. A partner, a spouse, or an investor whose approval is required but who has not seen anything is a common and invisible cause, and identifying who genuinely needs to sign off at the start prevents a fortnight disappearing at the end.
Track where the time actually went afterward rather than only noting that it ran over. Most businesses assume the build was slow and the record usually shows several days of waiting distributed across the project. That distinction determines whether the fix is a different provider or a different process.
Separate the deadline that matters from the ones that do not, since projects frequently carry a real external date such as an event or a lease and several internal ones that were arbitrary. Knowing which is which lets everybody protect the one that counts rather than treating all dates as equal.