The questions that decide whether a build runs to time. Most slippage traces back to one of these rather than to the build itself.
When does the 48 hours actually start?
When we have everything we need from you: final content, brand assets, and access to any accounts or domains the site touches. Not when you enquire, and not when you pay. Our terms state that timelines assume prompt provision of content, credentials, approvals and feedback, and that delays caused by late or incomplete materials extend delivery accordingly. In practice the build is rarely the slow part; gathering the material beforehand is what makes 48 hours achievable at all.
What do I need to have ready before you start?
Final copy for each page in scope, your logo in a vector or high-resolution format, any photography you want used, and login access to your domain and the third-party accounts the site connects to. If you do not have copy, say so during the scoping call so it is planned for rather than discovered on day one. A list of sites you like, and specifically what you like about them, usually saves a revision round.
What if my content isn't ready?
Then the clock has not started, and we will say so rather than quietly counting days against a deadline that cannot be met. Content is the most common reason a build slips. The options are to narrow the scope to pages you can fill now and add the rest later, to build the structure around content you replace before launch, or to include copywriting in the scope. All three are fine. Discovering it on day one is not.
How many rounds of changes do I get?
The number of revision rounds is set in your project document, because it differs by project size. Rounds beyond those included, and changes requested after you have approved something, are quoted separately. Our terms also treat a deliverable as accepted either when you approve it in writing or five business days after delivery if no specific revision requests have been raised, so feedback is worth giving promptly rather than sitting on it.
Who writes the content?
By default you do, because you know your business and your customers better than we do. If writing it is the thing standing between you and a launch, copywriting can be included in the scope and quoted like any other work. What we will not do is fill the site with generic industry filler and call it content, because it reads as filler to your customers and search engines treat it much the same way.
What if I don't like the design?
That is what the design step exists for. You see the structure and visual direction before development starts, which is the cheap point at which to disagree. Tell us what specifically is wrong rather than that something feels off, because specific feedback resolves in one round and vague feedback takes three. If the direction is fundamentally wrong, we would far rather hear it at that stage than after the site has been built.
Do I need to be available during the build?
Briefly, and at predictable points: the discovery call, approving the design direction, and a final check before launch. Between those you do not need to be on hand. What matters is responding within a working day at those three points, because a 48-hour build cannot absorb a two-day wait for an approval. If you will be unreachable, say so when we schedule and we will plan the build around it.
What happens on launch day?
We deploy to your hosting, point the domain, confirm forms and analytics are working, and check the site at real phone, tablet and desktop sizes. Then we walk you through managing it. You finish with the repository, the accounts, and the ability to hand the project to another developer. Unless ongoing support is written into your project document, the engagement ends at handover and later changes are quoted separately.
