Webentwicklung

Diese Seite beschreibt die technische Seite unserer Arbeit: wie eine Anwendung aufgebaut wird, welche Entscheidungen dabei anstehen und woran man später merkt, ob sie richtig getroffen wurden. Welche Arten von Projekten wir umsetzen, steht unter individuelle Weblösungen; alles rund um Verkaufen im Netz auf der Seite zum E-Commerce.

Frontend und Backend

Das Frontend ist der Teil, der im Browser läuft: HTML für die Struktur, CSS für die Darstellung, JavaScript für alles, was auf Eingaben reagiert. Die Trennung ist keine Formalie. Wer Struktur über CSS erzeugt statt über HTML, bekommt eine Seite, die für Screenreader und Suchmaschinen unlesbar ist – und beide lesen denselben Quelltext.

Moderne Frontends arbeiten mit Komponenten: ein Element wird einmal gebaut und überall verwendet, wo es gebraucht wird. Ob dafür React, Vue oder ein Framework wie Astro sinnvoll ist, hängt davon ab, wie viel Interaktion die Seite wirklich enthält. Eine Unternehmenswebsite mit fünfzehn Unterseiten braucht kein clientseitiges Routing – sie wird dadurch nur langsamer.

Das Backend läuft auf dem Server: Es hält Daten in einer Datenbank, prüft Eingaben, entscheidet, wer was sehen darf, und spricht mit anderen Systemen. Wir arbeiten überwiegend mit PHP, Node.js und Python, je nachdem, was das Zielsystem vorgibt. Wichtiger als die Sprache ist, dass Validierung und Rechteprüfung serverseitig stattfinden. Alles, was nur im Browser geprüft wird, lässt sich umgehen.

Architektur: drei Wege, die gleiche Seite zu bauen

Serverseitig gerendert. Der Server erzeugt die fertige Seite bei jedem Aufruf. So arbeiten WordPress, TYPO3 und die meisten Shopsysteme. Der Vorteil: Inhalte sind sofort aktuell und ohne Umwege im Quelltext. Der Preis: Jeder Aufruf kostet Rechenzeit, weshalb Caching hier keine Kür ist.

Statisch vorgebaut. Die Seiten werden einmal erzeugt und dann als fertige Dateien über ein CDN ausgeliefert. Das ist die schnellste Variante und bietet kaum Angriffsfläche, weil zur Laufzeit nichts ausgeführt wird. Sie passt für Inhalte, die sich planbar ändern.

Headless. Inhalte liegen in einem Redaktionssystem und werden per API abgeholt. Sinnvoll, sobald dieselben Inhalte an mehreren Stellen erscheinen – Website, App, Newsletter, Partnerportal. Welche Systeme dafür in Frage kommen, behandelt die Seite zu den Content-Management-Systemen.

In der Praxis mischen sich diese Ansätze. Ein Shop rendert Produktseiten serverseitig, liefert aber Bilder und statische Inhaltsseiten aus dem CDN.

Schnittstellen

Der aufwendigste Teil eines Projekts ist selten die Seite selbst, sondern das, was hinter ihr hängt. Typische Anbindungen: Warenwirtschaft und ERP für Bestände und Preise, CRM für Anfragen und Kunden, Zahlungsdienstleister, Versanddienstleister, Buchhaltung, Newsletter-Systeme.

Solche Integrationen gehen selten am ersten Tag kaputt, sondern am dreihundertsten. Deshalb gehören Fehlerbehandlung, Wiederholungslogik und Protokollierung von Anfang an dazu: Was passiert, wenn das ERP zwei Stunden nicht antwortet? Bleibt die Bestellung liegen oder geht sie verloren? Diese Fragen beantwortet man vor der Umsetzung, nicht im Störfall.

Performance ist messbar

Ladezeit wird oft als Gefühl diskutiert. Sie ist eine Messgröße. Google fasst die relevanten Werte als Core Web Vitals zusammen:

• LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element geladen ist. Als gut gilt ein Wert unter 2,5 Sekunden.
• INP (Interaction to Next Paint) misst, wie schnell die Seite auf Eingaben reagiert. Dieser Wert hat FID im März 2024 abgelöst und ist strenger, weil er alle Interaktionen einer Sitzung betrachtet statt nur der ersten. Gut sind Werte unter 200 Millisekunden.
• CLS (Cumulative Layout Shift) misst, wie stark das Layout während des Ladens springt – meist verursacht von Bildern ohne Größenangabe oder nachgeladenen Schriften.

Die Stellschrauben sind bekannt und wirken unterschiedlich stark. Bilder in WebP oder AVIF statt in JPEG sparen bei gleicher Qualität einen erheblichen Teil der Dateigröße; korrekt gesetzte srcset-Angaben verhindern, dass ein Handy ein Bild in Desktop-Auflösung lädt. HTTP/3 baut Verbindungen über QUIC auf und verliert bei schlechter Mobilverbindung weniger Zeit als sein Vorgänger. Und der größte Hebel ist meist der, den niemand nennen will: weniger JavaScript. Jedes Tracking-Skript, jedes eingebettete Widget, jeder Chat-Button verlängert die Zeit bis zur Bedienbarkeit. Wie sich die Werte im Detail zusammensetzen, steht im Wiki-Eintrag zu Page Speed.

Barrierefreiheit gehört ins Markup, nicht in ein Plugin

Barrierefreiheit entsteht beim Bauen. Ein nachträglich eingebundenes Overlay-Skript, das Schrift vergrößert und Kontraste umfärbt, ersetzt keine saubere Grundlage. Der technische Maßstab in Europa ist die Norm EN 301 549, die auf die WCAG verweist: sinnvolle Überschriftenhierarchie, beschriftete Formularfelder, sichtbarer Fokus, Bedienbarkeit ohne Maus, ausreichender Kontrast, Alternativtexte für Bilder mit Informationsgehalt.

Für Anbieter im elektronischen Geschäftsverkehr ist das seit dem 28. Juni 2025 keine Kür mehr: Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act in deutsches Recht um und erfasst unter anderem Onlineshops, die sich an Verbraucher richten. Ob und in welchem Umfang Ihr Angebot betroffen ist, hängt vom Einzelfall ab und ist eine Rechtsfrage. Die technische Umsetzung ist unsere.

Sicherheit und Betrieb

Die häufigsten Einfallstore sind unspektakulär: eine seit Monaten nicht aktualisierte Erweiterung, ein Formular ohne serverseitige Prüfung, ein Datenbankzugriff ohne vorbereitete Statements, Zugangsdaten im Repository. Dagegen hilft kein Produkt, sondern Routine – regelmäßige Updates, getrennte Umgebungen für Test und Produktion, funktionierende Backups, deren Rückspielen auch einmal geprobt wurde.

Dazu kommen Kleinigkeiten mit großer Wirkung: HTTPS erzwingen, Sicherheits-Header setzen, Fehlermeldungen nicht mit Stacktraces nach außen geben, Admin-Zugänge mit zweitem Faktor. Wo die Anwendung anschließend läuft, beschreibt unsere Seite zum Webhosting.

Bestehende Projekte übernehmen

Ein guter Teil unserer Arbeit sind fremde Codebasen: ein Dienstleister, der nicht mehr erreichbar ist, ein Shop, den niemand mehr aktualisieren traut, eine Anwendung ohne Dokumentation. Wir sehen uns so etwas an, bevor über einen Neubau geredet wird. Häufig ist die Substanz besser als ihr Ruf, und drei Wochen Aufräumen sind billiger als sechs Monate Relaunch.

Unsere Leistungen im Überblick

• Websites und Webanwendungen auf Basis von HTML, CSS und JavaScript
• Umsetzung mit Content-Management-Systemen wie WordPress und TYPO3
• Shopsysteme: Shopware, WooCommerce, Shopify, Magento Open Source
• Individualentwicklung in PHP, Node.js und Python
• Schnittstellen zu ERP, CRM, Zahlungs- und Versanddienstleistern
• Intranet- und Verwaltungsanwendungen für interne Abläufe
• Prüfung, Übernahme und Sanierung bestehender Entwicklungen
• Performance-, Sicherheits- und Barrierefreiheitsprüfungen
• Wartung, Updates und Monitoring im laufenden Betrieb

Wie wir arbeiten

Sie haben einen festen Ansprechpartner, der das Projekt kennt und nicht nur weiterleitet. Zwischenstände laufen auf einer Testumgebung, die Sie jederzeit ansehen können. Was wir bauen, gehört Ihnen: Quellcode, Zugänge, Dokumentation. Wir arbeiten überwiegend mit Open-Source-Technologie, damit Sie weder an Lizenzen noch an uns gebunden sind.

Wenn Sie ein Vorhaben haben – neu, halbfertig oder festgefahren –, schildern Sie es uns kurz über die Kontaktseite. Dort lässt sich auch direkt ein Gesprächstermin buchen.