Softwareentwicklung für Unternehmen, deren Abläufe in kein Standardwerkzeug passen.

01

Für wen es gedacht ist und was es löst

Softwareprojekte beginnen meist mit einer Behelfslösung, die zu groß geworden ist. Eine Betriebsleiterin führt den echten Plan in einer Tabelle, weil das offizielle System ihn nicht abbilden kann. Ein Logistikunternehmen verfolgt Aufträge in E-Mail-Verläufen und Telefonaten. Ein Bildungsanbieter verwaltet Anmeldungen, Rechnungen und Zertifikate von Hand in drei verschiedenen Werkzeugen. Ein Gutachterbüro hängt von einer alten PHP-Anwendung ab, die niemand mehr anzufassen wagt. Eine Gründerin hat eine Produktidee und braucht eine erste Version, die echte Kunden nutzen können. Gemeinsam sind diesen Situationen doppelte Dateneingabe, keine einheitliche Datenquelle, zu grobe Berechtigungen und Berichte, die jeden Monat von Hand zusammengestellt werden. Wir ersetzen die Behelfslösung durch ein System, das den tatsächlichen Prozess abbildet, sodass Daten einmal erfasst werden und den Personen zur Verfügung stehen, die sie brauchen.

02

Was wir entwickeln

Wir übernehmen die Verantwortung für das gesamte Produkt, vom Datenmodell bis zu dem Bildschirm, den der Nutzer sieht. Die folgenden Beispiele stammen aus eigenen Produkten und aus Kundenprojekten.

• Interne Systeme und Verwaltungswerkzeuge
• Dashboards und betriebliches Reporting
• APIs und Integrationen zwischen bestehenden Systemen
• Mandantenfähige SaaS-Produkte mit Unternehmen, Standorten und Rollen
• Modernisierung von Altsystemen, zum Beispiel von PHP zu TypeScript
• Kundenportale, etwa Störungsmeldungen mit Dringlichkeitsstufen

03

So läuft ein Softwareprojekt ab

Das Risiko eines Softwareprojekts besteht darin, das Falsche gut zu bauen. Der Ablauf ist darauf ausgelegt, das früh und günstig herauszufinden.

1. 1Umfang: Wir erfassen Nutzer, Arbeitsabläufe, Daten und die Systeme, die angebunden werden müssen. Sie erhalten eine schriftliche Leistungsbeschreibung, in der die erste Version klar von späteren Ideen getrennt ist, und ein Angebot für diese Version.
2. 2Architektur und UX: Datenmodell, Rollen und Berechtigungen sowie die wichtigsten Bildschirme als klickbare Abläufe. Sie erhalten eine Beschreibung der Architektur und die Bildschirme zur Freigabe, bevor die Entwicklung beginnt.
3. 3Entwicklung: Frontend, Backend und Integrationen entstehen in kurzen Iterationen. Sie erhalten nach jeder Iteration eine lauffähige Version in einer Vorschauumgebung und können sie mit echten Fällen testen.
4. 4Inbetriebnahme: Datenmigration, Benutzerkonten, Abschlusstests und Bereitstellung in der Produktion. Sie erhalten das laufende System und eine Einweisung für die Personen, die es nutzen werden.
5. 5Betrieb und Weiterentwicklung: Korrekturen und neue Funktionen werden nach der tatsächlichen Nutzung priorisiert. Kunden melden Störungen über ein Ticketportal mit Dringlichkeitsstufe, sodass dringende Probleme zuerst bearbeitet werden.

04

Technologie und technische Entscheidungen

Wir schreiben TypeScript auf beiden Seiten der Anwendung: React im Browser und Node.js auf dem Server, sodass ein Typsystem das gesamte Produkt abdeckt und viele Fehler gefunden werden, bevor der Code läuft. Die Daten liegen in PostgreSQL. GastroApp, unser Produkt für den Restaurantbetrieb, nutzt eine REST-API, das ORM Prisma, tokenbasierte Authentifizierung und rollenbasierte Berechtigungen auf einem mandantenfähigen Modell, in dem ein Unternehmen mehrere Standorte hat und jeder Nutzer für ausgewählte Standorte freigeschaltet ist. Leichtere APIs, etwa die Bestell- und Kontoendpunkte dieser Website, laufen auf Cloudflare Workers mit serverlosem Postgres. Zahlungen, Transaktionsmails und Dateispeicher werden über die APIs der Anbieter angebunden und nicht über Plugins. Vor jeder Bereitstellung laufen automatisierte Tests und eine Typprüfung, und bereitgestellt wird aus dem Git-Repository. Wir wählen bewährte Komponenten statt Neuheiten, weil Unternehmenssoftware über Jahre gepflegt wird.

05

Wie eine gute erste Version aussieht

Die erste Version sollte klein genug sein, um fertig zu werden, und vollständig genug, um jeden Tag benutzt zu werden. In der Praxis heißt das: ein zentraler Arbeitsablauf von Anfang bis Ende, die daran beteiligten Rollen, die dafür nötigen Daten und die eine Integration, ohne die doppelte Arbeit entstünde. Alles andere kommt auf eine Liste für später. Das ist kein Weg, weniger zu liefern. Ein System, das täglich genutzt wird, liefert bessere Anforderungen als jeder Workshop, und die zweite Version wird aus dem geplant, was die Menschen in der ersten tatsächlich tun. Außerdem bleibt das Budget unter Ihrer Kontrolle, weil jeder Schritt einzeln angeboten und freigegeben wird.

06

Budget, Zeitplan und wann man nicht entwickeln sollte

Die Kosten folgen der Zahl der Nutzerrollen, dem Datenmodell, den Integrationen und dem Anteil des Prozesses, den die erste Version abdecken muss. Wir veröffentlichen keine Preisspannen, weil eine Zahl ohne Umfang in die Irre führen würde. Unser Leitfaden zu den Kosten der Softwareentwicklung in Dänemark beschreibt die Kostentreiber und wie man in Etappen budgetiert. Individualsoftware ist auch nicht immer die Antwort: Deckt ein Standardprodukt den Prozess gut ab, ist der Kauf günstiger und schneller, und das sagen wir Ihnen. Der Vergleich von Individualsoftware und SaaS erklärt, wo die Grenze meist verläuft.