Software,
gebaut, um
zu bleiben.

Was wir bauen

Die Arbeit, die wir mögen, ist die, die weiterlaufen muss. Neue Produkte, die ausgeliefert werden müssen und dann ihr zweites Jahr überleben. Interne Tools, die ein fragiles Tabellenblatt ersetzen, auf dem eine Abteilung leise ihren Monatsabschluss aufgebaut hat. Backends, die die Last einer Funktion tragen müssen, die Ihre Wettbewerber gleich starten werden.

Wir sind das Team, das Sie anrufen, wenn die Antwort auf „sollten wir das selbst bauen?” lautet: „ja, und wir wollen es richtig machen.”

Wie wir typischerweise zusammenarbeiten

• 0→1-Projekte. Neue Produkte von Grund auf, bei denen wir Design, Architektur und Auslieferung übernehmen. Sie bringen das Geschäftsproblem; wir bringen das Engineering.
• Rettungsprojekte. Eine Codebasis, geerbt von einem früheren Team oder einer Agentur, die stabilisiert, dokumentiert und wieder in Produktion gebracht werden muss. Wir beginnen mit einem kurzen Audit, schlagen einen Aufräumplan vor und führen ihn aus.
• Long-Tail-Plattformen. Software, die ein Geschäft im Stillen trägt — Auftragsverarbeitung, Anspruchspipelines, interne Administration. Wenig glamourös, aber das Erste, worauf alle schauen, wenn sie ausfällt.

Technologien, die wir nutzen

Wir nutzen langweilige, bewährte Technologie. Frameworks werden nach Passung gewählt, nicht weil sie letztes Quartal auf Hacker News in Mode waren.

• Frontend. React, Vue, Angular. TypeScript überall.
• Backend. Java mit Spring Boot, Node, gelegentlich Python.
• Mobile. React Native oder nativ, wenn der Fall es rechtfertigt.
• Datenbank. Postgres für fast alles, mit Redis oder einer Nachrichten-Queue, wenn die Last es rechtfertigt.

Was wir nicht tun

Wir nehmen keine Arbeiten an, die voraussetzen, Experten für Dinge zu sein, die wir nicht sind. Wenn Sie eine Marketing-Website, eine Werbekampagne oder eine Markenidentität brauchen, verweisen wir Sie gern an jemand Besseren.

Was wir tun

Cloud-Infrastruktur, die ungestörte Nächte ermöglicht. Wir entwerfen, bauen und betreiben Systeme auf AWS, GCP und (wo es Sinn ergibt) on-prem oder hybrid. Wir wählen die Architektur, die zur Last passt — nicht die, die die Cloud-Rechnung maximiert.

Wie wir typischerweise zusammenarbeiten

• Neue Plattformen. Infrastruktur von Grund auf entworfen, mit dokumentierten Trade-offs, damit der nächste Ingenieur sie lesen kann.
• Migrationen. Lift-and-Shift, Replatforming oder vollständiger Neuentwurf. Wir haben genug Monolithen bewegt, um zu wissen, welche Wege es wert sind und welche zu meiden sind.
• Stabilisierung. Ein System, das im Großen und Ganzen funktioniert, aber zu oft Alarme auslöst. Wir diagnostizieren, instrumentieren und lösen die wirklichen Ursachen — nicht nur die Symptome.
• Kontinuierlicher Betrieb. Langfristige Zusammenarbeit, bei der wir das Licht anlassen, Vorfälle managen und uns um das wenig glamouröse Patchen kümmern, das niemand sonst übernehmen will.

Worauf wir laufen

• AWS — der Großteil unserer Arbeit. EKS, ECS, RDS, Lambda, die üblichen Dienste.
• GCP — wenn es einen Grund gibt (BigQuery, Vertex, regulatorisch).
• Kubernetes — wenn der operative Aufwand gerechtfertigt ist. Niemals standardmäßig.
• Terraform — Infrastructure as Code, versioniert, peer-reviewed.
• Docker — überall.
• Observability — Prometheus, Grafana, OpenTelemetry, gelegentlich Datadog.

Was wir nicht tun

Wir verkaufen Ihnen keine Architekturen, die komplexer sind, als Ihr Problem es erfordert. Wenn eine einzige EC2-Instanz und eine managed Postgres die richtige Antwort sind, ist das, was wir vorschlagen. Die Aufgabe ist, Ihr Problem zu lösen, nicht unsere Rechnung in die Höhe zu treiben.

Wann es nützlich ist

Manche technischen Entscheidungen sind später leicht zu ändern. Andere blockieren Sie still für Jahre. Wir sind das Team, das Sie anrufen, wenn Sie eine ehrliche zweite Meinung zu Entscheidungen der zweiten Art brauchen — und es vorziehen, jetzt dafür zu zahlen, statt die Kosten achtzehn Monate später zu entdecken.

Wie wir typischerweise zusammenarbeiten

• Architekturreviews. Wir lesen Ihre Designdokumente, sprechen mit Ihren Ingenieuren und liefern eine schriftliche Bewertung mit priorisierten Empfehlungen. In der Regel 2 bis 4 Wochen.
• Technische Due Diligence. Übernahmen, Allianzen, große Lieferantenbindungen. Wir bewerten das Engineering, nicht nur den Code — Team, Prozess, Schulden, Schlüsselpersonenrisiko.
• Zweite Meinungen. Eine konkrete Entscheidung (Build vs. Buy, Framework-Wahl, Migrationsansatz), bei der Sie die externe Perspektive von jemandem ohne eigenes Interesse wollen.
• Fractional CTO. Für Gründer, die senior Engineering-Urteilsvermögen brauchen, aber noch keine Vollzeitstelle.

Was wir nicht tun

• Wir sagen Ihnen nicht, was Sie hören wollen. Wenn Ihre Architektur in Ordnung ist, sagen wir es, ohne uns Probleme auszudenken, um abzurechnen. Wenn nicht, erklären wir Ihnen warum in einer Sprache, die Ihr CFO lesen kann.
• Wir empfehlen uns nicht für die aus dem Review folgenden Implementierungsarbeiten, sofern Sie uns nicht ausdrücklich darum bitten. Beratung und Bau sind aus einem Grund getrennte Engagements.

Ergebnis

Jedes Engagement endet mit einem schriftlichen Dokument — meist 10 bis 30 Seiten —, auf dem Ihr Team nach unserer Abreise handeln kann. Präsentationen auf Anfrage, aber wir bevorzugen, dass Ihnen das Dokument bleibt.

Was wir tun

Test-Infrastruktur, die Regressionen abfängt, bevor sie in die Produktion gelangen. Release-Pipelines, die jedes Deployment zu einer Routinesache machen. Monitoring, das warnt, bevor Ihre Nutzer es bemerken.

Die meisten Teams investieren zu wenig in diese Arbeit, weil sie nie am dringendsten erscheint — bis etwas im schlimmsten Moment kaputtgeht. Wir helfen Ihnen, die langweilige Arbeit zu machen, die Vorfälle im schlimmsten Moment verhindert.

Wie wir typischerweise zusammenarbeiten

• Aufbau von Testautomatisierung. Eine echte Test-Suite — Unit-, Integrations-, End-to-End — in die CI integriert und in die Ihr Team Vertrauen hat. Nicht tausend instabile Tests, die jeder zu ignorieren lernt.
• CI/CD-Pipelines. Schnelle, reproduzierbare, sicher zurückzurollende Deployments. Wir haben genug von der Alternative gesehen.
• Last- und Performance-Tests. Realistische Lastprofile, identifizierte Engpässe, dokumentierter Spielraum. Besonders wertvoll vor Launches oder saisonalen Spitzen.
• Quality Engineering als Praktik. Eingebettet in Ihr Team für ein oder zwei Quartale, mit Hinterlassen sowohl der Infrastruktur als auch der Gewohnheiten.

Werkzeuge, die wir nutzen

• Test-Runner. Jest, Vitest, Playwright, Cypress, JUnit. Je nachdem, was in Ihrem Stack üblich ist.
• CI. GitHub Actions, GitLab CI, gelegentlich Jenkins, wenn die Umgebung es erfordert.
• Last. k6, Locust, JMeter.
• Monitoring. Prometheus + Grafana, Datadog, Sentry.

Eine Anmerkung zur Testphilosophie

Wir glauben nicht an 100 % Abdeckung als Ziel. Wir glauben daran, das abzudecken, was zählt — kritische Pfade, Randfälle, die Sie schon einmal gebissen haben, Integrationen, die wahrscheinlich abdriften. Eine kleine, schnelle, zuverlässige Test-Suite ist mehr wert als eine riesige, die niemand ausführt.