Individuelle Webanwendungen und SaaS für den täglichen Einsatz.
SaaS-Produkte, Kundenportale, Buchungs- und Bestellsysteme - die browserbasierte Software, auf der ein Unternehmen läuft. Wir entwerfen das Datenmodell, bauen Backend, API und Oberfläche, bringen alles in Betrieb und bleiben für das, was erst mit echten Nutzern sichtbar wird.
- Ein Team für Datenbank, API und Oberfläche - keine Reibungsverluste bei der Übergabe.
- Jeder Kunde sieht nur seine eigenen Daten - durchgesetzt von der Datenbank, nicht von der Hoffnung.
- Live-Updates: Ändert eine Person etwas, sehen es alle anderen sofort.
- Durchgehend typisiert: TypeScript, versionierte Migrationen, eine dokumentierte API.
Wo die eigentliche Arbeit steckt
Eine Webanwendung ist keine Website mit Login. Sie verwaltet Daten, auf die es ankommt - Aufträge, Rechnungen, Berechtigungen, Protokolle - und viele Menschen ändern sie gleichzeitig. Der Großteil der Arbeit steckt dort, wo niemand Screenshots macht: im Datenmodell, in den Berechtigungsregeln und in der Frage, was passiert, wenn zwei Personen denselben Datensatz bearbeiten.
Bei der Web-App-Entwicklung setzen wir auf unspektakulär und langlebig: PostgreSQL als einzige Quelle der Wahrheit, eine typisierte API davor, eine schnelle, serverseitig gerenderte Oberfläche darüber und Hintergrundjobs für alles, worauf niemand warten sollte. Die API wird vor dem Code festgeschrieben - so entwickeln Ihre Mobile App, Ihre Partner und Ihre eigenen Integrationen gegen etwas Stabiles.
Als Agentur für Webentwicklung übernehmen wir SaaS-Entwicklung ab dem ersten Schema ebenso wie Anwendungen, die ein anderes Team begonnen hat und die wieder verlässlich werden müssen - aus Wien und Ugljevik, remote mit Teams in ganz Europa.
So funktioniert's
So fühlt sich eine gute Web-App an
Drei Dinge unterscheiden eine Web-App, der man vertraut, von einer, um die man herumarbeitet. Hier sind sie im Kundenportal eines Großhändlers.
-
Ein Kunde meldet sich an und sieht seine eigenen Bestellungen, Preise und Rechnungen - die von niemandem sonst. Ihr Team sieht alles. Die Regel steckt in der Datenbank, also kann kein Bildschirm sie vergessen.
-
Markiert das Lager eine Bestellung als versendet, aktualisiert sich der Bildschirm des Kunden in derselben Sekunde. Kein Neuladen, kein „Haben Sie meine Mail bekommen?“.
-
Zehn Nutzer oder zehntausend: Die Seiten antworten gleich schnell, weil langsame Arbeit im Hintergrund passiert und zusätzliche Server von selbst starten, wenn viel los ist.
In der Praxis
Beispielszenarien - die Art von Projekten, die wir umsetzen, keine Kundenreferenzen.
Aus einem internen Tool wird ein SaaS-Produkt
- Das Problem
- Ein Unternehmen hat ein Planungstool für sich selbst gebaut, und andere Betriebe der Branche wollen dafür bezahlen. Der Code geht überall von genau einem Kunden aus.
- Was wir bauen
- Mandantenfähigkeit, sauber umgesetzt: die Daten jedes Kunden in der Datenbank getrennt, Einstellungen pro Mandant, Self-Service-Registrierung mit Kartenzahlung und das ursprüngliche Unternehmen als Mandant Nummer eins migriert. Dazu eine Admin-Konsole, damit der Support nie direkt an die Datenbank muss.
- TypeScript
- PostgreSQL RLS
- Stripe
- SvelteKit
- Docker
Ein Kundenportal auf einem bestehenden ERP
- Das Problem
- Kunden rufen an, um nach Auftragsstatus, Rechnungen und Lieferterminen zu fragen. Die Antworten liegen im ERP, auf das sie niemals Zugriff bekommen dürfen.
- Was wir bauen
- Ein Webportal mit eigenem Login, das über eine schmale API aus dem ERP liest, selten Geändertes cacht und jedem Kunden nur die eigenen Dokumente zeigt. Nachbestellungen laufen über eine Queue, damit ein langsames ERP das Portal nie einfriert.
- SvelteKit
- Node.js
- REST API
- Redis
- BullMQ
Eine öffentliche API für Partner
- Das Problem
- Ein Logistikunternehmen möchte, dass Partner Sendungen direkt aus ihren eigenen Systemen buchen und Pakete verfolgen - heute läuft alles über E-Mail und ein internes Tool ohne API.
- Was wir bauen
- Eine versionierte REST API mit OpenAPI-Spezifikation, API-Keys pro Partner mit eigenem Rate Limit, signierten Webhooks für Statusänderungen und einer Sandbox. Client-Bibliotheken und Referenzdoku werden aus derselben Spezifikation generiert, sodass die Dokumentation nicht vom tatsächlichen Verhalten abweichen kann.
- Go
- OpenAPI 3.1
- PostgreSQL
- Redis
- Prometheus + Grafana
Was Sie bekommen
- Datenmodell und Datenbankschema mit versionierten, umkehrbaren Migrationen
- Eine dokumentierte API (OpenAPI oder GraphQL), gegen die Ihre anderen Apps und Partner entwickeln können
- Rollen und Berechtigungen, durchgesetzt in der Datenbank, plus ein Audit-Log, wer was geändert hat
- Live-Updates, wo Menschen zusammenarbeiten, Hintergrundjobs für alles Langsame
- Admin-Oberflächen für Ihr Team, damit der Support nie an die Datenbank muss
- Registrierung, Abrechnung und Abos für SaaS-Produkte
- CI/CD und Infrastructure as Code - Staging und Produktion identisch aufgebaut
Typischer Stack
- TypeScript
- SvelteKit
- React / Next.js
- Node.js
- NestJS
- Go
- PostgreSQL
- Redis
- WebSockets
- OpenAPI
- Docker
- Playwright
- Stripe
Häufige Fragen
Ihre Frage ist nicht dabei? Fragen Sie uns direkt - wir antworten innerhalb von zwei Werktagen.
Frage stellenWas kostet es, eine Webanwendung entwickeln zu lassen?
Vor allem hängt es an drei Dingen: wie viele Rollen und Abläufe die Anwendung hat, mit wie vielen externen Systemen sie spricht und wie viele Bestandsdaten migriert werden müssen. Schicken Sie uns eine kurze Beschreibung; wir antworten innerhalb von zwei Werktagen mit einem Link zu einem 30-minütigen Erstgespräch und senden danach einen schriftlichen Plan mit einer Schätzung für einen fest definierten Umfang, aufgeschlüsselt nach Funktionen.
Wie lange dauert die Entwicklung einer Web-App?
Die Dauer folgt dem Umfang. Wir liefern lieber früh eine nutzbare erste Version als einen großen Launch: Die Arbeit wird in Etappen geteilt, die jeweils mit etwas Klickbarem auf Staging enden, meist alle ein bis zwei Wochen. Die schriftliche Schätzung enthält den Zeitplan pro Etappe.
Welche Technologie setzen Sie ein - und warum nicht No-Code?
Standardmäßig TypeScript mit SvelteKit oder React, Node.js und PostgreSQL - verbreitet, schnell und personell gut nachzubesetzen. Bei einer bestehenden .NET-, PHP- oder Python-Codebasis passen wir uns an, wenn das sinnvoller ist. No-Code-Tools taugen für Prototypen; teuer werden sie, sobald eigene Berechtigungen, Integrationen oder viele Nutzer dazukommen.
Wie trennen Sie die Daten verschiedener Kunden in einem SaaS-Produkt?
Jede Zeile trägt den Kunden, zu dem sie gehört, und die Datenbank selbst filtert jede Abfrage nach dem angemeldeten Kunden (Row-Level Security) - auch die Abfrage, die jemand in Eile schreibt. Automatisierte Tests melden sich als ein Kunde an und versuchen, die Daten eines anderen zu lesen; gelingt das je, schlägt der Build fehl.
Können Sie auch die API für unsere Mobile App oder unsere Partner bauen?
Ja - die meisten Web-Apps, die wir bauen, haben eine dokumentierte API als Kern, und die Browser-Oberfläche ist nur ihr erster Client. Eine Mobile App, eine Partner-Anbindung oder Ihre eigenen Skripte nutzen dieselbe API mit eigenen Schlüsseln und Limits.
Ein Prozess, der seiner Excel-Tabelle entwachsen ist?
Erzählen Sie uns, was die Anwendung können soll und wer sie nutzt. Wir antworten innerhalb von zwei Werktagen mit einem Link zu einem 30-minütigen Erstgespräch und schicken danach einen schriftlichen Plan mit Aufwandsschätzung.
Projekt anfragen