Die Menschen, die Ihr System bauen — und die es in fünf Jahren noch kennen.

Warum wir klein bleiben — und warum Sie davon profitieren

In der Softwarebranche gibt es ein Muster, das fast jeder Auftraggeber schon einmal erlebt hat: Im Angebotstermin sitzt ein erfahrener Architekt, der die richtigen Fragen stellt. Nach der Unterschrift übernimmt ein Team, das er nie wieder sieht. Die Erfahrung, für die Sie bezahlt haben, war im Vertrieb. Im Projekt sitzt sie nicht.

Bei uns gibt es diesen Bruch nicht, weil es die Struktur nicht gibt, die ihn erzeugt. Wer mit Ihnen spricht, schreibt später den Code oder verantwortet die Architektur. Das ist die eine Zusage, die sich mit einem kleinen Team einhalten lässt und mit einem großen kaum.

Der zweite Punkt ist Zeit. Ein System, das wir bauen, betreuen wir danach über Jahre. Diese Konstellation funktioniert nur, wenn die Menschen bleiben. Unsere beiden Gründer sind seit 2012 hier — dieselben Personen, die LingoHub gebaut haben und es bis heute betreiben. Wir wissen deshalb aus eigener Erfahrung, was es bedeutet, eine Architekturentscheidung aus dem Jahr sechs im Jahr elf noch erklären zu müssen.

Der dritte Punkt ist unbequemer. Ein kleines Team kann nicht alles. Wir nehmen keine Aufträge an, die parallel drei Entwicklungsstränge über ein Jahr erfordern, und wir sagen ab, wenn ein Vorhaben zu einem Zeitpunkt starten muss, an dem wir keine Kapazität haben. Das kostet uns regelmäßig Aufträge. Es ist trotzdem die bessere Zusage als ein Team, das erst nach der Unterschrift zusammengestellt wird.

Was das für die tägliche Zusammenarbeit bedeutet

Kurze Wege. Sie schreiben nicht an ein Postfach, sondern an eine Person. Fragen zu Architektur, Betrieb oder Rechnung landen bei jemandem, der sie beantworten kann, ohne intern zurückzufragen.

Weniger Übersetzungsverlust. In größeren Konstellationen wandert eine Anforderung vom Kunden zum Projektleiter, von dort in ein Ticket, von dort zu einer Entwicklerin, die den fachlichen Hintergrund nie gehört hat. Jede Station kostet Genauigkeit. Wir haben weniger Stationen.

Verantwortung, die zuordenbar ist. Wenn nachts ein System steht, gibt es bei uns keine Zuständigkeitsfrage. Das ist der Grund, warum wir Betrieb als eigene Leistung führen und nicht als Anhang zum Projekt — nachzulesen unter Betrieb und Weiterentwicklung.

Grenzen, die wir aussprechen. Wenn ein Vorhaben mehr Kapazität braucht, als wir haben, sagen wir das im Erstgespräch — nicht im dritten Projektmonat.

Wie wir einstellen

Wir stellen selten ein und dann für lange. Uns interessiert weniger, wie viele Technologien jemand aufzählen kann, sondern ob jemand ein System übernehmen und ein halbes Jahr später noch verantworten will. Wer bei uns anfängt, arbeitet ab dem ersten Monat an Code, der in Produktion läuft, und redet ab dem ersten Quartal direkt mit Kunden.

Wenn Sie das interessiert: Unsere offenen Stellen und was wir ausdrücklich nicht bieten, stehen auf der Karriereseite.