Die meiste Software, die wir bauen, würde es ohne uns auch geben. Wahrscheinlich sogar schneller. Aber sie würde anders sein — und in den meisten Fällen schlechter. Diese Behauptung klingt arrogant, also lass uns gleich klären, was wir damit meinen.

Software ist nicht das Produkt einer Anforderung. Software ist eine Übersetzung. Jemand hat ein Problem, das er nicht in Code formulieren kann. Jemand anderes schreibt Code, der dieses Problem lösen soll. Zwischen diesen beiden Personen passieren tausend kleine Entscheidungen, von denen die meisten unsichtbar bleiben — bis sie es plötzlich nicht mehr sind.

Was schiefläuft, wenn niemand entscheidet

Die häufigste Form von gescheiterter Software ist nicht die, die nie fertig wurde. Es ist die, die fertig wurde, aber nie wirklich passte. Sie funktioniert, sie wird benutzt, sie kostet jeden Monat Geld — und niemand traut sich zu fragen, ob sie eigentlich das tut, was sie tun sollte.

Das passiert nicht aus Bösartigkeit. Das passiert, weil jemand vor zwei Jahren in einem Meeting gesagt hat: „Wir brauchen ein Tool, mit dem wir X können." Und jemand anderes hat geantwortet: „Klar, kein Problem." Und dann wurde drei Monate lang entwickelt, ohne dass jemals jemand gefragt hat: Warum eigentlich X? Was passiert vorher? Was passiert danach? Wer benutzt das wirklich, und in welcher Situation?

Die spannendste Codezeile bringt nichts, wenn das Konzept dahinter nicht trägt.

Das ist der Grund, warum unser erstes Gespräch fast nie über Code geht. Wir wollen verstehen, was hinter der Anforderung steckt. Welches Problem wirklich gelöst werden soll. Wer betroffen ist. Was die Konsequenzen sind, wenn wir es richtig machen — und was die Konsequenzen sind, wenn wir es schlecht machen.

Der Code, den niemand mehr versteht

Eine andere Form von schlechter Software: die, die niemand mehr verändern kann. Sie wurde irgendwann von jemandem geschrieben, der inzwischen das Unternehmen verlassen hat. Sie ist nicht dokumentiert. Sie ist auch nicht besonders schlecht — sie ist nur unzugänglich.

Wir behandeln Code wie einen Text, den ein Fremder verstehen können muss. Nicht in fünf Jahren, wenn er archäologisch ausgegraben werden muss, sondern in der nächsten Woche, wenn jemand eine kleine Änderung machen will. Das bedeutet: klare Namen, kleine Funktionen, dokumentierte Entscheidungen, getestete Annahmen.

Das ist nicht romantisch. Das ist nicht „Craftsmanship" im LinkedIn-Sinn. Das ist einfach die Voraussetzung dafür, dass Software überlebt. Code, der nicht verändert werden kann, ist toter Code. Und toter Code ist ein laufender Kostenfaktor.

Was wir nicht sind

Wir sind keine Full-Service-Agentur. Wir machen kein Marketing, kein Design für andere Domänen, keine SEO, kein klassisches Beratungsgeschäft mit PowerPoint-Decks. Wir sind ein Software-Studio mit drei klaren Schwerpunkten.

Wir sagen auch nein. Häufiger, als man denkt. Wenn ein Projekt nicht zu uns passt, weil es zu klein, zu groß, fachlich zu weit weg oder schlicht falsch konzipiert ist — dann sagen wir das. Vor dem Vertrag, nicht danach. Das ist nicht immer angenehm, aber es spart auf beiden Seiten Monate.

Wofür wir uns einsetzen

Wir bauen Software für Menschen, die sich darauf verlassen müssen. Logistik-Teams, die jeden Morgen wissen müssen, was zu tun ist. Buchhalter, die saubere Daten brauchen. Disponenten, die in fünf Sekunden einen Überblick haben sollen, weil sie keine zehn haben.

Für diese Menschen ist Software kein Erlebnis und kein „Feature". Sie ist ein Werkzeug. Und ein gutes Werkzeug fällt einem nicht auf — bis es weg ist. Genau das ist die Latte, an der wir uns messen.

Ein gutes Werkzeug fällt einem nicht auf — bis es weg ist.

Wenn nach drei Monaten Nutzung niemand mehr darüber redet, dass „die neue Software" eingeführt wurde, weil sie einfach Teil des Arbeitsalltags geworden ist, ohne zu nerven — dann haben wir unseren Job gemacht.

Was du davon hast

Wenn du mit uns arbeitest, bekommst du:

  • Jemanden, der lieber eine Stunde zuhört, bevor er anfängt zu schreiben.
  • Code, der ohne uns weiterleben kann — denn das ist das Mindeste, was wir dir schulden.
  • Klare Sprache statt Architektur-Folklore.
  • Ein direktes Gegenüber, das auch in Monat sechs noch antwortet.
  • Die Bereitschaft, Nein zu sagen, wenn etwas nicht passt.

Wenn das nach deiner Art zu arbeiten klingt — lass uns reden. Wenn nicht: kein Problem. Es gibt genug gute Entwickler da draußen, die anders ticken, und es ist gut, dass es uns alle gibt.