What Happens Between the Decision and Launch: Website Project Steps

The contract is signed, the upfront payment is made, and then silence sets in. The company waits for the website to appear, the developer waits for copy and photographs, and neither of them thinks they are waiting through the same week, so a month later both sides are dissatisfied and neither has done anything wrong; it is simply that nobody had written down who delivers what, and by which date.

This article is about what happens between the decision and launch, and mainly about how the work is divided between the two sides, because that is what decides the deadline far more often than the speed of the build or the technology chosen. We have written separately about the mistakes clients make, in the article on ten mistakes when commissioning a website, and we do not repeat them here. There are likewise no prices here, and no comparison of doing it yourself against commissioning it, because both of those belong to other articles; the subject is only the sequence, and what has to be prepared at each step.

Discovery is not the start of the build

Almost every development process starts with a stage called discovery or research, and this is the stage most often misunderstood, because the client treats it as a formality before the real work. Nielsen Norman Group, which uses the term professionally, defines it as a preparatory phase that researches the problem itself and its context, frames what can be solved and gathers enough evidence to know what to do next, and it stresses specifically that discovery does not involve testing solutions.

In the public sector this idea is formalised even more strictly, because the UK Government Digital Service Manual distinguishes five phases — discovery, alpha, beta, live and retirement — and of discovery it simply says: you do not start building the service in this phase. At the end of the phase the team decides whether to go on or to stop, and the manual itself does not impose a fixed duration, although it notes that in practice this phase usually lasts four to eight weeks.

A caveat has to be made at once, otherwise a wrong picture forms: that manual describes the lifecycle of a government digital service, not a ten-page company website, and transferring its timescales onto an ordinary development project would be misleading. What is valuable in it is the principle, not the calendar: before the build there is a phase whose purpose is to understand the brief, and the outcome of that phase can also be a decision not to build at all.

In a practical project this phase usually takes the form of a conversation about processes, user roles and scope, and its result is a written plan, not a design sketch, even though the client often wants to see the latter. Two direct consequences follow for the client, and the first is that without a written discovery result there is later simply nothing against which to compare what was built, so a dispute about scope stays without evidence for either side. The second is that this is the phase in which changing your mind is cheap, whereas after the build has started every change also costs what has already been built and will have to be redone.

The prototype is the cheapest place to change your mind

Between the plan and the build there is a stage that clients sometimes treat as an unnecessary expense, and it is exactly the stage that most often saves money. A prototype is a clickable version of the site without the real code, in which you can walk through the main paths and see where something is missing, and its only purpose is to let you change your mind while changing your mind is still cheap.

The UK government manual puts this thought unsparingly, writing of the alpha phase that you should expect to throw away any code written in this phase and a large part of the ideas you test, and that is not a contradiction of good work but its point: throwing away a prototype is cheap, throwing away a built system is not. At the scale of a company website the same principle applies, only smaller, which is exactly why we prepare the prototype before the first line of production code.

A practical requirement follows for the client, and it is worth saying out loud: approving the prototype is not a formal box-ticking exercise, but the only moment when changes cost only time, so that is the moment to bring to the table the people who will later say that nobody asked them anything. After the prototype is approved, every such conversation already costs what has been built.

The other thing worth doing at this stage is draft content, because a prototype filled with placeholder text is easy to approve and you then discover that the real copy does not fit, or that a section which was meant to hold one paragraph actually needs three. If the copy is not ready yet, it is worth putting drafts of roughly the right length into the prototype, because length changes the layout more than any colour.

Most of the waiting happens on the client's side

A project's deadline is usually set not by how fast the build runs, but by how quickly the client delivers content, and in our experience that is the most common cause of delay. There is no independent study of this in the industry with a methodology and a date, so we say it as our own experience and do not pretend that percentages stand behind it.

Another caveat is worth making here, otherwise this section would sound like shifting the blame: in the public sector, content production is a separate profession and a team role, and in the government manual the content designer is listed among the skills needed, but it does not follow from that that in an ordinary development project the developer writes the copy. Who writes it is a matter of agreement, and the only wrong answer is that nobody has settled it before the work starts.

Concretely, there are usually five deliveries on the client's side, and each of them is worth putting a specific date on already in the contract, rather than leaving it at the level of a conversation. The first is the copy, and it is the heaviest of all, because it cannot be written in one evening and it is usually written by someone for whom writing is not part of the main job and who has to squeeze it in among other duties. The second is photographs and logos in vector format, the third is access to existing systems if something has to be moved from them, the fourth is approvals at defined points in the project, and the fifth, which is not a document but a person, is one approver who is allowed to say yes on the company's behalf.

This fifth is the one most often missing, and its absence costs more than any technical complication: a project in which approval is given by a committee drags on not because anyone works badly, but because every approval requires a meeting, meetings happen once a fortnight, and between them the work simply stands still. If the company has several stakeholders, the right solution is not to try to shut them out, but to agree which of them is the final decision-maker and within what time an answer is expected.

The United Kingdom has no equivalent rule naming the head of an institution as the owner of the content on its official website. No such statute binds a private company, but the idea is the same and can be taken on voluntarily: content responsibility belongs to the client, and it has to be placed on a named person.

Images are a rights question, not a files question

Photographs are where clients act with the best of intentions and still create a risk, because a file that is on the computer is taken to be a file that may be used. Under the Copyright, Designs and Patents Act 1988 a photograph is a protected artistic work, copyright arises the moment the work is created without any registration, and the author is the person who took the picture.

The conclusion that surprises almost every company follows from that: paying for a photoshoot does not by itself mean the client has acquired the copyright. The photographer remains the author. The right to be identified as author exists, but under the Act it must be asserted and it may be waived in writing. Economic rights pass only by licence or assignment, and for a company that plans to use the photographs on a website, on social media and in print that means the licence or assignment must list exactly those uses.

It is the same with stock libraries, only there the terms are written clearly and publicly, so they can be read before buying: the Shutterstock Standard License grants a non-exclusive, non-transferable right to use the image, including on websites, and the same page states that the customer does not obtain ownership or exclusive rights. The same page has restrictions people often breach by accident: the image must not be passed on, must not be used as a logo or trademark, and images marked for editorial use only must not be used commercially. A company that has bought a Standard License has acquired the right to use the image on a site, not a file it can hand to the developer as its own property.

There is another case that is almost always misunderstood. Section 62 of the Copyright, Designs and Patents Act 1988 allows a photograph of a building, and of a sculpture, a model for a building or a work of artistic craftsmanship permanently situated in a public place or in premises open to the public, and it also allows copies of that photograph to be issued and communicated to the public. The exception is not limited to personal, news or non-commercial use, so a photograph of a building in a public place on a company website is covered. The section does not cover two-dimensional works: a photograph of someone else's photograph or painting on public display still needs permission.

Finally, people in photographs are a personal-data question, not merely a matter of courtesy: under UK GDPR a photograph of an identifiable person is personal data, and the legal basis may be consent or a contract; consent must be freely given, specific, informed and unambiguous. The practical point that matters most is that consent can be withdrawn at any time, and after withdrawal the images have to be taken down from the public environment, so team photographs on a website have to be arranged so that a departing employee does not become a problem.

The staging environment, and the mistake made with good intentions

Before launch the work takes place in a separate environment, and that is needed for a simple reason: the client has to see a real page in a real browser, not an image from a design tool, and mistakes have to be caught in a place where customers cannot see them. The only question is how this environment is closed off, and this is where a mistake is made that looks correct.

The common solution is to write a disallow into robots.txt, and it does not do what people think it does, because Google's documentation states it directly: this file tells crawlers which addresses they may access, and it mainly serves to avoid overloading a site with requests, but it is not a mechanism for keeping a page out of Google. To keep a page out of search results you have to use a noindex directive or protect the environment with a password.

Next comes the detail that makes the two methods together work worse than each one separately. A noindex directive works only if the page is crawlable, because the crawler has to read it; if the page is disallowed in robots.txt, the crawler will never see the directive, and the page can still appear in results, for example if links lead to it from elsewhere; moreover Google does not support a noindex directive in robots.txt at all.

There is also a second reason why this is not a theoretical problem: if the staging environment contains the same content as the finished site, the search engine can treat that environment as the main version and show it in results in place of your site, which means a visitor lands on an unfinished page with test data. This mistake is hard to notice, because the site itself works perfectly and the problem is visible only in the search results.

The practical answer is therefore simple, and it is worth asking for it directly: protect the staging environment with a password. That is the only solution that, independently of crawler behaviour, ensures an unfinished site appears nowhere, and at the same time it removes the second risk, thought about less often: that a staging environment with the same content can be treated as the main version and start competing with the real site.

Which choices after launch cost the most

Most decisions in a website project can still be changed after launch, and that is worth saying clearly, because clients often worry precisely about the things that are later the easiest to change. Colours, layout, the template, the copy and even where pages sit in the menu can be changed at practically any moment, and that costs only hours of work, not a rebuild, but two things are different, and those are the ones worth thinking about before launch, while the change still costs nothing.

The first is the address structure, and it becomes a decision at the moment the pages are indexed and inbound links point to them, because from that moment changing addresses is no longer a visual choice but a site move, which Google describes as a separate procedure with its own requirements. You have to use server-side permanent redirects and keep them for at least a year; Google also warns against changing addresses, the content management system and the layout in one go, and for an ordinary company site it recommends moving all addresses at once rather than in stages. The same page has a useful note that reduces the fear: permanent redirects do not themselves cause a loss in PageRank, although rankings may fluctuate for a while.

The second is the domain itself, because a domain change is the same site move with all of its requirements, only at a larger scale, and everything already printed on business cards and letterheads is added to it. We have written about whose name the domain should be registered under in the article on ten mistakes when commissioning a website, and we do not repeat it here; here it is only worth saying that the choice of domain is one of the few decisions that later costs more to change than to get right the first time.

There is one procedural detail worth knowing so that you do not request it without need: the Change of Address tool in Search Console is submitted only when the domain or subdomain changes; it is not intended for a move from an insecure to a secure connection, or for a choice between an address with and without the www prefix on the same domain, and there the right redirects are enough. For a company that means most changes are settled on the server side, not in a form.

In practice one recommendation follows before launch: if the old site already exists and it has visitors from search engines, then a list of addresses with redirects to the new addresses has to be prepared before publication, not after someone notices the drop in visits. This list is also one of the jobs the client can prepare themselves, and which, if nobody prepares it, becomes a week of search work after launch.

Accessibility: who has a duty, and who does not

Public-sector bodies in the United Kingdom have had an accessibility duty for several years; a private company is not under a listed-services accessibility act of the European shape, because the UK did not adopt the European Accessibility Act. What binds a private service provider is the Equality Act 2010. An informative company website that sells nothing is not thereby off a list, because there is no such list in UK law. The market often confuses the public-sector regulations with the Equality Act, and that confusion costs.

The first regime is the public sector, and it has been in force for several years, so for public bodies it is not news. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public sector bodies to make their websites perceivable, operable, understandable and robust, and to publish an accessibility statement; conformity with WCAG A and AA is the presumption. Those regulations bind public sector bodies and do not apply to an ordinary private company, even though the market sometimes offers them as a general requirement.

The second regime is newer in the EU, and that is where most of the misunderstanding comes from, because its in-force date has been widely advertised and its scope has not: the European Accessibility Act applies in member states from 28 June 2025 to a listed set of services. The United Kingdom did not adopt it. That date does not mean that from then on every company website in the UK has to meet an accessibility standard, and this over-broad claim is the one the market repeats most often, sometimes together with an offer to fix it.

What does bind a private UK service provider is not a list of services. Section 29 of the Equality Act 2010 says a service provider concerned with the provision of a service to the public, for payment or not, must not discriminate; section 20 imposes an anticipatory duty to make reasonable adjustments. An informative company website that is part of providing a service to the public can still face that duty. It is not decided by whether the site is an online store, a bank, a transport operator or a book platform.

There is also no microenterprise exemption of the European Accessibility Act's shape, because that Act is not UK law. The Equality Act has no headcount-and-turnover get-out, so the sentence that small companies are exempt from accessibility law is not correct here either.

The practical conclusion for the client is short: if you are a public body, accessibility requirements have to be written into the specification already, because later they mean a rebuild. If you are a private service provider, the duty is reasonable adjustments under the Equality Act, not a listed-service test, and there is no microenterprise get-out of that Act; it is still an argument for making the page usable with a keyboard and readable with a screen reader, because some of your customers use them regardless of the law.

How long all of this takes

The timeline question is the one the client wants answered first, and it is also the one to which an honest answer is the hardest to give. The timelines published in the industry almost always come from developers' own pages, where they serve as a promise of speed, so they cannot be used as an independent data point, and we did not find an independent study with a methodology.

It is therefore more accurate to talk about what sets the deadline than to look for an average number that would not fit any particular project anyway: the deadline is set by scope, the speed of approvals and the readiness of the content, and in the last two of these three the decisive influence is on the client's side. A project in which the copy is ready before the start and decisions are taken by one person runs considerably faster than a project of the same scope without those two conditions, and that is a difference that can be measured in weeks.

Our own published timeline on the WordPress development page is four to ten weeks, and that applies to an ordinary company site, while for more complex projects it is longer, and for e-commerce longer still, but for a particular project the only useful timeline is the one that follows from the scope, not from an average.

There is another way of looking at this question, and for the client it is usually more useful than any number: ask the developer not how long it will take, but which weeks depend on you and which on them. The answer to that question is checkable, and it immediately shows how much of the deadline you control.

And one more thing that affects the deadline more than it looks is scope growing as the work proceeds: each new suggestion is small and justified on its own, but together they move the handover date, and it happens unnoticed, because none of them ever looks like a decision to extend the project. The only thing that helps against that is an agreement that changes outside the original scope are written down separately together with their effect on the deadline, rather than included in silence.

What to agree before the work starts

Before the first invoice line it is worth talking through and writing down a content schedule with dates: who writes the copy, by which date it is in the developer's hands, and what happens if it is late, because without this clause a delay always looks like the developer's fault.

The second is the origin of the images and the rights, namely where the photographs come from, what licence they have, whether the licence mentions use specifically on the site, and whether the people in the images have given consent which they can later withdraw. The third is one approver with a first name and a surname, and an agreement on how many working days an answer to an approval request is expected in, because without a deadline an approval is not a plannable quantity.

The fourth is a staging environment protected with a password, not with a disallow in robots.txt, and the fifth is a redirect list from the old addresses to the new ones, if the old site already exists and has visitors. The sixth is accessibility: if you are a public body, the requirements belong in the specification already, and if you are a private service provider the duty is reasonable adjustments under the Equality Act, not a listed-service test; it is much cheaper to settle that when the specification is being written than after handover.

This list is worth going through in one conversation, not in pieces, because together it shows how large a part of the project depends on the client, and that is usually larger than the client expected. None of these requirements is expensive, and none of them requires technical knowledge; they only require that someone ask them before the work starts.

And the seventh, which is not technical but decides more than the other six: an agreement on the minimum scope with which the site can be published. A project in which publication happens only when everything is ready tends never to publish, whereas a project with a clear minimum scope publishes on time and then grows. If you would like us to talk this through with you, get in touch.