Woran erkenne ich einen professionellen Webentwicklungs-Dienstleister?

Weniger am Portfolio als an den Antworten auf unbequeme Fragen: Was passiert bei einem Datenverlust – und wurde die Wiederherstellung getestet? Was bekommen wir bei der Übergabe – Quellcode, Zugänge, Dokumentation? Wie läuft eine Änderung am Projektumfang ab? Wer ausweicht oder verspricht, dass „so etwas nicht vorkommt", plant den Ernstfall nicht ein. Wer konkrete Abläufe nennen kann, hat sie durchdacht.

Ein Baukasten oder Template ist deutlich günstiger – wann rächt sich das?

Für eine einfache Präsentationsseite rächt es sich oft gar nicht – dafür sind Baukästen gemacht, und das sagen wir auch so. Kritisch wird es, wenn Geschäftsprozesse in der Anwendung ablaufen: eigene Datenstrukturen, Rollen und Rechte, Anbindungen an andere Systeme, wachsende Nutzerzahlen. Dann stößt man an Grenzen, die sich nicht wegkonfigurieren lassen, und der Neubau kostet mehr, als die solide Lösung von Anfang an gekostet hätte. Die ehrliche Frage ist nicht „Baukasten oder individuell?", sondern „Was soll die Anwendung in drei Jahren können?".

Was bedeutet „getesteter Restore" – und warum wird das so betont?

Ein Backup zu haben und aus einem Backup wiederherstellen zu können sind zwei verschiedene Dinge. Viele Setups sichern jahrelang brav Daten – und erst im Ernstfall zeigt sich, dass die Sicherung unvollständig, nicht lesbar oder nie mit der aktuellen Systemversion erprobt war. Ein getesteter Restore heißt: Die Wiederherstellung wurde tatsächlich durchgespielt, sie funktioniert, und es ist dokumentiert, wie lange sie dauert. Das ist der Punkt, an dem sich stille Risiken von echter Betriebssicherheit trennen.

Gilt die Barrierefreiheitspflicht (BFSG) auch für unsere Anwendung?

Das Barrierefreiheitsstärkungsgesetz gilt seit Mitte 2025 für viele Angebote, die sich an Endverbraucher richten – etwa Online-Shops, Buchungsstrecken oder Bewerbungsportale können darunter fallen. Rein interne B2B-Anwendungen sind in der Regel nicht erfasst. Zwei Dinge gehören trotzdem in jedes Projekt: die rechtliche Einordnung sollte vor Projektbeginn geklärt und vertraglich festgehalten werden, und Barrierefreiheit lohnt sich auch ohne Pflicht – Ihre Belegschaft und Ihre Bewerber profitieren unmittelbar davon.

Fachartikel

Professionelle Webentwicklung: Die 9 Grundlagen, die ein Projekt tragfähig machen

Der Unterschied zwischen einer Baukasten-Website und professioneller Webentwicklung liegt weniger im Programmieren selbst als in dem, was drumherum abgesichert ist. Kurz gesagt: Professionalität zeigt sich vor allem darin, wie sich ein System verhält, wenn etwas schiefgeht – beim Datenverlust, beim Personalwechsel, bei der Änderung mitten im Projekt. Dieser Artikel erklärt die neun Grundlagen, an denen Sie das erkennen – verständlich und so konkret, dass Sie jeden Anbieter daran messen können.

1. Anforderungen vor Technik

Der teuerste Fehler in Softwareprojekten ist nicht der Programmierfehler – es ist die technisch saubere Lösung für das falsche Problem. Deshalb beginnt professionelle Webentwicklung nicht mit der Wahl der Technologie, sondern mit Fragen: Wer wird die Anwendung täglich nutzen? Wie laufen die Abläufe heute – wirklich, nicht laut Organigramm? Was ist unverzichtbar, was nur wünschenswert? Und woran wird nach einem Jahr gemessen, ob sich das Projekt gelohnt hat?

Erst wenn diese Fragen beantwortet sind, fällt die Technikentscheidung – nicht umgekehrt. Ein Anbieter, der im ersten Gespräch bereits das Werkzeug festlegt, bevor er Ihr Geschäft verstanden hat, optimiert für sich, nicht für Sie.

2. Datenmodell und Architektur zuerst

Jede Anwendung hat einen Kern, der alle Moden überlebt: die Struktur ihrer Daten. Wie Kunden, Aufträge, Mitarbeitende und ihre Beziehungen abgebildet sind, prägt die Anwendung über Jahre – lange nachdem die heute moderne Oberflächentechnik ausgetauscht wurde. Deshalb wird das Datenmodell zuerst und mit Sorgfalt entworfen, nicht nebenbei.

Dasselbe gilt für den inneren Aufbau: Geschäftslogik gehört an eine klar definierte Stelle, nicht verstreut über Oberfläche und Datenbank – sonst hat jede spätere Änderung unvorhersehbare Nebenwirkungen. Schnittstellen nach außen werden dokumentiert und versioniert, Änderungen an der Datenbank laufen als nachvollziehbare, wiederholbare Schritte statt als Handgriffe, an die sich später niemand erinnert. Man sieht von all dem nichts auf dem Bildschirm – aber man spürt es bei jeder Erweiterung.

3. Wartbarkeit als Feature

Der ehrlichste Maßstab für Codequalität ist eine einfache Frage: Kann eine andere Entwicklerin – oder derselbe Entwickler in achtzehn Monaten – das Projekt an einem Tag verstehen und sicher ändern? Dahinter stehen unspektakuläre Gewohnheiten: durchgängige, einheitliche Konventionen, automatisierte Prüfungen bei jeder Änderung und Tests auf den Pfaden, an denen wirklich Geld oder Daten hängen.

Wichtig ist das Augenmaß: Es geht nicht um beeindruckende Test-Statistiken – hundert Prozent Abdeckung sind Theater –, sondern darum, dass die kritischen Abläufe abgesichert sind und ein Fehler auffällt, bevor er Ihre Nutzer erreicht.

4. Sicherheit als Standard, nicht als Phase

„Security machen wir am Ende" ist das Gegenteil von Sicherheit. Professionell heißt: Die Anmeldung (wer bist du?) und die Berechtigung (was darfst du?) sind sauber getrennt, und jede Berechtigung wird auf dem Server geprüft – nicht nur in der Oberfläche versteckt. Alles, was von außen hereinkommt, wird an der Systemgrenze kontrolliert. Zugangsdaten und Schlüssel liegen nie im Quellcode. Und die verwendeten Komponenten werden laufend aktuell gehalten, denn die meisten erfolgreichen Angriffe nutzen längst bekannte Lücken in veralteten Bausteinen.

Als Prüfrahmen dienen die bekannten, öffentlich dokumentierten Angriffsmuster – bei Anbindungen an andere Unternehmen zusätzlich: begrenzte Zugriffe nach dem Prinzip der minimalen Rechte und ein Protokoll, das festhält, wer wann was getan hat.

5. Reproduzierbarer Betrieb

Ein Projekt ist nicht fertig, wenn es auf dem Rechner des Entwicklers läuft. Zum professionellen Betrieb gehören: eine Server-Umgebung, die als dokumentierter Bauplan existiert und jederzeit identisch wieder aufgebaut werden kann; automatisierte Auslieferung neuer Versionen statt Handarbeit am Produktivsystem; eine Testumgebung, die vom Produktivsystem getrennt ist; Überwachung mit Alarmen, die anschlagen, bevor Nutzer sich melden.

Und der Punkt, an dem die meisten Setups still durchfallen: Backups gibt es fast überall – aber wurde die Wiederherstellung je getestet? Eine Sicherung, aus der noch nie zurückgespielt wurde, ist keine Sicherung, sondern eine Hoffnung. Professionelle Anbieter spielen den Ernstfall durch und können sagen, wie lange die Wiederherstellung dauert.

6. Frontend-Qualität messbar machen

„Sieht gut aus" ist kein Qualitätskriterium – Messwerte sind eines. Ladezeit und Reaktionsverhalten lassen sich objektiv messen (Google tut das mit den Core Web Vitals und lässt es ins Ranking einfließen). Die Anwendung muss auf dem Smartphone genauso funktionieren wie am Arbeitsplatz, denn dort findet ein wachsender Teil der Nutzung statt.

Dazu gehört Barrierefreiheit: Seit Mitte 2025 ist sie durch das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Angebote an Endverbraucher auch rechtlich verpflichtend – für rein interne B2B-Anwendungen greift das Gesetz meist nicht, die Frage sollte aber vor Projektbeginn geklärt und vertraglich festgehalten werden. Und unabhängig von der Pflicht gilt: Eine Anwendung, die per Tastatur und Screenreader bedienbar ist, ist für alle Nutzer besser gebaut.

7. Der rechtliche Rahmen

Datenschutz lässt sich nicht nachrüsten wie ein Cookie-Banner. DSGVO by Design bedeutet: Es werden nur die Daten erhoben, die der Zweck erfordert; es ist geregelt, wann was gelöscht wird; und für jede Verarbeitung ist die Rechtsgrundlage benannt. Mit jedem beteiligten Dienstleister – vom Hoster bis zum E-Mail-Versand – besteht ein Vertrag zur Auftragsverarbeitung, und der Standort des Hostings ist eine bewusste Entscheidung, keine Voreinstellung.

Ein verlässliches Indiz für Sorgfalt: Einwilligungsabfragen erscheinen nur dort, wo sie rechtlich nötig sind. Wer jeden Besucher mit einem maximalen Consent-Banner empfängt, obwohl die Seite kaum etwas trackt, hat den Rahmen nicht durchdacht – sondern kopiert.

8. Übergabe und Eigentum

Am Ende eines professionellen Projekts gehört Ihnen alles: der Zugang zum Quellcode, die Dokumentation (Architekturüberblick, Einrichtung, Betriebshandbuch) und eigene Konten bei allen genutzten Diensten – vom Hosting bis zur Domain. Kein künstliches Lock-in, keine Abhängigkeit von einem Anbieter, der „die Zugänge verwaltet".

Für den Dienstleister kostet das kurzfristig Bindung – und schafft genau dadurch langfristig Vertrauen. Ein Anbieter, der Sie über Qualität hält statt über Abhängigkeit, kann es sich leisten, Ihnen die Tür offen zu lassen. Fragen Sie im Angebot konkret danach: Die Antwort verrät viel über das Selbstverständnis.

9. Professionelle Projektabwicklung

Auch das beste Team scheitert an schlechter Abwicklung. Professionell heißt: Es wird in kurzen Etappen entwickelt, mit lauffähigen Zwischenständen, die Sie ausprobieren können – statt einer Großlieferung nach Monaten. Es ist definiert, wann etwas als „fertig" gilt. Änderungen am Umfang sind willkommen, aber sie haben einen dokumentierten Weg: Was kostet es, was verschiebt sich – schriftlich, bevor gebaut wird.

Seriöse Schätzungen kommen als Bandbreiten, nicht als Punktwerte – wer Ihnen nach einem Telefonat „exakt 47 Tage" nennt, rät. Und für die Zeit nach dem Go-live ist geregelt, was Gewährleistung abdeckt, wie Wartung funktioniert und mit welchen Reaktionszeiten Sie bei Störungen rechnen können.

Der rote Faden: Was passiert, wenn etwas schiefgeht?

Neun Grundlagen, ein Muster: Professionalität zeigt sich nicht im Normalbetrieb – da sehen fast alle Lösungen gut aus. Sie zeigt sich, wenn etwas schiefgeht. Wenn eine neue Version eingespielt wird und etwas bricht. Wenn Daten verloren gehen. Wenn die Person geht, die alles gebaut hat. Wenn sich mitten im Projekt die Anforderungen ändern. Für jeden dieser Momente hat ein professionelles Projekt eine vorbereitete Antwort – und ein unprofessionelles eine Improvisation.

Neun Fragen, mit denen Sie jedes Angebot prüfen können

Sie müssen kein Technikwissen mitbringen – stellen Sie diese Fragen und achten Sie darauf, ob die Antworten konkret sind oder ausweichend:

Wie stellen Sie sicher, dass Sie unser Problem verstehen, bevor Sie bauen?
Was passiert mit der Anwendung, wenn in fünf Jahren neue Anforderungen kommen?
Kann ein anderes Team das Projekt übernehmen – und woran machen Sie das fest?
Wie ist die Anwendung gegen die üblichen Angriffe geschützt, und wer hält sie aktuell?
Wurde die Wiederherstellung der Datensicherung schon einmal wirklich getestet?
Wie schnell lädt die Anwendung auf einem durchschnittlichen Smartphone?
Wer bekommt die DSGVO-Dokumentation – und wann?
Gehören uns Quellcode, Zugänge und Daten – vertraglich festgehalten?
Was kostet eine Änderung am Umfang, und wie wird sie dokumentiert?

Genau nach diesen Grundlagen arbeiten wir – wie, steht offen auf unserer Seite zur individuellen Webentwicklung. Und weil seriöse Kostenaussagen ein geklärtes „Was" voraussetzen, beginnt jedes Projekt bei uns mit einer Analyse- und Konzeptphase zum Festpreis.

Sie planen eine Webanwendung?

In einem unverbindlichen Erstgespräch klären wir, was Ihre Anwendung leisten muss – und was eine Analysephase für Ihr Vorhaben kostet. Die neun Fragen oben dürfen Sie uns dabei gerne stellen.

Erstgespräch vereinbaren