Custom web solutions

A web solution is custom when it aligns with your business rather than the other way round. That sounds obvious, but it is not: most of the projects that end up with us did not fail on looks. They failed because a website builder or a bought theme eventually hit a wall – an interface to inventory management, an approval process for content, a form with logic, a second language.

Web solution for a notary’s office

When the effort pays off – and when it does not

There are good reasons not to build a custom solution. If you need a handful of pages, have no connections to other systems and rarely change content, a solid standard theme on a common content management system is the more economical decision. We say so even when it means we get a smaller project.

Custom becomes worthwhile as soon as at least one of these applies:

  • Data has to flow between systems – ERP, CRM, inventory management, accounting, a booking or ticketing system.
  • Several people maintain content and need different permissions, previews or approvals.
  • The site has its own logic: configurators, calculators, filters across large data sets, customer areas with a login.
  • You run several brands, languages or country versions out of one editorial base.
  • Your competitors look like you, because everyone bought the same theme.

What we build

Whether it is an online shop, a company website, a magazine or a platform – the process stays similar, the technical foundation does not.

Company websites are the most common case: services, references, ways to get in touch, often with a careers section carrying job ads and an application form.

Online shops have their own demands on payment methods, shipping rules, tax logic and product data. There is a separate page for that: online shop development.

Landing pages pursue a single goal and are usually planned together with a campaign.

Magazines, blogs and portals live on editorial processes: categories, authors, scheduled publication, archive pages that are still found years later.

Internal applications run in the browser instead of on the desktop: dashboards, administration interfaces, tools for sales. Technically this is where it crosses over into web development in the narrower sense.

The technology decision comes before the design

Which system carries a project depends on three questions: how often does content change, how many channels should it feed, and what has to be connected?

A classic CMS such as WordPress or TYPO3 renders pages on request and is strong when editing and output belong closely together. A headless CMS separates the two: content sits in an editorial system and is retrieved via an API – by the website, an app, a newsletter tool or a display in a branch. The Jamstack approach builds static pages from that in advance and has a CDN deliver them. That is fast and hard to attack, but it requires a build process and fits poorly with content that changes by the second.

None of these variants is fundamentally better. We decide that within the project and give reasons, instead of selling every client the same system.

How a project runs

Analysis. What is there, what works, where does it break down? On existing sites we look at the numbers before we change anything – entry pages, exits, search queries in Google Search Console.

Concept and information architecture. Page structure, navigation, URL scheme. In a relaunch this is where the redirects are defined, so that existing rankings are not lost.

Design. Layout, typography, components.

Build. Frontend, backend, interfaces, editorial interface. You see intermediate states on a staging environment, not just the result.

Launch and operations. Migration, monitoring, updates. The work does not stop afterwards, it just gets quieter.

What we check before every launch

Part of the quality of a web solution is measurable, and those measurements run before a site goes live.

Google’s Core Web Vitals consist of three values: LCP (Largest Contentful Paint) measures when the largest visible content is in place, INP (Interaction to Next Paint) the response time to input, and CLS (Cumulative Layout Shift) how much the layout jumps while loading. INP replaced the earlier FID metric in March 2024 and measures more sharply, because it considers all interactions in a session and not only the first.

On top of that come points no user sees and which still decide the outcome: images in WebP or AVIF instead of uncompressed JPEG, HTTP/3 on the server, cleanly set heading levels, forms with proper labels, sufficient contrast, keyboard operability. And a consent banner that only loads scripts after active consent – under the German TDDDG, consent before setting is not an optional extra but a precondition.

When an existing site is replaced

A relaunch is not new construction on an empty plot. The old site has rankings, links from outside, saved bookmarks and campaigns pointing at particular URLs. That is exactly where relaunches most often come apart: the new site is better, and traffic drops anyway.

Every rebuild therefore starts with an inventory before anything is designed. Which pages bring visitors today, which search queries lead there, which URLs have references from other websites? That list turns into a mapping: every old address gets a new target, and one that fits in terms of content – not the homepage across the board. These redirects are tested before the switch, not after.

The second point is the content itself. On most sites that have grown over the years, an honest review pays off: what gets read, what is out of date, what was never right? Merging pages is usually more effective than dragging them along one by one.

Operations, maintenance and further development

A web solution is not a piece of furniture. CMS and extensions receive security updates, browsers change their behaviour, search engines change how they judge. We take over maintenance of existing projects – including ones we did not build – handle updates, backups and monitoring, and develop the site further step by step instead of throwing everything away every five years.

Let’s talk about your project

We get furthest fastest if you tell us roughly what should be built, what is in the way today, and by when it has to be standing. Everything else we sort out in conversation – here is the contact page, where you can also book a slot directly.

Our clients

Client logo Client logo Client logo Client logo Client logo Client logo Client logo Client logo