At the start of a website project, the question is rarely about colours or typefaces. The first real question is who should build the site at all. Four answers are in circulation: you build it yourself with a website builder kit, you hire an agency or a freelancer, you use an AI-assisted builder, or someone you know takes it on. Each of these answers is reasonable, and none of them fits every situation. This article puts the four routes side by side, assesses them against seven criteria that make themselves felt in day-to-day operations, and states openly where our own route is not the right one. It is deliberately not about what technology can do today — there is a separate article for that. It is about choosing the route.
Why the choice of route matters more than the design
A website is not an object you buy once and then own. It is a piece of operating equipment with maintenance needs, legal duties and a dependency on whoever carries it technically. That is why the decision on a route echoes far longer than any decision about layout or imagery. Get a layout wrong and you change it within an hour. Get the route wrong and you often notice eighteen months later — when a price list is out of date, a legal text needs adjusting or a new service is added and nobody is available to make the change.
The starting point is not that small firms do nothing digitally. Quite the opposite: 85 percent (Bitkom) of trade businesses offer at least one digital service, 68 percent (Bitkom) send quotes digitally, 62 percent (Bitkom) also send invoices that way, and 48 percent (Bitkom) allow online appointment booking. At the same time, only 4 percent (Bitkom) of businesses already use artificial intelligence, with a further 9 percent (Bitkom) planning to. The gap is not one of willingness but of implementation — and implementation starts with the question of who takes it on.
Having a website is no longer a distinguishing feature either. 92 percent (Bavarian State Office for Statistics) of companies with at least ten people employed had a website in 2025, 64 percent (Bavarian State Office for Statistics) published job openings there and 27 percent (Bavarian State Office for Statistics) offered an online booking system. Anyone thinking about a website today is no longer deciding whether to have one, but how to run it: who builds, who maintains, who is liable, who pays.
Choosing a route is an organisational decision
The four routes in brief
Before criteria are applied, each route deserves a short description — without judgement and without product names. The descriptions cover the typical case; each of the four variants has exceptions in both directions.
Self-build with a builder kit
You rent a platform, pick a template and fill it with your content. Structure, copy, images and upkeep stay with you. The platform supplies the technology, hosting and usually templates for legal pages.
Agency or freelancer
You commission a provider for concept, design, implementation and often copy and photography as well. The scope sits in the quote; later changes usually go back through the provider.
AI-assisted builder
You describe the business, its services and its audience; the system produces structure, draft copy and layout from that. You review, correct and publish. Changes are made by instruction or directly in the editor.
Someone you know
A person from your circle builds the site on the side. Costs are low, arrangements informal. Availability, scope and responsibility for later upkeep are rarely put in writing.
These four routes are not mutually exclusive. Hybrids are common in practice: a business has the structure and first drafts generated and then hands them to a specialist for editing. Or an agency builds the first version and the business maintains it afterwards. What matters is less the pure doctrine than the question of who is responsible for which part — and whether anyone has written it down.
Seven criteria that separate the routes
The following seven criteria have proven to be the points on which projects are decided in hindsight. They are deliberately not sorted by preference but by what creates work or costs money in the second year. The table describes typical cases, not commitments — every platform and every provider deviates from it in both directions.
| Criterion | Builder kit (self-build) | Agency or freelancer | AI-assisted builder | Someone you know |
|---|---|---|---|---|
| Time to launch | Days to weeks, depending on your own free time | Several weeks to months, including coordination and content delivery | Hours to days for the first complete draft | Open-ended, because the work happens alongside a main job |
| One-off cost | Low, essentially your own working time | The largest item of the project, but with a written scope | Low; the effort sits in the briefing and the editorial review | Very low, but without a binding commitment on scope |
| Ongoing cost | Monthly subscription plus domain | Hosting plus a maintenance or support retainer, changes billed by effort | Monthly subscription plus domain, changes within the plan | Hosting and domain, with the working time unpaid |
| Who can change it later | You, within what the builder kit allows | Usually the provider, and you as well depending on the agreement | You, by instruction or directly in the editor | The one person who built it |
| Dependency on the provider | On the platform; exports are often limited to text and images | On the provider, their workload and their availability | On the platform; domain and content stay in your hands | On a single individual and their spare time |
| Technical quality | Varies with template, image material and add-ons | Contractually definable, if measured values are in the quote | Built into the system, because structure and delivery are predefined | Unverified, because measured values are rarely part of the arrangement |
| Mandatory topics covered | Your own work; templates do not replace a content review | Part of the engagement, if explicitly agreed and signed off | Included as a framework; the content review stays with you | Usually unresolved; responsibility stays with the business |
Two rows in this table are regularly underestimated. The first is "who can change it later": it decides whether a changed opening time is online the same day or three weeks later. The second is "dependency on the provider": it decides how much effort a switch takes when one becomes necessary. Both rows cost nothing at the start and a lot later.
Check the exit before you enter
Time to launch, one-off cost, ongoing cost
Time is the criterion on which the routes differ most — and the one most often miscalculated. The bottleneck in an agency project is rarely the agency but the material coming from the business: descriptions of services, photos of the team, details on prices and processes. The bottleneck in self-build is your own free time, which in a trade business or a practice falls in the evening and at weekends. The bottleneck on the AI-assisted route is the editorial review: a draft arrives quickly, yet responsibility for every sentence remains with the business.
On cost, separating one-off from ongoing is worthwhile because the two behave differently. The one-off amount is visible and gets compared. The ongoing amount is small and gets overlooked, even though over five years it can make up the larger share. How to plan both sides cleanly, without surprises at the end, is set out in the article on separating one-off and ongoing website costs.
- One-off: concept, structure, copy, photos, logo or image editing, domain setup, migration of existing content.
- Ongoing: subscription or hosting, domain, email, maintenance and updates, editorial upkeep, extensions.
- Invisible: your own working time for supplying material, coordination, correction loops and approvals.
- Later: adjusting legal texts, changing provider, an overhaul after a few years, new services and pages.
A rule of thumb from projects: if a route is markedly cheaper on the one-off amount, check which part of the work has been shifted to you. If a route is markedly cheaper on the ongoing amount, check what the subscription includes and what is billed by effort (project experience). Both are legitimate — the choice should simply be a conscious one.
Technical quality is measurable
Loading time and mobile usability are not matters of taste. The Core Web Vitals provide three measured values with clear thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1, each assessed at the 75th percentile of real page loads (Google web.dev). These values can be agreed as targets before commissioning and measured again after handover — regardless of which route you have chosen.
A look at the wider picture shows why this matters: only 48 percent (HTTP Archive) of websites loaded on mobile pass all three Core Web Vitals. Loading time is the most common sticking point: 62 percent (HTTP Archive) reach a good LCP value, while 77 percent (HTTP Archive) are in the good range for INP and 81 percent (HTTP Archive) for CLS. A website that feels fast on the builder's own computer can be a very different experience on a three-year-old phone on a mobile connection.
- Agree on measured values in writing, not adjectives: "LCP under 2.5 seconds on mobile" instead of "fast".
- Have it checked on a real mobile device on a mobile connection, not only on Wi-Fi at a desk.
- Clarify how many scripts and external embeds the page loads — every embed is loading time and a data protection question.
- Ask what happens to loading time when photos, forms or a gallery are added later.
- Test usability with a thumb: spacing, button sizes, form fields, phone number as a tap-to-call link.
How high measured values are achieved technically, and why the type of delivery weighs more than the choice of template, is described in the article on static delivery and PageSpeed scores. Which controls actually work on small screens is covered in the piece on mobile usability for business websites.
Mandatory topics: imprint, privacy, consent, accessibility
The fourth block of criteria separates the routes especially clearly, because responsibility and execution can come apart here. The imprint and the privacy policy have to match the actual business, not a template. A consent solution is only a consent solution if it takes effect before non-essential cookies are set and makes rejection as easy as agreement. And since 28 June 2025 the German Accessibility Strengthening Act applies to products and services offered to consumers after that date (BFSG); micro-enterprises with fewer than ten employees and no more than two million euros in annual turnover are exempt when providing services (BFSG).
That this area is still widely open is shown by the annual analysis of the one million most visited home pages: automatically detectable WCAG failures were found on 95.9 percent (WebAIM) of them, up from 94.8 percent (WebAIM) the year before, with an average of 56.1 (WebAIM) distinct errors per page. Automated checks only cover part of the criteria — so the real picture is likely to be below that figure rather than above it.
Responsibility can be delegated, but not handed over
In practice this means: with self-build and with the acquaintance route, you have to organise the review yourself. With an agency it belongs in the written scope, otherwise it has not been commissioned. With an AI-assisted builder the framework is usually built in, yet factual accuracy still rests with you. What exactly belongs in an imprint and a privacy policy is set out in the article on mandatory legal pages for business websites; the requirements for a workable cookie consent solution and the reach of the accessibility duties for businesses are described separately.
When an agency is the better choice
Part of the honesty of a decision grid is naming the cases in which our own route is not the best one. For a share of projects, hiring an agency or an experienced freelancer is the more sensible decision — not as a fallback, but because the task calls for exactly that.
- Special functions: configurators, calculators, booking logic with resource planning, member areas with roles and permissions.
- Selling with stock and shipping: a shop with inventory, shipping rules, returns and tax specifics is a system in its own right, not an extra page.
- Connection to existing software: merchandise management, scheduling software, point of sale, an industry solution or a practice management system — anywhere data is meant to flow both ways.
- A highly distinctive design: when the brand needs a fully drawn visual identity that deliberately steps away from any template.
- Extensive migration: hundreds of existing pages with grown addresses, redirects and historical search placements.
- Several locations or brands: when structures, legal texts and editorial processes have to line up across multiple units.
The common denominator of these cases: it is not about more pages but about more logic. As soon as a website has to talk to another system, store states or steer processes, the centre of gravity shifts from editing to development — and development is the domain of providers with a team behind them. A usable test sentence: if you cannot write the requirement down in five sentences without saying "and then the system has to automatically", it is a development project.
A website with a clear set of services is an editorial project. A website that checks appointments against resources is a software project. Treating both the same way means either underestimating the second or overpaying for the first.
When self-build is enough
The opposite direction is just as real. There are projects where a quote running into several thousand euros misses the need, because the task is simply small. Anyone working alone, with a manageable set of services and no intention to grow over the next few years, gets a long way with a small, carefully made site.
- A single person without a team: a site that explains who you are, what you offer and how to reach you.
- One to five pages: home, services, about, contact and the mandatory pages — often nothing more is needed.
- No growth target: anyone fully booked and working through referrals needs a dependable business card, not a visibility machine.
- A clearly limited purpose: a site that mainly shows address, opening hours and availability correctly and up to date.
- Genuine enjoyment of the work: anyone who likes writing their own copy and choosing their own images loses no time and gains control.
Small is no excuse for incomplete
Three business profiles with a recommendation
Criteria become tangible once they are applied to concrete situations. The three profiles below cover a large share of the cases that come up in practice. In each case the recommendation is the choice that creates the least friction under the described conditions — not the only defensible one.
Trade business, 8 employees
An established business with a loyal customer base and a growing need for applicants. The website should show services, take enquiries and advertise jobs. No special functions are planned; changes come up several times a year.
Practice wanting online appointments
Fixed consultation hours, a heavy phone load, a wish for online appointments. Professional rules and particularly sensitive data shape every decision. The appointment part is the actual core of the project.
Association without a budget
A volunteer structure, no meaningful budget, changing responsibilities on the board. What is needed: dates, contacts, a membership form and a place for reports from club life.
Trade business with eight employees. An AI-assisted builder fits best here in most cases. The reason is not the speed of the first draft but how changeable it is afterwards: a new service, a new team photo, an updated job ad — these are editorial tasks that arise inside the business and should be done there. An agency becomes sensible once a connection to merchandise management, a configurator or a customer portal is added. Which content actually generates enquiries in the trades is described in the article on winning enquiries through a tradesperson website.
Practice wanting online appointments. The recommendation here is split. The website itself — range of treatments, team, directions, consultation hours, mandatory pages — can be built well with an AI-assisted builder and maintained in-house afterwards. Appointment booking, by contrast, is the delicate part: it processes health data, it has to fit the practice software, and it is subject to professional rules. Where a connection to a practice management system is wanted, that part belongs in expert hands while the rest of the site stays with the practice. The professional boundaries are set out in the piece on a compliant medical practice website.
Association without a budget. Self-build is the realistic choice here, but on one condition: the scope has to stay small and responsibility has to sit with at least two people, so a change on the board does not freeze the site. An AI-assisted builder can shorten the start, because structure and draft copy do not begin from zero; what remains decisive is that upkeep is possible without specialist knowledge. What a club site actually has to deliver is covered in the article on nonprofit and club websites for members and volunteers.
| Profile | Recommendation | Moving to an agency makes sense as soon as ... |
|---|---|---|
| Trade business, 8 employees | AI-assisted builder with editing kept in-house | a connection to merchandise management, a configurator or a customer portal is needed |
| Practice wanting online appointments | AI-assisted builder for the site, specialist work for the appointment link | appointments are to be synchronised with practice software or patient data processed |
| Association without a budget | Self-build within a clearly limited scope, upkeep shared by two people | a member area with roles, fee administration or payment processing is created |
Four questions that decide every route
When there are too many criteria and the profiles do not fit, four questions remain. They can be answered in a board meeting, an office conversation or on the back of a beer mat — and in most cases they sort the four routes more reliably than any feature list.
- Who maintains the website in two years? Name a person, not a role.
- What happens if the platform or provider is gone? Describe the path, not the hope.
- Who owns the domain? Check the registration instead of relying on an assurance.
- Who is liable for the legal texts? Write down who updates them and when.
Who maintains it in two years? This question exposes most wrong decisions. If the answer is "we will sort that out", it has not been answered. A website does not age through technology but through content: changed prices, new staff, a different set of services, updated opening hours. Anyone unable to name a person should choose the route that makes changes easiest — and that is rarely the one where every small item triggers an order. How upkeep can be organised as a fixed routine is described in the article on a maintenance routine for small firms.
What happens if the provider is gone? Providers give up business areas, platforms change their plans, people change careers. That is normal and no accusation. What matters is whether you are prepared: is your copy and imagery available in a form you can take with you? Do you have access to the domain and the email accounts? Is there a current backup? Where those three answers exist, a change of provider is inconvenient but manageable.
Who owns the domain? In Germany more than 18 million (DENIC) de domains were registered at the end of June 2026 — and a share of them is held in the name of service providers rather than the businesses they are used for. The domain is your company's address online; it should be registered to the business, with your own email address as the contact. Check this actively, before a conflict arises. The basics, including responsibilities and email setup, are described in the article on domains and business email addresses.
Who is liable for the legal texts? The short answer: the business operating the website. The longer answer concerns the division of labour: who drafts the texts, who checks that they match the actual business, who updates them when a provider or a process changes? One sentence in the quote or in the club minutes saves a great deal of discussion later.
Four questions, four names
How to make the decision in half an hour
Criteria, profiles and questions can be turned into a short sequence that works without prior knowledge. It does not replace professional advice, but it narrows the options enough for a conversation with a provider or a trial with a platform to be conducted with purpose.
- Write down in three sentences what the website should achieve — no features, just purpose and audience.
- Mark the two rows in the criteria table that weigh most heavily for you.
- Use the list of special functions to check whether your project is a development project.
- Answer the four questions with names and dates.
- Set a budget for one-off and ongoing costs separately, before you request quotes.
- Agree measurable targets for loading time and mobile usability, whichever route you take.
Whether now is the right moment for a new site at all, or whether reworking the existing one is enough, is a prior question — it is addressed in the article on when a new website is worth it. And anyone wanting to know what is technically possible today and where the limits lie will find it in the article on building a website with AI; this text deliberately answers only the question of the route, not the question of the technology.
How the four routes differ in their characteristics is summarised on our overview comparing the routes. The sequence from the first description to the published site is set out on the page how a website is built step by step, and finished examples from various industries can be viewed in the demo overview.
The route you can leave again
Sources and studies