Zum Hauptinhalt springen
FromNine
Menü

Engineering

Unternehmenssoftware und SaaS-Produkte, gebaut für Jahre

Wir entwickeln SaaS-Produkte, Bürger- und Mitarbeiterportale sowie zentrale Fachsysteme: barrierefrei, standardmäßig sicher und so gebaut, dass Ihre eigenen Teams sie noch lange nach dem Start weiterentwickeln können.

Für Softwareanbieter, Mittelstand und öffentliche Stellen in Deutschland, deren Anwendungen über Jahre gepflegt und weiterentwickelt werden müssen.

Ihr Projekt besprechenUnser Vorgehen kennenlernen
Unternehmenssoftware & SaaS: LeistungsschichtenVier hintereinander gestaffelte Schichten. Von oben nach unten: die barrierefreie Oberfläche, mit der Menschen arbeiten, die Fachmodule mit den Geschäftsregeln, die Plattformdienste für Mandanten und Identitäten und darunter die abgesicherte Delivery-Pipeline.01Barrierefreie Oberflächen02Fachmodule und Regeln03Mandanten, Identität, Daten04Sichere Delivery-Pipeline
  1. 01Domain-driven Design für regelintensive Arbeit wie die Fallbearbeitung
  2. 02Barrierefreiheit nach EN 301 549 und WCAG 2.2 AA ab dem ersten Sprint
  3. 03Dokumentation und Entscheidungsprotokolle, die Ihre Teams übernehmen können

01 Herausforderungen

Was wir vor einer Neuentwicklung hören

  1. 01

    Jede Änderung dauert ein Quartal

    Die Anwendung läuft, aber niemand wagt sich an den Kern. Kleine Änderungen erfordern umfangreiche Regressionstests und ein Release-Fenster.

  2. 02

    Das Portal lässt seine Nutzenden im Stich

    Es funktioniert nicht mit einem Screenreader, nicht in den benötigten Sprachen und nicht auf dem Smartphone. Die Beschwerden kommen, bevor das Barrierefreiheits-Audit kommt.

  3. 03

    Die Änderung des einen Kunden legt den anderen lahm

    Das SaaS-Produkt ist durch kundenspezifische Anpassungen gewachsen. Jetzt wird jedes Release zur Verhandlung, und manche Mandanten hängen auf alten Versionen fest.

  4. 04

    Das Wissen ist mit dem Dienstleister gegangen

    Entscheidungen wurden nie festgehalten. Das Team, das die Software gebaut hat, ist weitergezogen, und der Code ist die einzige Dokumentation.

  5. 05

    Kunden und Aufsicht stellen Sicherheitsfragen

    Der Einkauf verlangt eine SBOM, einen Prozess für Schwachstellen und Nachweise für den Cyber Resilience Act. Niemand hat sie parat.

02 Leistungsumfang

Unsere Leistungen

  1. 01 SaaS-Produktentwicklung

    Produkte, die viele Kunden aus einer Codebasis bedienen: mit dem passenden Mandantenmodell, Konfiguration statt Individualanpassung und Releases, die jeden Mandanten erreichen.

    Was wir tun

    • Wahl des Mandantenmodells: geteilt, gepoolt oder isoliert je Mandant
    • Strategie für Konfiguration und Feature Flags
    • Anbindung von Nutzungsmessung und Abrechnung
    • Release Trains mit mandantenbezogenem Rollout

    Was Sie erhalten

    • Konzept für Mandantenfähigkeit und Isolation
    • Konfigurationsmodell mit Leitplanken
    • Release-Prozess mit Rollback je Mandant

  2. 02 Fachliches Design für komplexe Regeln

    Domain-driven Design, wo die Regeln das Produkt sind: Fallbearbeitung, Anspruchsprüfung, regulatorisch geprägte Berechnungen. Wir entscheiden ehrlich zwischen modularem Monolithen und Microservices und beginnen meist mit Ersterem.

    Was wir tun

    • Event Storming mit Fachleuten
    • Bounded Contexts und Modulgrenzen
    • Explizite, testbare Geschäftsregeln
    • Architecture Decision Records für die großen Entscheidungen

    Was Sie erhalten

    • Domänenmodell und Context Map
    • Modulare Codebasis mit durchgesetzten Grenzen
    • Ausführbare Spezifikationen für zentrale Regeln

  3. 03 Bürger- und Mitarbeiterportale

    Oberflächen auf Basis eines Designsystems, standardmäßig barrierefrei und vom ersten Release an auf die Sprachen ausgelegt, die Ihre Nutzenden tatsächlich sprechen.

    Was wir tun

    • Designsystem mit barrierefreien Komponenten
    • Content Design in verständlicher Sprache
    • Tests mit assistiven Technologien und echten Nutzenden
    • Lokalisierungsprozess für jede Sprache

    Was Sie erhalten

    • Portal auf einem wiederverwendbaren Designsystem
    • Bericht zur Konformität der Barrierefreiheit
    • Prozess für Inhalte und Übersetzungen

  4. 04 Qualitätssicherung und sichere Entwicklung

    Testautomatisierung auf den richtigen Ebenen, Contract Tests zwischen Services, Performancetests vor dem Start und ein sicherer Entwicklungsprozess auf Basis von OWASP ASVS, SBOMs und Kontrollen der Lieferkette.

    Was wir tun

    • Teststrategie und Testautomatisierung
    • Contract- und Performancetests
    • Bedrohungsmodellierung und ASVS-Verifikation
    • SBOM-Erzeugung und Regeln für Abhängigkeiten

    Was Sie erhalten

    • Automatisierte Testsuiten in der Pipeline
    • Bericht zur Sicherheitsverifikation
    • Prozess für den Umgang mit Schwachstellen, vorbereitet auf den Cyber Resilience Act

  5. 05 Schrittweise Modernisierung

    Ein Altsystem Funktion für Funktion hinter einer Routing-Fassade ablösen, während der Betrieb weiterläuft. Siehe auch Modernisierung von Altsystemen.

    Was wir tun

    • Fähigkeitslandkarte der bestehenden Anwendung
    • Strangler-Fig-Routing und API-Kapselung
    • Datenmigration mit Abgleichsberichten
    • Parallelbetrieb für kritische Berechnungen

    Was Sie erhalten

    • Modernisierungsfahrplan mit fachlichen Meilensteinen
    • Fassade und neue Module im Produktivbetrieb
    • Abgeglichene Daten bei jeder Umstellung

  6. 06 Wartbarkeit und Übergabe

    Software, die Ihre Teams selbst verantworten können: lesbarer Code, Entscheidungsprotokolle, Runbooks und ein Übergabeplan, der zu Beginn vereinbart und nicht erst am Ende entdeckt wird.

    Was wir tun

    • Pairing mit Ihren Entwicklerinnen und Entwicklern während der Umsetzung
    • Architecture Decision Records direkt beim Code
    • Betriebs-Runbooks und Leitfäden für die Rufbereitschaft
    • Meilensteine für den Wissenstransfer

    Was Sie erhalten

    • Übergabeplan mit Abnahmekriterien
    • Dokumentation in Ihren Repositories
    • Geschultes internes Team

03 Architektur

Eine beispielhafte Referenzarchitektur

Ein typisches Muster für ein Fachsystem, das ein älteres ablöst: ein barrierefreies Frontend, eine Routing-Fassade, die jede Funktion an das alte oder das neue System leitet, eine API-Schicht mit klaren Verträgen und ein modularer, fachlich geschnittener Kern.

Mandantenfähigkeit und Konfiguration sind eigenständige Plattformdienste und keine Bedingungen, die über den Code verstreut sind. Darunter durchläuft jeder Build Tests und Sicherheitsprüfungen und erzeugt eine SBOM.

Ebenen der Darstellung

Menschen
Bürgerinnen und Bürger, Kunden und Beschäftigte, auf jedem Gerät und mit assistiven Technologien.
Modernisierung
Die Routing-Fassade, die bestehende Anwendung und die Datenmigration mit Abgleich.
Plattform
API-Schicht, Identität, modularer Kern, Mandanten und Konfiguration, operative Daten.
Sichere Auslieferung
Contract- und Performancetests, ASVS-Prüfungen und eine SBOM in jedem Build.
Beispiel zur Veranschaulichung

  1. Menschen

    • Bürger, Kunden, Beschäftigte
    • Barrierefreies Frontend

  2. Schrittweise Modernisierung

    • Routing-Fassade
    • Bestehende Anwendung
    • Migration mit Abgleich

  3. Plattform

    • API-Schicht und Verträge
    • Identität und Rollen
    • Modularer Kern: Eingang, Fälle, Abrechnung
    • Mandanten, Konfiguration, Feature Flags
    • Operative Datenspeicher

  4. Sichere Auslieferung

    • Contract- und Performancetests, ASVS-Prüfungen, SBOM in jedem Build
Modularer Kern hinter einer Routing-Fassade

Beispielhafte Architektur, kein Kundensystem.

Diagramm als Text lesen

Der Hauptpfad führt von den Menschen zu einem barrierefreien Frontend, über eine Routing-Fassade und eine API-Schicht zu einem modularen Kern, der in Bounded Contexts gegliedert ist.

Die Fassade leitet einige Funktionen auch an die bestehende Anwendung weiter, die Schritt für Schritt abgelöst wird. Deren Daten wandern über eine Migration mit Abgleich in die operativen Datenspeicher.

Die Identitätsverwaltung bedient die API-Schicht. Dienste für Mandanten und Konfiguration liegen unter dem Kern. Ein Band für sichere Auslieferung darunter umfasst Contract Tests, Performancetests, Sicherheitsverifikation und SBOMs.

04 Abwägungen und Grenzen

Technische Abwägungen und Grenzen

  • Erst der modulare Monolith

    Wie wir vorgehen

    Wir beginnen mit klaren Modulen in einer deploybaren Einheit und lösen Services nur dort heraus, wo Skalierung, Release-Takt oder Teamverantwortung es erfordern.

    Grenzen und Abhängigkeiten

    Microservices lösen organisatorische Probleme ebenso wie technische. Ohne Teams, die sie verantworten, bringen sie vor allem zusätzliche Kosten und Fehlerquellen.

  • Barrierefreiheit ist Ingenieursarbeit

    Wie wir vorgehen

    Barrierefreie Komponenten, automatisierte Prüfungen in der Pipeline und manuelle Tests mit assistiven Technologien vor jedem größeren Release.

    Grenzen und Abhängigkeiten

    Automatisierte Werkzeuge finden nur einen Teil der Probleme. Volle Konformität erfordert manuelle Audits und idealerweise Tests mit Menschen mit Behinderungen.

    Inhalte und Dokumente, die Redaktionen nach dem Start ergänzen, müssen denselben Standard erfüllen. Wir schulen die Redaktionen, haben aber keinen Einfluss darauf, was sie veröffentlichen.

  • Modernisierung dauert so lange wie die Daten

    Wie wir vorgehen

    Die Datenmigration wird je Funktion geplant, geprobt und abgeglichen, mit fachlicher Freigabe bei jeder Umstellung.

    Grenzen und Abhängigkeiten

    Die Qualität der Altdaten bestimmt oft das Tempo. Ihre Bereinigung ist ebenso eine fachliche wie eine technische Aufgabe.

  • Regulierung für Softwareprodukte

    Wie wir vorgehen

    SBOMs, Schwachstellenmanagement und sichere Voreinstellungen gehören zu unserer Standard-Pipeline und bereiten Produkte auf den Cyber Resilience Act vor.

    Grenzen und Abhängigkeiten

    Ob und wie die Verordnung für Ihr Produkt gilt, ist eine Rechtsfrage. Wir liefern die technischen Nachweise, Ihre Rechtsberatung trifft die Bewertung.

05 Zusammenarbeit

So arbeiten wir

Kurze Zyklen, früh echte Nutzende und eine Übergabe, die ab der ersten Woche geplant ist.

  1. 01

    Die Domäne erfassen

    Event Storming mit den Menschen, die die Regeln kennen, und eine Fähigkeitslandkarte des heutigen Bestands.

    ErgebnisContext Map und erste Entscheidungsprotokolle

  2. 02

    Einen schmalen Schnitt liefern

    Eine Funktion durchgängig, über die Fassade, im Produktivbetrieb mit echten Nutzenden.

    ErgebnisFunktionsfähiger Schnitt im Produktivbetrieb

  3. 03

    Funktion für Funktion wachsen

    Jedes Release verlagert eine Funktion samt Daten und Nutzenden, mit vorbereitetem Abgleich und Rollback.

    ErgebnisRelease-Plan nach Funktionen

  4. 04

    Übergeben

    Ihre Entwicklerinnen und Entwickler arbeiten im Pairing mit unseren, übernehmen die Rufbereitschaft und verantworten die Roadmap, sobald die Übergabekriterien erfüllt sind.

    ErgebnisAbgenommene Übergabe

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Kontrolle heißt bei Unternehmenssoftware: wissen, wer was geändert hat, wer es freigegeben hat und wie es sich rückgängig machen lässt.

  • Product Owner entscheiden über den Umfang

    Ihr Product Owner setzt die Prioritäten und nimmt jedes Inkrement ab. Wir beraten, entschieden wird bei Ihnen.

  • Konfiguration hat eine Verantwortung

    Mandanteneinstellungen und Feature Flags werden über einen protokollierten Prozess geändert, durch Rollen, die Sie festlegen.

  • Umstellungen werden freigegeben

    Jeder Wechsel vom alten zum neuen System wird vom Fachbereich freigegeben, mit einem geprobten Rollback.

  • Entscheidungen werden festgehalten

    Architecture Decision Records zeigen, was gewählt wurde, von wem und warum, damit künftige Teams sie in Kenntnis der Gründe überprüfen können.

07 Technologien

Technologien, mit denen wir arbeiten

Backend
  • Java und Kotlin
  • .NET
  • TypeScript und Node.js
  • Python
Frontend
  • React und Next.js
  • Angular
  • Designsysteme mit barrierefreien Komponenten
  • Native und plattformübergreifende Mobile-Apps
Daten
  • PostgreSQL
  • SQL Server und Oracle (Bestandssysteme)
  • Event Streaming
  • Suchmaschinen
Qualität und Sicherheit
  • Playwright und Contract Testing
  • Last- und Performancetests
  • SAST, DAST und Abhängigkeitsscans
  • SBOM in CycloneDX oder SPDX

Die Nennung einer Technologie beschreibt unsere Engineering-Erfahrung. Sie bedeutet keine Partnerschaft mit dem Hersteller und keine Empfehlung durch ihn.

08 Beispiel

Beispielhaftes Szenario

Beispiel zur Veranschaulichung

Ein neues Kundenportal für ein Stadtwerk

01Ausgangslage
Ein Stadtwerk betreibt sein Kundenportal auf einer veralteten Plattform. Zählerstände, Abschläge und Umzüge laufen über Formulare, die Prüfungen zur Barrierefreiheit nicht bestehen, und jede Tarifänderung erfordert einen Auftrag beim Hersteller.
02Was wir bauen würden
Ein neues Portal auf einem barrierefreien Designsystem, angebunden an Abrechnung und CRM über dokumentierte Schnittstellen, mit Tarifen und Inhalten, die das Stadtwerk selbst pflegt.
03Wo Menschen entscheiden
Der Fachbereich gibt Inhalte und Tarifkonfiguration frei; jede Version durchläuft vor dem Livegang eine Prüfung auf Barrierefreiheit.
04Was wir messen würden
Barrierefreiheitsmängel je Release, Anteil online erledigter Anliegen, Durchlaufzeit einer Tarifänderung.

09 Branchenblick

In Ihrer Branche

  • Öffentlicher Sektor & Verwaltung

    Fallbearbeitung und Bürgerportale, die die gesetzlichen Anforderungen an Barrierefreiheit erfüllen, in den benötigten Amtssprachen funktionieren und an nationale Datenaustauschplattformen angebunden sind.

  • Finanzdienstleistungen

    Kundenportale und Backoffice-Anwendungen mit belastbaren Audit-Trails und Release-Prozessen, die den Anforderungen des Change Managements genügen.

  • Fertigung & Industrie

    Konfiguratoren, Serviceportale und SaaS-Produkte für Maschinen- und Anlagenbauer, angebunden an ERP und Außendienst.

Deutschland

Software für den deutschen Markt

Seit Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für viele digitale Produkte und Dienstleistungen von Unternehmen; öffentliche Stellen sind über die BITV 2.0 schon länger verpflichtet. Der Cyber Resilience Act bringt ab September 2026 schrittweise Pflichten für Software mit digitalen Elementen, von der Meldung ausgenutzter Schwachstellen bis zur Dokumentation über den gesamten Lebenszyklus.

Wir bauen Barrierefreiheitsprüfungen, Software-Stücklisten (SBOM) und Sicherheitsnachweise in die Build-Pipeline ein. So entstehen die Unterlagen für Kundenaudits, für die Erklärung zur Barrierefreiheit und für die Fragen einer Vergabestelle mit jedem Release, nicht erst am Projektende.

Fragen zu Unternehmenssoftware und SaaS

Sollen wir individuell entwickeln oder eine Plattform konfigurieren?

Konfigurieren Sie eine Plattform, wo Ihr Prozess nah am Standard liegt, und entwickeln Sie individuell, wo der Prozess Sie vom Wettbewerb unterscheidet oder keine Plattform zu den Regeln passt. Wir arbeiten mit Salesforce, SAP und Odoo ebenso wie mit Individualsoftware und haben daher keinen Grund, eine Antwort zu bevorzugen. Unsere Architektur & Beratung macht diese Entscheidung transparent.

Können Sie garantieren, dass unser Portal barrierefrei ist?

Wir entwickeln nach EN 301 549 und WCAG 2.2 AA, testen automatisiert und manuell und liefern einen Konformitätsbericht mit allen bekannten Mängeln. Null Mängel versprechen wir nicht. Unser Ansatz ist, Mängel systematisch zu suchen, zu dokumentieren und zu beheben, soweit sie in unserem Verantwortungsbereich liegen.

Ist eine Modernisierung ohne Big-Bang-Migration möglich?

Ja, und wir empfehlen sie. Mit einer Routing-Fassade verlagern wir eine Funktion nach der anderen, während die bestehende Anwendung weiterläuft, und gleichen die Daten bei jedem Schritt ab.

Kann unser eigenes Team die Software übernehmen?

Das ist bei uns der Regelfall. Die Übergabekriterien werden zu Beginn vereinbart, Ihre Entwicklerinnen und Entwickler arbeiten während der Umsetzung im Pairing mit unseren, und Entscheidungsprotokolle sowie Runbooks liegen in Ihren Repositories.

Was bedeutet der Cyber Resilience Act für unser Produkt?

Wenn Sie Software mit digitalen Elementen auf dem EU-Markt bereitstellen, können sich daraus Pflichten zu sicherem Design, Schwachstellenmanagement und Dokumentation ergeben. Wir erarbeiten die technischen Nachweise: SBOMs, einen Schwachstellenprozess und sichere Voreinstellungen. Die rechtliche Bewertung bleibt bei Ihrer Rechtsberatung.

Sagen Sie uns, was weiterlaufen muss, während es sich ändert

Wir schlagen vor, welche Funktion zuerst umzieht und was Ihr Team am Ende selbst verantwortet: Quellcode, Dokumentation und Betriebshandbuch.

Ihr Projekt besprechenUnser Vorgehen kennenlernen