Software bauen kann heute fast jeder. Wir liefern sie produktionsstabil ab.

Was wir anbieten, machen wir selbst. Es gibt keine Schicht zwischen Ihnen und den Personen, die bauen — und niemanden, der verkauft und dann weiterreicht.

Entwickeln

Wir bauen Software mit Agenten und tragen die Verantwortung dafür wie für handgeschriebenen Code. Oft ist es keine grüne Wiese, sondern ein Inkrement in ein System, das läuft und weiterlaufen muss. Und wenn ein Agent auf den letzten zehn Prozent hängen bleibt, machen wir die Stelle fertig, statt sie zurückzugeben.

Womit wir arbeiten: TypeScript, Python, Java, C#. Web, Mobile und die Backends dahinter — APIs, Datenbanken, Edge-Functions. Azure, GitLab, GitHub Actions, Cloudflare. Claude Code im Alltag, seit 2025 in Kundenprojekten.
Wann Sie uns holen: Wenn etwas gebaut werden muss und Sie danach nicht die Hälfte der Zeit damit verbringen wollen, herauszufinden, ob es wirklich läuft — oder es in zahllosen Bug-Tickets nachzulesen.
Was dabei entsteht: Lauffähiger Code in Ihrem Repository, mit Tests, die vor dem Bauen feststanden — und ohne ein Werkzeug, das Sie danach lizenzieren müssen.

Automatisieren

Abläufe automatisieren, Systeme verbinden, Datenflüsse bauen — und Agenten, die einen Teil des Prozesses selbst übernehmen. Nicht als Demo, sondern als etwas, das morgens läuft, wenn niemand zuschaut.

Womit wir arbeiten: Prozess- und Systemautomatisierung, CI/CD- und Release-Pipelines, Betrieb und Überwachung — dazu Schnittstellen zwischen Systemen, die nie dafür gedacht waren.
Wann Sie uns holen: Wenn vor jedem Release jemand dieselben Klickstrecken durchgeht — oder zwei Leute Daten von einem System ins andere tippen und niemand merkt, wenn dabei etwas verloren geht.
Was dabei entsteht: Ein Ablauf, der ohne Zuruf läuft, und eine Meldung, wenn er es nicht tut. Was heute Arbeitszeit kostet, kostet danach keine mehr — und ändern kann ihn Ihr Team selbst, die Dokumentation liegt dabei.

Testmanagement

Die Arbeit, aus der wir kommen. Testprozesse aufsetzen, ein Testteam aufbauen, Freigaben belastbar machen — oft in Häusern, in denen vorher niemand getestet hat, und in Freigabeprozessen, die eine Aufsicht vorgibt.

Womit wir arbeiten: Jira und Xray, Azure Test Plans, TestRail, HP ALM. Testkonzepte, Testphasen und Abnahmeprozesse. Schulung von Fachbereichen, die vorher nie getestet haben.
Wann Sie uns holen: Wenn ein Release zur Freigabe ansteht und die ehrliche Antwort auf „Ist das ausreichend getestet?“ ein Schulterzucken ist.
Was dabei entsteht: Ein Testkonzept, das durch Ihre Freigabe kommt, ein Testteam, das ohne uns weiterarbeitet, und ein Werkzeugstand, der zu Ihrer Organisation passt statt zu unserer.

Abnehmen

Der Teil, den die meisten auslassen: Qualitätssicherung für KI-Features. Ein Agent, der Code schreibt, schreibt auch die Tests dazu — und erbt dabei dieselben blinden Flecken. Grüne Tests sind deshalb kein Beweis. Wir bauen die Gegenprobe, die ein Agent nicht selbst schreiben kann.

Womit wir arbeiten: Evaluation und Messgrößen für KI-Features, Guardrails, Regression-Gates in der CI, Testautomatisierung auf allen Ebenen, Abnahmekriterien, die im Wortlaut stehen, bevor gebaut wird.
Wann Sie uns holen: Wenn die Demo überzeugt hat und niemand weiß, was bei zehntausend echten Fällen passiert.
Was dabei entsteht: Ein gemeinsames Verständnis, was gut genug ist und wann etwas raus darf — und die Automatisierung, die genau das bei jedem Lauf selbst prüft, statt es zu kommentieren.

Von der Anforderung zur QA-Pipeline

Fast jede Anforderung beginnt als Satz, der sich nicht prüfen lässt. Er ist richtig gemeint — nur kann niemand sagen, wann er erfüllt ist. Genau dort fangen wir an: aus dem Satz wird ein Schritt in Ihrer CI/CD-Pipeline, der bei jedem Lauf mitprüft, sich selbst repariert, wo er kann, und mit jedem neuen Fall mitwächst.

„Die Bestellung soll im Shop zuverlässig durchlaufen."

Was daran nicht prüfbar ist

„Zuverlässig" hat keine Schwelle, und „die Bestellung" gibt es nicht: Gastbestellung, Gutschein, Teilstorno, drei Zahlarten, Lieferung ins Ausland. Drei Leute im Raum meinen drei verschiedene Wege — und es fällt niemandem auf, weil alle nicken.

Woran es dann automatisch gemessen wird

Die Bestellwege, die bei Ihnen wirklich vorkommen, jeder mit dem erwarteten Endstand in Shop, ERP und Lager. Läuft einer davon nicht durch, steht der Deploy — und der Fall liegt im selben Moment im Board: welcher Weg, welcher Schritt, welche Daten, mit Protokoll und Aufnahme, zugewiesen an das Team, dem der Schritt gehört. Niemand muss ihn erst nachstellen, und niemand merkt es am Montag beim Kunden.
„Der Agent soll nur tun, was er darf."

Was daran nicht prüfbar ist

Ein Verbot ohne Liste ist eine Absicht. Dazu kommt: der Agent, der den Code schreibt, schreibt auch den Test dazu — und erbt dabei die Annahme, aus der der Fehler entstanden ist. Grün heißt dann nur, dass zweimal dasselbe gedacht wurde.

Woran es dann automatisch gemessen wird

Die verbotenen Fälle schreibt ein Mensch, nicht der Agent. Sie laufen gegen die echte Berechtigungsschicht, nicht gegen eine Attrappe. Rutscht einer durch, kommt er als Fall dazu — vor dem Fix, nicht danach.
„Nach dem Umbau muss alles laufen wie vorher."

Was daran nicht prüfbar ist

„Wie vorher" steht nirgends geschrieben. Ohne Aufnahme des Ausgangszustands ist die Abnahme eine Erinnerungsleistung — und die verliert gegen einen Releasetermin.

Woran es dann automatisch gemessen wird

Vor dem ersten Eingriff nehmen wir den alten Stand auf: Antworten, Laufzeiten, Seitenbilder. Danach vergleicht die Strecke gegen diese Aufnahme statt gegen eine Meinung. Wer sie ändert, sieht im Diff, was er ändert.

Die Kriterien unserer Kunden dürfen wir nicht zeigen. Die Form ist dieselbe: der Satz kommt von Ihnen, die Prüfung entsteht vor dem Bauen — nicht danach, wo sie um das herum geschrieben wird, was fertig geworden ist.

Wie wir arbeiten

Erst das Ziel, dann der Code.

Woran man das fertige Ergebnis erkennt, steht bei uns fest, bevor gebaut wird. Das erspart die Diskussion am Ende, in der niemand mehr weiß, was ursprünglich gemeint war.

Remote, mit fester Überlappung.

Verteilt zu arbeiten ist bei uns Alltag und wir mögen es so: feste Zeiten, in denen wir ansprechbar sind, kurze Wege — und jeder Stand dort, wo Ihr Team ohnehin hinschaut.

Einer, beide — oder ein Team.

Für größere Vorhaben holen wir feste freie Partner dazu, mit denen wir Projekte schon gemeinsam abgeschlossen haben. Sie sprechen dabei immer mit der Person, die auch baut.

Wir arbeiten uns schnell in fremde Welten ein.

Vom Start-up bis zur Staatsbank unter BAIT, MaRisk und DORA und zum Verteidigungssektor — wir haben in beiden Enden geliefert. Was ein Haus verlangt, lesen wir aus seinen Prozessen statt aus Annahmen.

Wie das unter Bankenaufsicht aussah

Verstärkung — oder jemand, der es ganz übernimmt?

Einer von uns in Ihrem Team — oder wir beide als Einheit, die ein Vorhaben von der Umsetzung bis zur Abnahme übernimmt.

Kontakt aufnehmen