Fast, modern websites
you can measure.

Short version: Next.js and Node.js, pages pre-rendered on the server, no plugins or licences, SEO and tracking as part of the brief, Git deploys with automatic rollback. The long version follows.

1. 01

   Stack: Next.js, React, Node.js, TypeScript

   We build websites in Next.js on top of React, in TypeScript, on Node.js 22. Pages are pre-rendered at build time or on the server, so the browser gets finished HTML and search engines and language models read it without JavaScript. Styles live in one file with tokens, no CSS framework. Content lives in the repository or in our own lightweight CMS, depending on who changes it and how often. For smaller sites and tools, Node.js with Express and no build step is enough. We do not use WordPress, Webflow or builders, because each is expensive to run after a year, slow, or impossible to connect to tracking and the e-shop. If you have such a site and it works, we will not talk you into a rewrite. If it does not, we can port it so it looks the same, as we did for Safe Logic.

   Next.js 15 · React 19 · TypeScriptNode.js 22, Express for small sitesown CMS or content in the repositoryno plugins, no licences
2. 02

   Speed: we measure it, not claim it

   We judge website speed by Core Web Vitals, that is by what Google measures on real visitors: how fast the main content appears (LCP), how fast the site responds (INP) and whether it jumps around while loading (CLS). The goal is green in all three on mobile, not just a score in a lab test. We get there by construction, not by tuning at the end: pre-rendered HTML, fonts hosted by us with a character subset, images in WebP or AVIF in several sizes, JavaScript only where it does something, no animation libraries and no external scripts beyond tracking. The result is pages with roughly 100 kB of JavaScript that load fast even on mobile data; our own site is an example.

   Core Web Vitals: LCP, INP, CLS on mobilepre-rendered HTML, no waiting for JSfonts and images optimised at buildno third-party scripts beyond tracking
3. 03

   SEO: part of the build, not an add-on

   We design the site structure around what people search for, so every page targets one query and has its own title and description at a length the search engine will show. Every site gets the same technical layer: canonical URLs, sitemap, robots.txt, JSON-LD structured data (organisation, services, articles, FAQ, breadcrumbs), share images generated per page and an llms.txt file for language models. On multilingual sites the language is in the URL, pages carry hreflang and slugs are translated because they carry weight. We prepare redirects from the old site before launch so rankings are not lost. What we do not guarantee: positions in results. Those depend on content and competition, not technology. Technology makes sure the site does not lose positions over something that could have been done right.

   page = one query, own title and descriptionsitemap, robots, canonical URLs, hreflangJSON-LD, OG images, llms.txtredirects from the old site
4. 04

   Tracking: numbers that match orders

   We hand over the site with Google Tag Manager, GA4 and Consent Mode v2 set before any tag fires. The cookie banner is our own, with no per-domain licence, Reject on the first layer and provable consent. Conversions (form sent, order, phone call) are events with uniform names across our sites, so the agency can build campaigns on Google, Meta and Sklik straight away. For e-shops we verify that orders in analytics match orders in the admin, and add server-side tracking where needed.

   GTM, GA4, Consent Mode v2 before other tagsown cookie banner, no licencesconversions as events for Google, Meta and Sklikverified against real orders
5. 05

   Security and accessibility

   Forms have bot protection that does not bother people (a hidden field, submission limits, reCAPTCHA v3 on larger sites) and validation on the server, not just in the browser. An enquiry is saved first and e-mailed second, so a mail outage never loses it. Secrets live in the server environment, never in the repository. Browser headers are set so the site cannot be embedded in someone else's page and does not reveal where the visitor came from. We keep accessibility at the level European legislation requires for public websites: keyboard operation, visible focus, text contrast, labels on images and forms, respect for reduced-motion settings.

   server-side form validation, bot protectionsecrets outside the repositorysecurity headerskeyboard operation, contrast, labels
6. 06

   Deployment and operations

   The site lives in a Git repository that is yours. Deployment runs from Git through our Indepanel: the new release builds into a separate folder, passes a health check and only then takes traffic. If the check fails, the previous release keeps running. Staging is separate from production, so you see changes before customers do. Operations include dependency updates, backups and monitoring with outage alerts. If you want to host in-house, we deploy the same setup to your server or into Docker and hand over the documentation.

   Git deploys, health check, rollbackstaging separate from productionupdates, backups, monitoringhosting with us or with you