senn-tech
02 · Web

Websites and online shops that are built

Most company sites are assembled rather than built, and carry fifteen add-ons of which three are used. That is not obvious at first. It becomes obvious when the site slows down, when an update breaks something, or when nobody can say why the contact form stopped sending mail three weeks ago. A built site has fewer moving parts — and therefore ages differently.

Company site, landing page or shop — as a real application rather than a page builder carrying thirty add-ons. Multilingual, fast and measurable. This site is the working example.

  • Company sites and landing pages in Next.js, shipped multilingual
  • Online shops with Medusa and Stripe, headless instead of monolith
  • An editing system your people can actually operate: Kirby or MDX in the repository
  • Operations included: certificates, reverse proxy, image optimisation, analytics
Next.jsKirbyMedusaStripeCaddyMatomo
Who this fits

Businesses for which the website is a tool rather than a business card: multilingual, with forms that actually arrive, or with a shop that carries revenue. If an off-the-shelf template is enough for your case, we will say so — you would be overpaying with us.

What we run ourselves

We operate several sites ourselves — from a group site with a shop through to this one. All of it runs on our own hardware, behind our own reverse proxy.

This site
Next.js, bilingual, statically served, with a blog, a newsletter and an AI chat on a model in our own building. It doubles as our test bed for everything we recommend.
Group site with shop
Editing system, product catalogue and role-dependent pricing for a group of companies. Grown over years, not set up once and left alone.
Separate site per business area
A second site for a subsidiary, set up as a technically separate build so that a rebuild there does not take the rest with it.
Newsletter without a third party
Sign-up, double confirmation and delivery through our own mail server — without addresses sitting with a provider overseas.
Reverse proxy in a pair
Two nodes with automatic certificates in front. If one fails nobody notices, because the other keeps serving.

How a project runs

We start with structure, not colour. Once it is clear which pages exist, what they should trigger and who maintains them, the rest is craft.

  1. 1Structure and goal

    What should the site trigger — a call, an enquiry, an order? The structure follows from that, not from the number of menu items.

    1 meeting
  2. 2Draft on real content

    A clickable draft with your texts and images, not with placeholder text. Placeholder text hides exactly the places that cause trouble later.

    1–2 weeks
  3. 3Build and connect

    Implementation, editing, forms, shop integration, multilingual delivery. In parallel we set up measurement and search fundamentals rather than retrofitting them.

    2–5 weeks
  4. 4Go live and after

    Migration without downtime, redirects for old addresses, certificates, backups. After that either we look after it, or we hand it over cleanly.

    1 meeting + ongoing

What it costs

Fixed price per stage. A company site is straightforward to cost; a shop connected to your inventory system only becomes so once the interface is known — which is why we look at that first.

What drives the price
Multilingual delivery, integrations, and the number of genuinely different page types. Twenty pages of the same type cost almost nothing extra; three entirely different ones do.
What lowers the price
Finished texts and images. The most common reason web projects stall is not the technology — it is the content everyone is waiting for.
Running costs
Operation on your own hardware instead of a builder subscription: no fee per editor, no price jumps as traffic grows. What remains is the domain, hosting and maintenance.

What you get

  • A site that belongs to you — source code in your own repository
  • Multilingual content properly separated instead of a translation add-on
  • Analytics without a third-party service, with defined goals rather than visitor counts
  • Search fundamentals from day one: structured data, sitemap, clean addresses
  • Operations and certificates included — or documented for handover

Frequent questions

Why not WordPress?
Because the effort is not in the building, it is in the running. A grown landscape of add-ons has to be kept current, and every update is a small risk. That does not make content management systems bad — we run them ourselves. Just lean ones, where you know what is inside.
Can our team maintain the content?
Yes. Depending on the project you get an editing system with a login, or a text structure in the repository. What we will not do is promise an interface in which the entire layout can be moved around, and then watch the layout get moved around.
What about accessibility and data protection?
Keyboard operation, contrast and sensible labelling are part of the work, not an extra line item. For analytics we use Matomo on our own hardware: visitor data stays in the building, and the consent question eases because nothing flows to a third-party service.
How quickly is a new site live?
A manageable company site with five to ten pages is up within a few weeks. A shop connected to your inventory system takes longer — the work is in the interface, not in the appearance.