Webdesign für Software und SaaS.

Wir arbeiten mit Festpreisen. Ein einzelnes Produkt mit Funktionsübersicht und Kontakt liegt im Paket Smart. Preisseite, Testzugang und ausgebaute Funktionsseiten führen ins Paket Business, ein Trust-Bereich mit mehreren Sprachen ins Paket Performance. Eine Produktfamilie mit Dokumentation und Blog liegt im Paket Enterprise.

Die ehrlichere Frage ist in dieser Branche aber eine andere: Was kostet es, die Seite selbst zu bauen? Ihr könntet es — und genau deshalb passiert es meistens nicht.

Ihr könntet. Das unterscheidet euch von jeder anderen Branche, für die wir arbeiten. Nur konkurriert die Marketing-Website dann mit dem Produkt-Backlog — und verliert jedes Sprint Planning, weil kein Product Owner eine Landingpage über ein Kundenfeature stellt.

Dazu kommt die Rechnung. Beim medianen Jahresbrutto von rund 74.000 € und Arbeitgeberanteilen liegt ein interner Entwicklertag bei etwa 420 € an reinen Personalkosten, Gemeinkosten noch nicht eingerechnet. Ein Paket Business entspricht damit rund 20 Entwicklertagen — für Konzept, Gestaltung, Umsetzung, Texte und Tests ist das knapp gerechnet. Und diese 20 Tage fehlen am Produkt.

Was wir regelmäßig sehen: Die Seite wird zu zwei Dritteln gebaut, dann kommt ein Release dazwischen, und sie bleibt ein Jahr in diesem Zustand.

Das ist eine Vertriebsentscheidung, keine Designfrage, und beide Antworten sind vertretbar. Wer Preise zeigt, qualifiziert vor: Unpassende Interessenten melden sich gar nicht erst, passende kommen informiert ins Gespräch. Wer sie verbirgt, erzwingt den Kontakt — und verliert alle, die sich nicht erst verkaufen lassen wollen.

Entscheidend ist, dass die Seite zu dem passt, was danach passiert. Eine Preisseite mit „ab“-Angaben und einem ehrlichen Hinweis darauf, was den Preis treibt, funktioniert fast immer besser als beides in Reinform. Was nicht funktioniert: eine Preisseite, deren Zahlen im ersten Angebot nicht wieder auftauchen.

Diese Frage entscheidet die gesamte Struktur, nicht nur einen Button. Ein Produkt, das sich selbst erklärt und ohne Einrichtung nutzbar ist, braucht einen kurzen Weg zur Registrierung und eine Seite, die wie eine Anleitung funktioniert. Ein erklärungsbedürftiges Produkt mit Einführungsprojekt braucht das Gegenteil: eine Seite, die den Nutzen beweist, und einen Demo-Termin mit klarer Erwartung.

Beides zugleich anzubieten ist der häufigste Fehler. Dann steht der Testzugang neben dem Demo-Formular, und der Besucher entscheidet nicht, sondern geht. Wenn ihr beide Wege braucht, trennen wir sie nach Zielgruppe oder Produktgröße — nicht nebeneinander auf derselben Seite.

Sobald ihr Unternehmenskunden gewinnen wollt: ja. Der Einkauf und die IT-Sicherheit des Kunden prüfen euch, bevor jemand mit euch spricht. Gesucht werden Hosting-Standort, Zertifizierungen, Verfügbarkeitszusagen, der Vertrag zur Auftragsverarbeitung, die Liste der Unterauftragsverarbeiter und ein Weg, Sicherheitslücken zu melden.

Diese Angaben an einer Stelle zu bündeln verkürzt den Einkaufsprozess spürbar. Wer sie erst auf Nachfrage per E-Mail herausgibt, verliert jedes Mal eine Woche — und wirkt dabei unvorbereitet auf genau die Leute, die den Vertrag freigeben müssen.

Die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten, ohne nationale Umsetzung. Sie erfasst Banken, Versicherer, Zahlungs- und E-Geld-Institute sowie Wertpapierfirmen — und darüber hinaus deren Drittanbieter von IKT-Dienstleistungen.

Für euch heißt das: Wenn ihr Finanzunternehmen beliefert, wirkt DORA über die Verträge auf euch durch. Der Einkauf eures Kunden prüft entsprechend härter, und zwar früher als früher. Auf der Website schlägt sich das nicht in juristischen Texten nieder, sondern in Belegen — Zertifizierungen, Hosting, Verfügbarkeit, Meldewege, Unterauftragsverarbeiter. Wer das vorhält, kommt in Gespräche, aus denen andere herausfallen.

Ja. Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der KI-Verordnung. Systeme, die unmittelbar mit Menschen interagieren — Chatbots, Sprachassistenten — müssen so gestaltet sein, dass die Person erfährt, dass sie mit einem KI-System spricht, sofern das nicht ohnehin offensichtlich ist.

Dazu kommen weitere Pflichten: Anbieter generativer Systeme müssen synthetische Inhalte maschinenlesbar kennzeichnen, der Einsatz von Emotionserkennung muss offengelegt werden. Der Bußgeldrahmen reicht bis 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes.

Das betrifft zwei Dinge gleichzeitig: euer Produkt, wenn es KI-Funktionen hat, und eure Website, wenn dort ein Chatbot läuft. Wir prüfen beim Projekt mit, was auf der Seite eingebunden ist — Support-Widgets sind hier der häufigste blinde Fleck.

Fast nie über die eigene Kategorie. Wir haben das für diese Branche geprüft, und das Ergebnis ist lehrreich: Der naheliegende Begriff „webdesign software“ hat durchaus Suchvolumen — nur suchen die Leute dahinter eine Software zum Erstellen von Websites, nicht einen Dienstleister. Eine Intent-Falle.

Dasselbe Muster gilt für euer Produkt. Gesucht wird das Problem, nicht die Produktkategorie: nicht die Branchensoftware, sondern die Aufgabe, die sie löst, oft zusammen mit dem Namen des Systems, das abgelöst werden soll. Deshalb bauen wir Seiten entlang von Anwendungsfällen und Problemen statt entlang eurer Funktionsliste — und prüfen vorher, was hinter einem Begriff tatsächlich gesucht wird.

So, dass es möglichst wenig Zeit kostet. Die Marketing-Website läuft getrennt von eurer Anwendung, mit eigenem Redaktionssystem und eigenem Deployment — euer Team muss also nichts freigeben, nichts mitdeployen und nichts mitwarten.

Berührungspunkte gibt es trotzdem, und die klären wir vorher: gemeinsame Domain und Routing, Übergabe in die Anwendung beim Login oder bei der Registrierung, einheitliche Gestaltung zwischen Website und Produkt, Nachverfolgung über beide Systeme hinweg. Wo ihr ein Design-System habt, nutzen wir es, statt ein zweites zu erfinden.