Maßgeschneiderte
Software Entwicklung

Das Problem

Jedes Unternehmen erreicht den Punkt, an dem die eingesetzten Tools beginnen, gegen einen zu arbeiten.

Vielleicht ist es das Excel-Sheet, das 15 Personen gleichzeitig bearbeiten und dem niemand mehr vertraut. Vielleicht ist es das SaaS-Produkt, das 70 % Ihrer Anforderungen abdeckt und für den Rest schmerzhafte Workarounds erzwingt. Vielleicht sind es drei Systeme, die miteinander reden sollten, es aber nicht tun – und jemand verbringt seine Montagvormittage damit, Daten zwischen ihnen hin- und herzukopieren.

Standardsoftware ist großartig, bis Ihr Prozess nicht mehr zu den Annahmen passt, die der Anbieter getroffen hat. An diesem Punkt haben Sie zwei Optionen: Sie ändern Ihre Arbeitsweise, damit sie zum Tool passt, oder Sie bauen etwas, das zu Ihrer Arbeitsweise passt.

Wir sind für Option zwei da.

Was wir bauen

Interne Tools & Back-Office-Anwendungen

Die Dinge, die Ihr Team täglich nutzt, die aber kein SaaS-Anbieter jemals bauen wird – weil Ihr Workflow Ihrer ist. Auftragsmanagement-Dashboards, Freigabesysteme, Bestandsverwaltungen, Reporting-Tools, Onboarding-Portale für Kunden. Gebaut nach Ihrer Logik, nicht nach jemandes Vorstellung davon, wie Ihr Geschäft laufen sollte.

APIs & Backend-Services

Saubere, gut dokumentierte APIs, die Ihre Systeme verbinden, Ihre Daten den Anwendungen zugänglich machen, die sie brauchen, und das Klebeband aus manuellen Exporten und CSV-Uploads ersetzen. Wir bauen Services, die zuverlässig und schnell sind – und so konzipiert, dass Ihr Team sie warten kann, nicht nur wir.

Kundenseitige Anwendungen

Portale, Self-Service-Tools und Webanwendungen, mit denen Ihre Kunden oder Partner interagieren. Wir bauen sie schnell, zugänglich und geradlinig. Kein Feature-Ballast, kein "das brauchen wir vielleicht später" – nur das, was das Problem löst.

Daten-Dashboards & Reporting

Echtzeit-Sichtbarkeit auf die Zahlen, die für Ihr Geschäft wirklich zählen. Kein generisches BI-Tool mit 400 Konfigurationsoptionen, sondern ein fokussiertes Dashboard, das Ihrem Team genau das zeigt, was es sehen muss – automatisch aktualisiert, ohne dass jemand einen Report ausführen muss.

Wie wir arbeiten

Wir machen nicht das, wo wir für drei Monate verschwinden und mit etwas zurückkommen, das nicht zu dem passt, was Sie angefragt haben. Unser Vorgehen ist darauf ausgelegt, Sie nah an der Arbeit zu halten, ohne Ihre Zeit zu verschwenden.

Discovery (1–2 Wochen)

Wir kartieren, was Sie brauchen und warum. Wir sprechen mit den Menschen, die das Ergebnis nutzen werden – nicht nur mit denen, die das Budget freigegeben haben. Wir schauen uns Ihre bestehenden Systeme, Ihre Daten und Ihre Rahmenbedingungen an. Am Ende haben wir einen klaren Scope, einen realistischen Zeitplan und ein gemeinsames Verständnis davon, wie "fertig" aussieht.

Design & Prototyp (1–2 Wochen)

Bevor wir produktiven Code schreiben, bauen wir etwas, durch das Sie klicken können. Wireframes, interaktive Prototypen, Datenmodelle – was immer nötig ist, um sicherzustellen, dass wir das richtige Problem lösen. Das ist der günstigste Zeitpunkt, um die Richtung zu ändern, und wir nutzen ihn konsequent.

Build (4–12 Wochen, je nach Scope)

Wir arbeiten in zweiwöchigen Sprints. Am Ende jedes Sprints sehen Sie funktionierende Software – keinen Statusbericht, keine Demo, die nur auf dem Laptop eines Entwicklers läuft. Funktionierende, deployte Software, die Sie testen und zu der Sie Feedback geben können.

Wir übernehmen Frontend, Backend, Infrastruktur und Deployment. Ein Team, keine Übergaben zwischen Agenturen.

Launch & Übergabe

Wir deployen in Produktion, stellen sicher, dass alles unter realer Last funktioniert, und bleiben in den ersten Wochen dabei, um zu fangen, was wir übersehen haben. Dann übergeben wir – mit Dokumentation, mit Tests und mit einer Codebasis, die Ihr Team tatsächlich lesen kann.

Wenn Sie möchten, dass wir die Wartung weiter übernehmen, machen wir das auch. Aber der Code gehört immer Ihnen, und er ist immer so geschrieben, dass jemand, der nicht wir ist, ihn warten kann.

Unser Stack

Wir haben Meinungen zu Technologie, aber wir sind nicht religiös darüber. Hier ist, wozu wir typischerweise greifen und warum:

Frontend: Next.js und React. Das kennen die meisten Entwickler, es performt gut und das Ökosystem ist ausgereift. Wir wählen Frameworks nicht danach aus, was gerade auf Twitter trendet.

Backend: FastAPI (Python) oder Node.js, je nach Projekt. FastAPI, wenn wir enge Integration mit Datenpipelines oder KI-Komponenten brauchen. Node, wenn das Projekt geradliniger ist und das wartende Team JS-nativ arbeitet.

Datenbank: PostgreSQL. Fast immer. Sie deckt 95 % dessen ab, was Enterprise-Anwendungen brauchen, ist absolut stabil – und Ihr Team kennt sie bereits.

Infrastruktur: Kubernetes, deployt via GitOps. Ihre Anwendung läuft vom ersten Tag an in Containern, was Deployments, Skalierung und Umzüge zwischen Umgebungen geradlinig macht. Wir bauen keine Dinge, die nur auf einem Server laufen, den niemand anfassen darf.

CI/CD: GitHub Actions, automatisierte Tests bei jedem Pull Request, Deployments ausgelöst durch Merge auf main. Keine manuellen Deployments, kein "lass mich kurz auf Produktion SSHen".

Wenn Sie bestehende Technologie-Vorgaben haben – Sie sind ein Azure-Haus, Sie müssen eine bestimmte Datenbank nutzen, Ihr Team arbeitet in einer anderen Sprache – passen wir uns an. Der Stack ist ein Ausgangspunkt, keine Religion.

Wie gut aussieht (und was wir nicht tun)

Wir haben Meinungen dazu, wie Software gebaut werden sollte. Einige davon sind für uns nicht verhandelbar:

Tests existieren und laufen automatisch. Nicht 100 % Coverage um der Coverage willen, sondern aussagekräftige Tests, die echte Probleme fangen. Wenn ein Deployment etwas kaputt macht, wissen wir das, bevor die Nutzer es tun.

Code ist lesbar. Wir schreiben Code für die Person, die ihn in zwei Jahren wartet, nicht um jemanden mit Cleverness zu beeindrucken. Klare Benennung, konsistente Muster, keine Magie.

Dokumentation deckt das ab, was Menschen tatsächlich brauchen. Wie man deployt. Wie man ein neues Feature hinzufügt. Wo die Daten liegen. Was die Umgebungsvariablen tun. Keine 200-seitige Spezifikation, die veraltet ist, sobald sie fertig ist.

Die Anwendung ist ab Tag eins deploybar. "Deployment klären wir später" ist keine Option. CI/CD wird im ersten Sprint aufgesetzt, und jeder Sprint endet mit einem Deployment.

Was wir nicht tun:

Wir bauen nicht, ohne mit Endnutzern zu sprechen. Wenn wir nicht mit den Menschen sprechen können, die die Software nutzen werden, melden wir uns. Auf Basis von Anforderungen aus zweiter Hand zu bauen ist der Weg zu Software, die niemand nutzt.

Wir überspringen die Prototyp-Phase nicht, um Zeit zu sparen. Das spart nie Zeit. Es kostet Zeit. Jedes einzelne Mal.

Wir sagen nicht ja zu einem Scope, an den wir nicht glauben. Wenn Sie ein 6-Monats-Projekt beschreiben und wir denken, Sie können das Problem in 6 Wochen mit einem einfacheren Ansatz lösen, sagen wir das. Wenn das Projekt für uns keinen Sinn ergibt, sagen wir es Ihnen, bevor wir anfangen – nicht nachdem Sie das Budget ausgegeben haben.

Für wen das gedacht ist

Das passt gut, wenn:

• Sie einen Prozess oder Workflow haben, den kein bestehendes Tool sauber abbildet
• Sie geschäftskritische Daten in Excel-Sheets verwalten und das zum Risiko wird
• Sie eine alternde interne Anwendung ersetzen müssen, die nur durch Workarounds zusammenhält
• Sie eine Anwendung wollen, die sich in Ihre bestehenden Systeme integriert, statt ein weiteres Silo zu schaffen
• Ihr Team Ideen hat, aber nicht die Kapazität zum Bauen – und Sie lieber mit einem Team arbeiten, das Infrastruktur versteht, als mit einer reinen Dev-Bude

Es passt weniger, wenn:

• Sie eine Mobile-App brauchen – wir konzentrieren uns auf Webanwendungen und APIs. Für native Mobile-Arbeit können wir Partner empfehlen.
• Sie eine Landing Page oder Marketing-Site wollen – dafür gibt es schnellere und günstigere Wege
• Das Problem durch ein bestehendes SaaS-Tool gut gelöst ist und Sie es nur noch nicht gefunden haben – wir sagen es Ihnen, wenn das so ist