Individuelle Web-App vs. SaaS Von Der Stange

Fast keine Entwicklung einer individuellen Web-App beginnt mit einem Lastenheft. Sie beginnt mit einer Tabelle, die jemand angelegt hat, um eine einzige Sache zu verfolgen, die dann eine zweite Spalte bekam, dann ein Register, dann eine Formel, die nur eine Person versteht. Drei Jahre später hält diese Datei den Terminplan, die Preise und die Hälfte der Kundendaten, vier Leute bearbeiten sie gleichzeitig, und niemand kann mit Sicherheit sagen, welche Kopie die aktuelle ist.

Das ist der eigentliche Entscheidungspunkt, und es ist nicht der, den die meisten Artikel über Bauen oder Kaufen behandeln. Sie wählen nicht zwischen einem leeren Blatt und einem Produkt. Sie wählen zwischen drei Auswegen aus einem funktionierenden, aber brüchigen Prozess: ein Produkt kaufen, etwas auf einer No-Code-Plattform zusammensetzen oder Software in Auftrag geben, die Ihrer Arbeitsweise folgt.

Sollten Sie eine individuelle Web-App bauen oder SaaS kaufen? Kaufen Sie, außer wenn mindestens zwei von drei Bedingungen gelten: Der Prozess ist ein Wettbewerbsvorteil statt Gemeinkosten, kein Produkt passt dazu, ohne Ihre Arbeitsweise zu verzerren, und die Integrationsarbeit macht den Großteil des Auftrags aus. Gilt nur eine davon, ist ein Produkt plus Konfiguration fast immer billiger. Ein Individualbau trägt zudem eine laufende Kostenuntergrenze von rund 15 bis 20 Prozent des Baupreises pro Jahr, und zwar dauerhaft.

Die Tabelle, die tragend wurde

Das Muster ist konkret genug, um ihm einen Namen zu geben, und an diesem Namen erkennt sich ein Team meist selbst.

Es beginnt mit einer Person und einem Zweck. Jemand muss wissen, welche Aufträge diese Woche gebucht sind, also legt er eine Tabelle an. Eine zweite Person muss sie lesen, also wandert sie auf ein gemeinsames Laufwerk. Dann muss eine dritte sie bearbeiten, also tippen jetzt mehrere gleichzeitig in dieselben Zellen. Dann ein Register pro Monat. Dann ein Abgleich gegen eine zweite Datei. Dann ein Makro, geschrieben von einem Auftragnehmer, der längst weg ist.

Die Anzeichen sind immer dieselben. Die Datei trägt ein Datum und ein Versionskürzel im Namen. Es gibt eine Hauptkopie, und jeder weiß, wer sie hält. Eine neue Kollegin einzuarbeiten heißt, ihr die Datei zu zeigen, statt ihr den Prozess zu erklären, weil der Prozess nirgendwo sonst niedergeschrieben ist.

An diesem Punkt ist die Tabelle kein Dokument mehr. Sie ist eine Anwendung ohne Zugriffskontrolle, ohne Änderungsprotokoll, ohne Validierung, ohne eine Sicherungsstrategie, die Sie verteidigen würden, und mit genau einem Betreuer. Sie funktioniert, und genau deshalb hat niemand sie ersetzt, und genau deshalb ist ihr Ersatz jetzt teuer.

Was der Status quo tatsächlich kostet

Niemand beziffert die Tabelle, also wirkt sie kostenlos. Das ist sie nicht, und die Rechnung lässt sich für das eigene Unternehmen leicht aufmachen.

Fangen Sie beim Abtippen an. Wenn zwei Personen je 45 Minuten am Tag damit verbringen, Daten zwischen der Tabelle, der Buchhaltungssoftware und einem gemeinsamen Postfach zu bewegen, sind das siebeneinhalb Stunden pro Woche oder rund 340 Stunden in einem Arbeitsjahr von 45 Wochen. Bei voll belasteten GBP 22 pro Stunde geben Sie etwa GBP 7.500 im Jahr dafür aus, Zahlen von einem Bildschirm auf den nächsten zu übertragen, und das kauft nichts außer der Gelegenheit für einen Tippfehler.

Dann kommt der Abgleich, bei dem jemand die Tabelle monatlich gegen die maßgebliche Quelle prüft und einen halben Tag damit zubringt, zu entscheiden, welche Fassung stimmt. Dann kommen spät entdeckte Fehler: das Angebot zum Preis des Vormonats, der doppelt gebuchte Auftrag, die versäumte Verlängerung. Jeder einzelne ist ein kleiner Betrag und ein verärgerter Kunde, und keiner taucht in irgendeiner Budgetzeile auf.

Dann kommt das Personenrisiko. Eine Person versteht die Formeln, und wenn diese Person krank, im Urlaub oder fort ist, sinkt der Prozess auf Raten ab.

Personenbezogene Daten in einer Tabelle bleiben regulierte Daten

Wenn die Datei Namen, Kontaktdaten, Personalakten oder Kundeninformationen enthält, sind das personenbezogene Daten, und die UK GDPR gilt dafür genauso wie für eine Datenbank.

Die ICO ist deutlich darin, was das verlangt. Ihr Leitfaden zur Datensicherheit hält fest, dass ein Kernprinzip der UK GDPR die sichere Verarbeitung personenbezogener Daten durch geeignete technische und organisatorische Maßnahmen ist und dass diese Maßnahmen die Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Systeme und der darin enthaltenen personenbezogenen Daten sicherstellen müssen. Eine Tabelle auf einem Notebook kennt keine zeilenweisen Berechtigungen, keine Löschfrist und keine Aufzeichnung darüber, wer was gelesen hat, und sie vervielfältigt sich vollständig, sobald jemand sie per E-Mail verschickt.

Die Folgen sind nicht theoretisch. Im Oktober 2024 verhängte die ICO eine Geldbuße von GBP 750.000 gegen den Police Service of Northern Ireland, nachdem verborgene Daten in einer Tabelle, die auf eine Informationsfreiheitsanfrage hin herausgegeben wurde, die Nachnamen, Initialen, Dienstgrade und Funktionen aller 9.483 PSNI-Beschäftigten offengelegt hatten. Der Bescheid nennt die Artikel 5(1)(f), 32(1) und 32(2). Ohne das Vorgehen der ICO gegenüber dem öffentlichen Sektor hätte die Buße GBP 5,6 Millionen betragen.

Jede Organisation, die einen Prozess auf Tabellen betreibt, hat irgendwo ein solches Arbeitsblatt.

Das Produkt kaufen: wann SaaS offensichtlich richtig ist

Das ist meistens die Antwort, und sie verdient es, zuerst vertreten und nicht in einem Schlussabsatz abgetan zu werden.

Wenn Ihr Prozess ein verbreiteter ist, gibt es das Produkt, und es ist billiger als alles, was Sie bauen könnten. Lohnabrechnung, Spesen, Ticketsysteme, Terminbuchung, elektronische Signatur, Buchhaltung, Bewerbermanagement. Jemand hat ein Jahrzehnt und ein großes Entwicklungsteam auf die Sonderfälle verwendet, die Ihnen noch gar nicht begegnet sind: den Schaltjahrfehler, die geänderte Mehrwertsteuer, die Erstattung, die nach dem Periodenabschluss eintrifft.

Sie kaufen außerdem Arbeit ein, die Sie sonst selbst bezahlen. Der Anbieter trägt die Verfügbarkeit, die Sicherheitsupdates, den Browserwandel, die Barrierefreiheit und die Compliance-Nachweise, nach denen Ihre Kunden fragen. Nichts davon erscheint als Funktion, und alles davon ist echtes Geld.

Der ehrliche Test ist nicht, ob das Produkt alles kann. Er lautet, ob es die wichtigen 80 Prozent erledigt, ohne Sie zu zwingen, etwas zu ändern, das Ihnen wichtig ist. Wenn die einzige Abweichung darin besteht, dass Ihr Team von einem Auftrag spricht und die Software von einem Ticket, kaufen Sie die Software und ändern Sie das Wort.

Die drei Bedingungen, die individuelle Web-App-Entwicklung rechtfertigen

Ein Individualbau wird durch Strategie gerechtfertigt, nicht durch Ärger. Es gibt drei Bedingungen, die ihn wirklich tragen, und die brauchbare Regel lautet, dass Sie mindestens zwei davon brauchen. Eine Bedingung allein löst sich fast immer billiger mit einem Produkt plus Konfiguration. Derselbe Test gilt auf Konzernebene, was unser Leitfaden zu Bauen oder Kaufen bei CRM und ERP in einer anderen Größenordnung behandelt.

Der Prozess ist ein Unterscheidungsmerkmal, keine Gemeinkosten

Fragen Sie, was ein Kunde bemerken würde, wenn der Prozess doppelt so gut wäre. Lautet die Antwort nichts, sind es Gemeinkosten, und Sie sollten kaufen, denn eine hervorragende Lohnabrechnung gewinnt Ihnen kein Geschäft. Aber ein spezialisierter Monteurbetrieb, dessen Einsatzplanung jedem Fahrzeug einen zusätzlichen Auftrag pro Tag abringt, oder ein Kreditgeber, dessen Prüfregeln sein eigentliches Produkt sind, führt Wettbewerbsvorteil durch diese Software. Sie können keinen Vorteil kaufen, den Ihre Wettbewerber zum selben Monatspreis kaufen können.

Kein Produkt passt, ohne den Prozess zu verzerren

Jedes Produkt kodiert Annahmen darüber, wie Arbeit fließt, und das Anzeichen dafür, dass sie für Sie falsch sind, ist, dass die Einführung Sie zwingen würde, etwas Profitables aufzugeben. Wenn Ihr Unternehmen auf einer Grundlage kalkuliert, die das Produkt nicht abbilden kann, und genau diese Kalkulation der Grund ist, warum Kunden Sie wählen, verlangt das Produkt von Ihnen, gewöhnlicher zu werden, im Tausch gegen eine Lizenzgebühr.

Die Integrationsfläche ist die eigentliche Arbeit

Manchmal liegt der interessante Teil gar nicht in den Bildschirmen. Er liegt darin, Bestände aus einem System zu ziehen, Preise aus einem zweiten, Technikerverfügbarkeiten aus einem dritten und das Ergebnis in ein viertes zu schreiben. Wenn der größte Teil des Aufwands Integration ist, ist die Oberfläche nur eine dünne Schicht über Ihrer eigenen Verrohrung, und die mitgelieferten Masken eines Produkts sind der Teil, den Sie am wenigsten brauchen. Diese Bedingung wird am häufigsten unterschätzt, und hier wohnt die Falle in der Mitte.

Die Falle in der Mitte: kaufen und dann doch bauen

Das teuerste Ergebnis ist keiner der beiden Wege, sauber gegangen. Es ist, ein Produkt zu kaufen, weil es billiger aussah, dann mehr für dessen Anpassung an Ihren Prozess auszugeben, als ein Individualbau gekostet hätte, und die Lizenz weiterhin zu zahlen.

Es passiert schleichend, und jeder einzelne Schritt ist begründbar. Das Produkt passt nicht, also holen Sie einen Implementierungspartner. Der Partner schreibt Konfiguration in der proprietären Skriptschicht des Anbieters, was Code ist, sich aber nicht wie Code anfühlt, weil es im Produkt lebt. Dann soll es mit zwei weiteren Systemen sprechen, also kaufen Sie eine Integrationsplattform. Dann liefert der Anbieter eine Hauptversion aus, und Ihre Anpassungen brauchen einen Regressionstest.

An diesem Punkt haben Sie alle Kosten von Individualsoftware und nichts von deren Eigentum: eine Codebasis, die Sie nicht lesen können, betrieben an einem Ort, den Sie nicht kontrollieren, geschrieben in einer Sprache, die in genau einem Produkt existiert, gepflegt von einem Partner, dessen Tagessatz nun eine Zeile in Ihrem Budget ist. Unser Leitfaden zu den Kosten individueller Softwareentwicklung zeigt, wie sich diese Zahlen summieren.

Warnzeichen, dass Sie in der Falle sitzen

Die Falle ist leichter zu erkennen als zu verlassen, und die Signale sind eindeutig, sobald man nach ihnen sucht.

• Das Honorar des Implementierungspartners ist höher als die Lizenzgebühr des ersten Jahres.
• Jemand verbringt faktisch eine Vollzeitstelle damit, ein einziges Produkt zu verwalten.
• Sie haben Logik in der proprietären Skriptsprache des Anbieters geschrieben, und niemand außerhalb Ihres Unternehmens kann sie lesen.
• Jedes Upgrade des Anbieters löst einen Regressionstest Ihrer Anpassungen aus, also schieben Sie Upgrades auf.
• Sie zahlen für eine Integrationsplattform, die nur existiert, um dieses eine Produkt mit Daten zu versorgen.
• Sie pflegen neben dem Produkt eine Schattentabelle, weil das Produkt etwas nicht ausdrücken kann, das Sie brauchen.

Der letzte Punkt ist der klarste. Wenn die Tabelle den Softwarekauf überlebt hat, hat die Software das Problem nicht gelöst.

No-Code und Low-Code als ernsthafter dritter Weg

Die Frage No-Code oder Individualbau verdient mehr als eine Fußnote, denn für die Entwicklung interner Werkzeuge sind Low-Code-Plattformen häufig die richtige Antwort, und sie sind kein Spielzeug.

Plattformen wie Airtable, Retool und Microsoft Power Apps lassen Sie eine echte Mehrbenutzeranwendung mit Datenbank, Formularen, Berechtigungen und Automatisierungen bauen, in Tagen statt Monaten und ohne jemanden einzustellen. Sie übernehmen Hosting, Sicherungen, Anmeldung und mobiles Layout. Für die konkrete Aufgabe, eine tragende Tabelle in etwas mit ordentlicher Zugriffskontrolle und Änderungsprotokoll zu überführen, sind sie häufig der schnellste Weg zu einer großen Risikominderung.

Sie werden außerdem pro Platz bepreist, und diese Tatsache entscheidet darüber, ob sie die richtige Antwort bleiben, wenn Sie wachsen.

Wo No-Code wirklich gewinnt

Es gewinnt, wenn die Form des Problems aus Datensätzen, Formularen, Ansichten und einfachen Regeln besteht: ein Anlagenverzeichnis, eine Freigabewarteschlange, eine Checkliste für das Onboarding von Kunden, eine Raumbuchung. Am stärksten gewinnt es, wenn die Person, die den Prozess versteht, ihn selbst bauen kann, denn dann müssen die Anforderungen nie die Übersetzung in ein Lastenheft und zurück überstehen.

Es gewinnt auch bei der Zeit bis zum Nutzen. Ein funktionierendes Werkzeug in zwei Wochen, das täglich benutzt wird, schlägt ein perfektes in sechs Monaten, das noch im Entwurf steckt, und die gebaute Fassung lehrt Sie, wie die Anforderungen wirklich lauteten.

Wo No-Code an eine Wand stößt

Die Wand ist meist eines von fünf Dingen. Leistung bei echten Zeilenzahlen, sobald eine Ansicht Hunderttausende Datensätze filtern muss. Berechtigungen mit echter Komplexität, etwa zeilenweise Regeln, die vom Zustand des Datensatzes und vom Team des Betrachters abhängen. Transaktionale Integrität, bei der zwei Dinge entweder beide oder gar nicht geschehen müssen. Tests und Versionsverwaltung, weil es oft keine Möglichkeit gibt, eine Änderung vor dem Livegang zu prüfen. Und alles mit einem echten Zustandsautomaten, bei dem Regeln bestimmen, welche Übergänge zulässig sind.

Sie stoßen nicht allmählich an die Wand. Sie stoßen an sie, wenn sich eine Änderung, die eine Stunde dauern sollte, als unmöglich herausstellt.

Was Preise pro Platz im großen Maßstab anrichten

Preise pro Platz sind bei zehn Nutzern günstig und können bei vierhundert nicht mehr zu rechtfertigen sein, und die veröffentlichten Sätze machen das leicht vorführbar.

Die Preisseite von Retool führt den Business-Tarif für die UK-Cloud mit GBP 40 pro Monat und Entwickler sowie GBP 12 pro internem Nutzer, den Team-Tarif mit GBP 8 und GBP 4. Microsoft listet Power Apps Premium mit GBP 16,90 pro Nutzer und Monat bei jährlicher Zahlung, zuzüglich Mehrwertsteuer, fallend auf GBP 10,80 ab einer Mindestabnahme von 2.000 Plätzen. Airtable veröffentlicht Team mit USD 20 und Business mit USD 45 pro Nutzer und Monat, beide jährlich in US-Dollar abgerechnet.

Rechnen Sie das hoch. Vierzig Nutzer auf Retool Business, drei davon Entwickler, ergeben rund GBP 6.800 im Jahr. Dieselbe Form bei vierhundert Nutzern liegt bei etwa GBP 59.600 im Jahr, und sie steigt erneut, sobald Sie Personen hinzufügen. Bei Power Apps Premium kosten vierhundert Plätze etwa GBP 81.000 im Jahr vor Mehrwertsteuer.

Keiner dieser Sätze ist unangemessen. Der Punkt ist, dass die Rechnung der Kopfzahl folgt und nicht dem gelieferten Wert, und die Kopfzahl wächst.

Das Ausstiegsproblem, wenn Logik in einem proprietären Werkzeug lebt

Jede Plattform exportiert Ihre Daten. Keine exportiert Ihre Anwendung.

Die Zeilen kommen als CSV oder über eine Schnittstelle heraus, und das ist der Teil, den vor der Unterschrift jeder prüft. Nicht heraus kommt das, was Sie gebaut haben: die Automatisierungen, die Formelspalten, die Berechtigungsregeln, die bedingten Formulare, der Ablauf, der aus einer Anfrage drei Benachrichtigungen und eine Statusänderung macht. Diese Logik ist der Vermögenswert, sie hat Monate an Entscheidungen gekostet, und nur die Laufzeitumgebung eines einzigen Anbieters kann sie ausführen.

Die praktische Folge ist, dass das Verlassen einer Low-Code-Plattform keine Migration ist, sondern ein Neubau. Sie bekommen Ihre Daten zurück und schreiben die Anwendung anderswo noch einmal, aus einer Spezifikation, die nie aufgeschrieben wurde, weil die Plattform die Spezifikation war.

Das ist kein Argument gegen den Einsatz einer solchen Plattform, sondern nur dafür, eine schriftliche Beschreibung der Regeln außerhalb des Werkzeugs zu führen.

Gesamtkosten über fünf Jahre für die drei Wege

Der Vergleich, den man üblicherweise anstellt, ist auf eine bestimmte Weise unehrlich: Er stellt die voll kalkulierte Fassung des einen Weges dem Listenpreis des anderen gegenüber. Nehmen Sie vierzig Nutzer und eine betriebliche Anwendung, die eine Tabelle und zwei kleine Abonnements ersetzt. Die Zahlen sind illustrative Planungswerte, keine Angebote, und Ihr Baupreis ist die Größe, die sich am stärksten bewegt.

In Prosa gelesen: Bei vierzig Nutzern gewinnt die No-Code-Plattform mit rund GBP 75.800 über fünf Jahre. Der Individualbau landet mit etwa GBP 94.500 auf dem zweiten Platz, weil ein Bau für GBP 45.000 plus GBP 1.800 Hosting und GBP 8.100 jährlicher Wartung die gestapelte Lizenz, Middleware und Verwaltung des SaaS-Weges immer noch schlägt. Das Produkt zu kaufen kommt mit etwa GBP 135.000 zuletzt, und zwar wegen der Falle in der Mitte und nicht wegen der Lizenz allein.

Warum sich dieselbe Tabelle bei vierhundert Nutzern umkehrt

Ändern Sie eine einzige Größe, die Kopfzahl, und die Reihenfolge kehrt sich vollständig um. Das ist der mit Abstand häufigste Grund, aus dem ein Bau rational wird.

Bei vierhundert Nutzern kostet die SaaS-Lizenz zu GBP 30 pro Platz und Monat allein GBP 144.000 im Jahr, und mit derselben Middleware und einem größeren Verwaltungsaufwand übersteigt die Summe über fünf Jahre GBP 800.000. Der No-Code-Weg landet nahe GBP 375.000. Der Individualbau bewegt sich kaum: Mehr Nutzer bedeuten eine etwas größere Hosting-Rechnung und ein etwas größeres Wartungsbudget, sodass selbst eine Verdopplung des Baupreises auf GBP 70.000 eine Fünfjahressumme nahe GBP 153.000 lässt.

Der Grund ist struktureller Natur. Preise pro Platz sind variable Kosten, die mit Ihrer Organisation wachsen, während ein Individualsystem Fixkosten plus einen kleinen variablen Anteil hat, und dieser Anteil ist Infrastruktur, die billig ist. Ob die Umkehr für Sie zählt, ist eine unternehmerische Prognose und kein technisches Urteil.

Die laufende Kostenuntergrenze eines Individualbaus

Die Zeile, die man in einer Individualschätzung weglässt, ist die, die nie aufhört. Eine maßgeschneiderte Anwendung hat eine Kostenuntergrenze, und diese fällt auch in einem ruhigen Jahr ohne Featurewünsche nicht auf null.

Die Untergrenze besteht aus Hosting, Überwachung, Sicherungen, deren Wiederherstellung Sie getestet haben, TLS-Zertifikaten, Sicherheitsupdates, Aktualisierungen von Abhängigkeiten und jemandem, der ans Telefon geht, wenn es montags um neun ausfällt. Planen Sie mit rund 15 bis 20 Prozent der ursprünglichen Baukosten pro Jahr. Das ist eine Planungsannahme aus dem Verhalten solcher Projekte und keine veröffentlichte Statistik, aber es ist die Zahl, gegen die wir budgetieren, und ein Angebot ohne diese Zeile ist kein vollständiges Angebot. Unser Beitrag zu den Softwarewartungskosten schlüsselt das weiter auf.

Jede Fünfjahressumme für den Individualbau oben setzt voraus, dass diese Zeile finanziert ist. Projekte, die sie auslassen, sparen das Geld nicht, sie verschieben es und zahlen es später als Neubau, und genau das beschreibt technische Schuld.

Nicht gewartete Software verfällt

Eine Anwendung, die zwei Jahre unangetastet lief, ist nicht stabil. Sie ist ungepatcht, und dieser Unterschied zählt.

An Ihrem Code hat sich nichts geändert, aber an allem um ihn herum. Sprachlaufzeiten erreichen ihr Lebensende nach einem veröffentlichten Zeitplan: Node.js unterstützt derzeit Version 26 als Current sowie die Versionen 24 und 22 als aktive LTS-Linien, was bedeutet, dass alles auf Version 20 oder früher ohne Unterstützung ist und keine Sicherheitskorrekturen mehr erhält. Abhängigkeiten sammeln veröffentlichte Schwachstellen an. Browser ändern, wie sie Cookies und Speicher behandeln. Zahlungsdienstleister stellen Schnittstellenversionen ein und setzen Ihnen eine Frist.

Nichts davon ist Ihre Schuld, und alles davon ist Ihr Problem, denn in einem maßgeschneiderten System gibt es keinen Anbieter, der es für Sie auffängt. Das ist der echte, strukturelle Vorteil des Kaufens: Das Entwicklungsteam eines anderen verbringt jede Woche damit, den Boden am Verrotten zu hindern, und die Lizenzgebühr ist der Preis dafür. Ihr eigenes Wartungsbudget kauft genau dieselbe Arbeit, und Sie zahlen sie entweder bewusst oder im Notfall.

Ihren eigenen Umschlagpunkt pro Platz bestimmen

Sie können den Umschlagpunkt in etwa zehn Minuten ausrechnen, und er überzeugt eine Finanzleitung mehr als jedes Argument über Eigentum.

Nehmen Sie die monatlichen Kosten des Produktweges, alles inklusive: Lizenz, Middleware und den Gehaltsanteil, der in die Verwaltung fließt. Ziehen Sie die monatlichen Betriebskosten eines Individualsystems ab, also Hosting plus ein Zwölftel des jährlichen Wartungsbudgets. Teilen Sie den Baupreis durch das, was übrig bleibt. Das Ergebnis ist die Zahl der Monate, bis sich der Bau bezahlt gemacht hat.

Für vierzig Nutzer durchgerechnet: Der SaaS-Weg läuft mit etwa GBP 2.150 im Monat, das Individualsystem mit etwa GBP 825, die monatliche Ersparnis liegt also bei rund GBP 1.325. Ein Bau für GBP 45.000 passt darin etwa 34 Mal, die Amortisation liegt somit bei knapp zwei Jahren und zehn Monaten. Bei vierhundert Nutzern fällt sie unter ein Jahr.

Zwei Einschränkungen. Der Baupreis ist hier die unsicherste Zahl, rechnen Sie ihn deshalb mit Ihrem Angebot und noch einmal mit 50 Prozent mehr. Und eine Amortisation von mehr als etwa drei Jahren ist ein schwacher Fall, denn Ihr Prozess überlebt so lange womöglich nicht unverändert.

Daten und Bindung schneiden in beide Richtungen

Anbieterbindung ist das übliche Argument fürs Bauen, und sie ist real. Sie ist auch nur die halbe Wahrheit, denn ein Individualsystem, das niemand dokumentiert hat, ist ebenfalls gebunden.

Prüfen Sie auf der Produktseite vor der Unterschrift, was tatsächlich herauskommt. Datensätze lassen sich meist sauber exportieren. Anhänge, historische Prüfprotokolle, Kommentarverläufe, Berechtigungsstrukturen und die Beziehungen zwischen Datensätzen häufig nicht. Der praktische Maßstab ist nicht, ob es eine Exportschaltfläche gibt, sondern ob Sie allein aus dem Export einen funktionierenden Ersatz aufbauen könnten.

Auf der Individualseite ist das gleiche und entgegengesetzte Risiko ein System, das ein einzelner Auftragnehmer gebaut hat, ohne README, ohne Tests, ohne Betriebshandbuch, mit Zugangsdaten in einer Konfigurationsdatei auf einem Notebook und einem Repository im privaten Konto von jemandem. Das ist schlimmer als SaaS-Bindung, denn der Anbieter ist wenigstens noch am Markt.

Die Gegenmittel sind vertraglich und zu Beginn billig einzufordern. Besitzen Sie das Repository selbst, verlangen Sie Dokumentation und ein Betriebshandbuch als benannte Liefergegenstände, und verlangen Sie, dass eine zweite Entwicklerin das System allein aus dieser Dokumentation ausrollen kann. Prüfen Sie das vor der Schlusszahlung. Unser vollständiger Käuferleitfaden behandelt die Vertragsklauseln ausführlicher.

Sicherheit und Compliance in den einzelnen Modellen

Die Aufteilung der Verantwortung unterscheidet sich je nach Weg, aber eine Sache bewegt sich überhaupt nicht, und hier liegt ein verbreiteter Irrtum.

Unter der UK GDPR sind Sie der Verantwortliche. Die ICO definiert den Verantwortlichen als die Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung personenbezogener Daten entscheidet, und den Auftragsverarbeiter als die Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet. Ihr SaaS-Anbieter ist fast immer der Auftragsverarbeiter. Sie bleiben dafür verantwortlich, die Einhaltung nachzuweisen, und die ICO sagt ausdrücklich, dass ein Verantwortlicher für seine Auftragsverarbeiter einsteht und einen bindenden Vertrag mit den nach Artikel 28(3) erforderlichen Bestimmungen halten muss.

Was der Anbieter wirklich trägt, ist die Infrastrukturebene: physische Sicherheit, Plattform-Patches, Netzwerkkontrollen und oft Zertifizierungen. Das Modell der geteilten Verantwortung des NCSC ist klar darin, dass Ihnen selbst mit SaaS drei Dinge bleiben: zu beurteilen, ob der Dienst Ihren Sicherheitsanforderungen genügt, ihn sicher zu konfigurieren und zu entscheiden, welche Daten Sie hineingeben.

In einem Individualbau erben Sie zusätzlich die gesamte technische Ebene: Patches, Zugriffskontrolle, Verschlüsselung, Protokollierung, Sicherung und Wiederherstellung. Unser Beitrag zur technischen DSGVO-Umsetzung zeigt, wie das im Code aussieht. Die rechtliche Lage ändert sich zwischen den Wegen nicht.

Barrierefreiheit gilt auch für interne Werkzeuge

Interne Werkzeuge werden regelmäßig so gebaut, als könnte niemand, der sie benutzt, eine Behinderung haben, was falsch ist und für manche Organisationen zudem rechtswidrig.

Nach Abschnitt 20 des Equality Act 2010 hat ein Arbeitgeber die Pflicht zu angemessenen Vorkehrungen, einschließlich der Schritte, die vernünftigerweise zu ergreifen sind, um einen erheblichen Nachteil durch eine Regelung, ein Kriterium oder eine Praxis zu vermeiden, sowie der Bereitstellung von Hilfsmitteln. Ein Dienstplansystem, das sich nicht mit der Tastatur bedienen lässt, versetzt eine beschäftigte Person mit Behinderung in einen erheblichen Nachteil, und es gibt keine Ausnahme für Software, die Ihre Kunden nie sehen.

Für Organisationen des öffentlichen Sektors ist die Lage ausdrücklich geregelt. Die Anleitung von GOV.UK zu den Anforderungen an die Barrierefreiheit hält fest, dass Intranet- und Extranet-Auftritte von den Barrierefreiheitsvorschriften erfasst sind, dass sie WCAG 2.2 AA erfüllen müssen und dass ältere interne Auftritte, die vor dem 23. September 2019 veröffentlicht wurden, bei einer Aktualisierung barrierefrei gemacht werden müssen.

Die Kriterien, an denen interne Werkzeuge am häufigsten scheitern, sind die banalen: 2.1.1 Tastatur und 3.3.2 Beschriftungen oder Anweisungen auf Stufe A, 1.4.3 Kontrast (Minimum) auf Stufe AA sowie unter den Ergänzungen von WCAG 2.2 die Kriterien 2.4.11 Fokus nicht verdeckt (Minimum) und 2.5.8 Zielgröße (Minimum), beide auf Stufe AA.

Barrierefreiheit ist bei No-Code eine Decke, die Sie nicht kontrollieren

Das ist der Punkt zur Barrierefreiheit, der eine Entscheidung zwischen Bauen und Kaufen verändert, statt ihr nur Arbeit hinzuzufügen.

Auf einer No-Code-Plattform schreiben Sie das Markup nicht. Die Plattform erzeugt es, also ist die Barrierefreiheit Ihrer Anwendung durch die der Komponentenbibliothek der Plattform gedeckelt. Wenn deren Datumsauswahl sich nicht per Tastatur bedienen lässt oder deren Dialog den Fokus schlecht hält, können Sie das nicht reparieren. Sie können ein Support-Ticket eröffnen und warten.

Das ist in Ordnung, solange die Decke hoch genug ist, und mehrere Plattformen nehmen das Thema ernst. Es ist nicht in Ordnung, wenn Sie eine konkrete Verpflichtung, eine konkrete beschäftigte Person oder eine Pflicht des öffentlichen Sektors haben, denn dann liegt die Abhilfe außerhalb Ihrer Kontrolle und außerhalb Ihres Zeitplans.

In einem Individualbau ist die Arbeit an der Barrierefreiheit Ihre Sache, was anfangs mehr kostet und die Abhängigkeit beseitigt. Fragen Sie jeden in Frage kommenden Anbieter nach einer Konformitätserklärung zur Barrierefreiheit, bevor Sie einen Prozess um seine Komponenten herum entwerfen, und werten Sie deren Fehlen als Antwort.

Einen Individualbau mit einer dünnen ersten Scheibe entschärfen

Individualprojekte scheitern meist nicht an der Technik. Sie scheitern daran, das gesamte Budget auf eine Spezifikation zu verpflichten, die geschrieben wurde, bevor jemand irgendetwas benutzt hatte.

Die Alternative ist eine dünne Scheibe: ein Arbeitsablauf, durchgängig, im Produktivbetrieb, von einer echten Person bei echter Arbeit benutzt, in sechs bis acht Wochen. Kein Prototyp und keine Demo, sondern der schmalste Pfad durch das System, der ein echtes Ergebnis erzeugt, mit echten Daten, echter Anmeldung und echter Auslieferung. Ist der Prozess das Angebotswesen, dann erstellt die Scheibe ein Angebot, kalkuliert es und verschickt es.

Diese Scheibe leistet vier Dinge, die eine Spezifikation nicht kann. Sie beweist die Integrationen, und dort wohnen die Überraschungen. Sie misst die tatsächliche Liefergeschwindigkeit des Teams, statt sie zu schätzen. Sie stellt der Person, deren Prozess es ist, funktionierende Software hin, was die Anforderungen zuverlässig verändert. Und sie gibt Ihnen einen Ausstieg: Sie haben einen festgelegten Betrag ausgegeben und besitzen etwas, das funktioniert.

Setzen Sie dort dann schriftlich einen Entscheidungspunkt, bevor die größere Ausgabe freigegeben wird. Unser Leitfaden zum Bau einer Web-App behandelt die technische Gestalt einer ersten Scheibe, und unsere Seite zu den Leistungen der Softwareentwicklung erklärt, wie wir eine solche zuschneiden.

Ein Entscheidungsrahmen, den Sie an einem Nachmittag durchlaufen

Nichts davon braucht ein Beratungsmandat. Es braucht ein paar Stunden und Ehrlichkeit bei den Zahlen.

Schreiben Sie erstens den Prozess so auf, wie er tatsächlich läuft, in Schritten, einschließlich der Ausnahmen, die Menschen von Hand erledigen. Das allein beendet die Debatte oft, weil dabei herauskommt, dass es drei Prozesse sind und nicht einer.

Zählen Sie zweitens die Plätze von heute und schätzen Sie sie für drei Jahre. Nehmen Sie drittens genau drei Produkte in die engere Wahl und bewerten Sie sie gegen Ihren aufgeschriebenen Prozess statt gegen ihre Funktionslisten, und markieren Sie jede Stelle, an der die Einführung Ihre Arbeitsweise ändern würde und ob diese Änderung Sie etwas kostet.

Beziffern Sie viertens die Falle in der Mitte ausdrücklich: Implementierungshonorare, Middleware und den Gehaltsanteil für die Verwaltung. Wenden Sie fünftens den Test zwei aus drei an. Berechnen Sie sechstens den Umschlagpunkt in Monaten für beide Platzzahlen. Beauftragen Sie siebtens, falls die Antwort Individualbau lautet, eine dünne Scheibe statt eines Systems.

Wer diesen Tab schließen und etwas kaufen sollte

Manche Leserinnen und Leser sollten hier aufhören, und das klar zu sagen ist nützlicher als ein ausgewogener Schluss.

Wenn Ihr Prozess ein verbreiteter ist, den Tausende Unternehmen ungefähr gleich betreiben, kaufen Sie das Produkt. Wenn Sie weniger als etwa zwanzig Nutzer haben und keine Prognose, die das ändert, kaufen Sie das Produkt oder bauen Sie es auf einer No-Code-Plattform, denn die Rechnung pro Platz wird sich in keinem planbaren Zeitraum zu Ihren Gunsten drehen. Wenn niemand die Software nach der Übergabe verantworten wird, kaufen Sie das Produkt, denn ein Individualsystem ohne Eigentümer verfällt schnell zur Belastung.

Wenn Sie Ihren Prozess nicht schriftlich beschreiben können, beauftragen Sie noch gar nichts. Schreiben Sie ihn zuerst auf. Viele gescheiterte Projekte wurden gegen eine Beschreibung beauftragt, die drei Personen im selben Raum unterschiedlich verstanden, und das repariert keine noch so gute Entwicklungsarbeit.

Wenn nur eine der drei Bedingungen gilt, kaufen Sie das Produkt und schauen Sie in einem Jahr erneut hin. Die Bedingungen ändern sich, meist weil die Kopfzahl gewachsen ist. Und wenn Sie in Wahrheit einen öffentlichen Auftritt statt eines internen Werkzeugs brauchen, ist das ein anderes Projekt, das unsere Arbeit zur Website-Entwicklung abdeckt.

Eine zweite Meinung einholen, bevor Sie sich festlegen

Der teure Fehler wird in beide Richtungen gemacht, bevor Code existiert, deshalb ist das Billigste, was Sie jetzt kaufen können, eine ehrliche Einschätzung.

Mecanik baut betriebliche Webanwendungen für britische Unternehmen, und ein großer Teil dieser Arbeit besteht darin, Leuten zu sagen, dass sie keine brauchen. Bringen Sie die Tabelle, die Platzzahl und die drei Produkte Ihrer engeren Wahl mit, und unser Team für individuelle Softwareentwicklung kalkuliert entweder eine dünne erste Scheibe oder sagt Ihnen, welches Produkt Sie stattdessen kaufen sollten. Ist die Anwendung kundenseitig statt intern, beginnen Sie mit der Website-Entwicklung und lesen Sie den Vergleich individuelle Webentwicklung gegen SaaS-Plattformen, der diese Seite der Frage behandelt.

Häufig gestellte Fragen

Was kostet eine individuelle Web-App im Vereinigten Königreich? Eine fokussierte interne Anwendung, die eine Tabelle und ein oder zwei Abonnements ersetzt, kostet im Bau in der Regel GBP 25.000 bis GBP 60.000, wovon eine dünne erste Scheibe GBP 8.000 bis GBP 15.000 ausmacht. Planen Sie jedes Jahr weitere 15 bis 20 Prozent des Baupreises für Hosting, Patches und Aktualisierungen von Abhängigkeiten ein, denn diese Kostenuntergrenze erreicht nie null.

Ist No-Code eine echte Alternative zur individuellen Web-App-Entwicklung? Ja. Für Datensätze, Formulare, Ansichten und einfache Regeln ist es häufig die richtige Antwort und deutlich schneller. Es stößt an eine Wand bei großen Zeilenzahlen, komplexen Berechtigungen, transaktionaler Integrität, Versionsverwaltung und echten Zustandsautomaten. Es wird zudem pro Platz bepreist: Retool führt seinen Business-Tarif mit GBP 40 pro Entwickler und GBP 12 pro internem Nutzer und Monat, was bei zehn Plätzen günstig und bei vierhundert erheblich ist.

Ab welcher Nutzerzahl wird Bauen billiger als Kaufen? Teilen Sie den Baupreis durch die monatliche Ersparnis, also die Gesamtkosten des Produktweges abzüglich Hosting plus ein Zwölftel des jährlichen Wartungsbudgets. Bei vierzig Nutzern amortisiert sich ein Bau für GBP 45.000 gegenüber monatlichen Produktkosten von GBP 2.150 in rund 34 Monaten. Bei vierhundert Nutzern amortisiert er sich in unter einem Jahr, denn Gebühren pro Platz wachsen mit der Kopfzahl, während die Betriebskosten eines Individualsystems kaum steigen.

Wer ist für den Datenschutz verantwortlich, wenn wir SaaS kaufen statt zu bauen? Sie selbst. Die ICO definiert den Verantwortlichen als die Stelle, die über Zwecke und Mittel der Verarbeitung entscheidet, und Ihr SaaS-Anbieter ist fast immer der Auftragsverarbeiter, der auf Ihre Weisung handelt. Sie bleiben dafür verantwortlich, die Einhaltung nachzuweisen, für die Einhaltung durch Ihre Auftragsverarbeiter und für einen Vertrag nach Artikel 28(3). Der Kauf von Software verlagert die Infrastrukturarbeit, nicht die rechtliche Verantwortung.

Gelten Regeln zur Barrierefreiheit auch für interne Werkzeuge, die niemand von außen sieht? Ja. Abschnitt 20 des Equality Act 2010 verlangt von Arbeitgebern angemessene Vorkehrungen, und ein Werkzeug, das sich nicht mit der Tastatur bedienen lässt, versetzt eine beschäftigte Person mit Behinderung in einen erheblichen Nachteil. Intranets und Extranets des öffentlichen Sektors sind zusätzlich von den Barrierefreiheitsvorschriften erfasst und müssen WCAG 2.2 AA erfüllen. Auf einer No-Code-Plattform setzt der Anbieter mit seinen Komponenten die Decke der Barrierefreiheit.