Prozess- und Rollenmodell
Wer darf was sehen und ändern, und was passiert im Ausnahmefall. Aufgenommen mit den Leuten, die das Tool täglich benutzen.
Individualsoftware
Web-Apps bei uns sind interne oder kundennahe Werkzeuge: Rollen, Zustände, Integrationen, Logs. Die Oberfläche zeigt, was das System tut — inklusive Pause, Override und Übergabe an Menschen.
Teams, die Excel, E-Mail und Insellösungen ersetzen wollen, ohne eine undurchsichtige Plattform einzukaufen.
Vier bis fünf Artefakte, keine Pakete. Jedes ist ein Gegenstand, den ihr am Ende in der Hand habt — kein Zustand, den wir behaupten.
Wer darf was sehen und ändern, und was passiert im Ausnahmefall. Aufgenommen mit den Leuten, die das Tool täglich benutzen.
Die zwei, drei Abläufe, für die das Tool existiert — bedienbar, bevor Code entsteht.
Anmeldung, Rechte und eine nachvollziehbare Spur, wer wann was geändert hat. Von Anfang an, nicht als Nachrüstung.
Anbindung an das, was schon läuft — mit definiertem Verhalten, wenn die Gegenseite ausfällt.
Runbook, Zugänge und ein Termin, an dem euer Team einmal alles selbst macht, während wir zuschauen.
Wer klickt was, wo bricht es, was darf nie automatisiert werden.
Entwürfe, Freigaben, Fehler, Wiedervorlage.
Enger Scope, echte Daten, frühe Tests mit dem Team.
Monitoring, Rechte, Dokumentation.
MVP oft 6–16 Wochen. Danach Releases, keine Big-Bang-Versprechen.
Flächen aus demselben Studio. Lab-Konzepte sind als solche gekennzeichnet — wir zeigen keine fremde Arbeit als unsere.
28 Orte in Österreich haben eine eigene Seite für Softwareentwicklung — mit lokalem Kontext, Quellen und einem eigenen Arbeitsblatt. Ist der Stadtname austauschbar, wird die URL nicht gebaut.
Nein. Wir bauen das Werkzeug, das euren Prozess abbildet. Standardsoftware empfehlen wir, wenn sie passt.
Nur wenn sie einen Schritt übernimmt, den ihr prüfen könnt. Kein KI-Aufkleber auf einem Formular.
Web-App anfragen. Wir versprechen keine Rankings und keine erfundenen Case-Zahlen.
Projekt starten