From brief to launch: what a website project really involves

The decision is usually taken quickly: the old website looks as though it has fallen out of its time, the competition is visibly more modern, a new presence is needed. Between that decision and the day the new site goes online, however, lies a genuine project — with phases, dependencies and decisions that many clients underestimate the first time round. Anyone who knows the sequence plans more realistically, compares quotations better and spares themselves frustration on both sides.

Transparency up front: this piece appears as an advertisement, and the examples given come from the project practice of the Osnabrück web agency BitBau (in German). The procedures described are, however, standard across the industry — they apply largely regardless of which service provider a company ends up working with.

At the beginning stands not the design but a conversation. In the brief, a good agency first clarifies questions that have nothing to do with colours and typefaces: what is the website supposed to achieve for the company? Who is supposed to visit it, and what are those people supposed to do there — call, fill in a form, book an appointment, buy something? How will success be measured a year from now? Anyone who has no answers to these questions ends up with a pretty but aimless site.

The brief also involves a sober stocktaking: which content already exists, and which has to be created anew? Which systems are to be connected — appointment booking, newsletter, inventory management? Are there specifications from the corporate design? And not least: who inside the company decides, and who supplies the input? That last question sounds banal, but it later determines weeks of the schedule.

Clients can prepare for this first conversation in a targeted way — and thereby often spare themselves the first round of corrections. A plain folder has proved its worth: access details for the domain and the existing hosting, the logo in print-ready quality, existing texts, pictures and brochures, a list of the most important competitors as well as three examples of websites they like — and, at least as revealing, three they do not like, each with a brief reason. Anyone who additionally notes which channels enquiries come in through today, and which of them turn into orders, gives the agency a realistic picture of what the new site is actually supposed to improve. None of this is compulsory; all of it saves billable hours.

The brief is followed by the concept phase. Here the page structure, the navigation logic and first sketches of the most important pages come into being, so-called wireframes — deliberately kept rough, without colours and pictures. There is a reason for that: an argument about structure is cheap to have on paper. If the same error of thinking is discovered only in the finished design, or even in the programmed state, the correction costs a multiple.

Only after that does the actual design work begin. UX-oriented design does not mean “making it prettier”, but rather taking decisions consistently from the users' point of view. Which information belongs at the top? How many clicks lie between the home page and contact? Does the site work just as naturally on a smartphone as on a large screen? Good design does not strike visitors at all — bad design does, immediately.

This phase also decides how smoothly the project runs, and surprisingly often it is decided on the client's side. Feedback consisting of five contradictory emails from different departments costs iterations. A simple rule has proved its worth: one person collects all the responses internally, resolves contradictions and passes them on in a bundle. Projects with a clear decision-making path are noticeably quicker to finish than projects with committees.

It also helps to take sign-offs seriously. A cleanly run project works with milestones: first the structure is signed off, then the design, then the implemented site. Every sign-off is an agreement — what has once been accepted is not casually unpicked again in the following phase. Late changes of course remain possible; they are simply not free, because they devalue work already finished. Reputable service providers say so openly and put a figure on change requests before implementing them, instead of quietly adding them to the final invoice. Clients, for their part, do well to involve, before every sign-off, precisely those people whose objections would later become expensive — and afterwards to stand by their decision.

Development itself is the least visible phase for clients. Approved drafts become components, components become pages; in the background the editorial system, the form processing and the interfaces come into being. The fact that for weeks there is apparently “nothing to see” unsettles some customers. Reputable service providers therefore show interim states on a test environment at regular intervals, instead of presenting one big surprise at the end — for better or for worse.

The most underestimated bottleneck of a website project, though, is not technology but content. Texts, photographs, team portraits, product data, translations: somebody has to supply all of it, and that somebody is almost always the client. Experience shows that missing content delays projects more often than any technical hurdle. Anyone who takes the new website seriously starts with the texts on day one — not in the final week.

Before going live comes the testing: different browsers and devices, every form, every redirect, loading times, basic accessibility. That also includes the unspectacular part — clean redirects from old addresses to new ones, so that laboriously built-up visibility in search engines is not lost overnight. The launch itself is then, in the best case, a quiet morning. The weeks before it decide whether it stays that way.

For the last days before going live, a sober checklist has proved its worth. Are the Impressum — the publisher's imprint German law requires — and the privacy policy up to date with the new site? Do form submissions land in the right inbox, and does anybody answer there? Is there a proper error page for addresses that no longer exist? Is the old website completely backed up in case something goes wrong? And is it settled who presses the proverbial button and when, and who stays reachable in the hours afterwards? One unspectacular but proven piece of advice belongs here too: the launch belongs on a weekday morning — not on a Friday afternoon, after which undetected problems can unfold undisturbed for an entire weekend.

And afterwards? A website is not a finished piece of work like a printed catalogue. Security updates, small corrections, new content, a look at the visitor figures: anyone who does not organise operations will have an outdated site again in two years. Part of closing the project is therefore an honest conversation about who will look after it in future — the service provider, the company's own team, or both together with a clear division of tasks.

The first weeks after the start deserve attention as well. Search engines have to reassess the new site; rankings can fluctuate temporarily before they settle — that is normal and no alarm signal, as long as the redirects are cleanly in place. What is most valuable in this phase is the feedback of real users: customers who cannot find something, employees who notice inconsistencies, enquiries that come in differently than expected. A small list of corrections in the first weeks is therefore not a defect of the project, but the moment at which assumptions turn into practical knowledge — and the accepted website turns into a tool that can be measured against everyday use.

How long does all this take? Three examples from BitBau's practice show the realistic range. The website of the Praxis am Salzmarkt — a presence for a medical practice, complete in three languages — came into being in twelve weeks. ScanYou, a tool for automated visual comparison tests of websites, needed sixteen weeks. QR2GO, a QR code platform with analytics features, was finished after twenty-four weeks.

The differences are explained not by diligence but by scope: a presentation site with clearly defined content is finished faster than a software product with user accounts and evaluations. As a rule of thumb for professional projects in mid-sized businesses, twelve to twenty-four weeks is an honest frame — depending on the range of functions, on the number of feedback rounds and on the speed at which content is delivered.

Offers promising a “professional website in a week” do not save these phases — they leave them out. Usually the concept is dropped, the design comes from a template, testing hardly happens, and the content is taken over from the old site unexamined. For some purposes that can be entirely sufficient. Nobody should merely expect to get the same result with it as with a well-considered project.

Money is rarely discussed in concrete terms in texts like this, and for good reason: reputable prices arise from the scope, not the other way round. The honest answer to the question “what does a website cost?” is: it depends on what it is supposed to be able to do. Mistrust is more appropriate towards fixed prices quoted without a single conversation about goals and content — that calculation has to come from somewhere, after all.

Clients can do a great deal to keep their project within the time and cost frame: deliver content early, bundle feedback, not defer decisions — and have the courage to leave functions out of the first launch. A website that starts with a clean core and grows afterwards beats, in practice, almost always the mammoth project that is still not online a year later.

The choice of service provider, too, can be checked against a few signals. Does the agency ask questions about the business in the first conversation — or does it only talk about design? Is there a comprehensible process with interim states on a test environment? Who owns the code, the domain and the content in the end? What happens after the launch, and what does it cost? Anyone who gets evasive answers to these questions should keep looking.

Whether the service provider sits round the corner or at the other end of the German-speaking world is today above all a question of working method. BitBau, for instance, looks after companies within a radius of around thirty kilometres of Osnabrück in person on site and works remotely with customers in Germany, Austria and Switzerland — with the same procedures, test environments and interim states. What is decisive is not the distance but whether the process holds.

That leaves the most important insight: a website project is a normal business project. It needs a goal, someone responsible, a realistic time frame and the willingness to take decisions. Anyone who treats it that way — and chooses a partner who explains their working method openly — ends up not with a work of art but with something better: a tool that works for the company every day.