Websites & web platforms — from one page to a whole system
On a business-card site somebody reads something and reaches for the phone. On a platform somebody signs in, is granted permissions, sees their own data and triggers processes that also land in your other systems. Between those two ends lies not a price tier but a different kind of project — which is why we never start with technology but with the question of what should actually happen on this site.
The four tiers side by side
The difference is not the number of pages but what happens on them. Pick the tier closest to your own task.
One-pager
For businesses that mainly want to be called: trades, practices, firms, sole traders. Everything on one page — what you do, for whom, where you are, how to reach you. No menu anyone can get lost in.
- Services, contact, directions, opening hours
- Legal notice, privacy policy and cookie notice set up
- Built for the phone first, not adapted afterwards
- A Google Search Console entry so you can see what happens
Company website
As soon as you have more than one offering, each of them needs its own page — otherwise they compete against each other in search. Plus a structure both people and search engines understand, and an editing setup you can work with yourself.
- One page per service instead of one catch-all page
- Editing: you change text yourself, without learning HTML
- A second language with separate content rather than machine translation
- Blog, forms, appointment booking — whatever you actually need
Shop & booking
From here on it is a process question more than a design one: payment methods, tax rates, right of withdrawal, availability, confirmations, returns. The look is quickly done — the rules behind it are the work.
- Catalogue, basket, payment and invoice
- Appointment booking with availability, buffers and reminders
- Handover to accounting and inventory, without retyping
- Accessibility to WCAG 2.1 AA where the German accessibility act applies
Platforms & systems
Users sign in, see different things depending on their role and trigger processes that land in your other systems. Different questions decide success here: who may do what? What happens on simultaneous edits? What if the other side stops answering for two hours?
- User accounts, roles and permissions, protected areas
- Customer portals with their own data, documents and reports
- Interfaces to inventory systems, CRM, ERP and accounting
- Logging and a plan for when the other side fails
Build a site so that you “have one” and you get a site that does nothing. Build it so the phone rings three times a week and you build differently — shorter paths, plainer language, the phone number at the point where somebody makes up their mind. And whoever builds a portal designs roles and permissions first, and screens only afterwards.