Leistungen
Foliendecks und Berater-Buzzwords — Echtes Engineering von einem Praktiker, der den Code schreibt und die Cluster, Pipelines und Deployments selbst betreibt.
Wer diese Leistungen liefert
Alle Leistungen auf dieser Seite liefert der Gründer selbst — founder-led, ohne Account-Schicht dazwischen. Spezialisten kommen nur dazu, wenn ein Projekt eine Kompetenz außerhalb dieses Rahmens braucht; sie werden vorher benannt und abgestimmt, die Lieferverantwortung bleibt bei der Appetizer Labs UG. Weil die Kapazität begrenzt ist, laufen nur wenige Projekte parallel — Verfügbarkeit klären wir, bevor ein Angebot entsteht.
Liefermodell im Detail →Cloud-Native Strategie
Cloud-Native heißt nicht, VMs auf EC2 zu schieben und fertig. Wir analysieren eure Ist-Situation, entwickeln eine realistische Roadmap und planen Migrationen, die funktionieren — nicht nur auf dem Papier.
- Cloud-Readiness Assessment eurer bestehenden Systeme
- Migrationsstrategie: Re-platform, Re-architect oder Hybrid — je nach Business Case
- Kosten-Nutzen-Analyse und ROI-Planung für Cloud-Investitionen
- Vendor-Lock-in-Bewertung und Multi-Cloud-Überlegungen
- Organisatorische Readiness: Teams, Prozesse, Skills
Kubernetes & Container-Orchestrierung
Kubernetes in Produktion ist kein Wochenendprojekt. Wir bauen Cluster, die unter Last stabil bleiben, sicher sind und von eurem Team betrieben werden können.
- Produktionsreife Kubernetes-Cluster (EKS, self-managed, on-prem)
- Service Mesh und Observability — weil blind fahren keine Option ist
- Container-Strategien, Image-Pipelines und Registry-Management
- Namespace-Strategien, RBAC und Network Policies
- Migration bestehender Workloads auf Container-Plattformen
AWS Cloud-Architektur
AWS richtig nutzen heißt mehr als EC2-Instanzen starten. Wir entwerfen Architekturen nach dem Well-Architected Framework und sorgen dafür, dass eure Cloud-Rechnung keine Überraschungen enthält.
- Well-Architected Reviews und Optimierungsempfehlungen
- Multi-Account-Strategien und Landing Zones mit AWS Organizations
- Kostenoptimierung: Reserved Instances, Savings Plans, Right-Sizing
- Security-Baseline: IAM, GuardDuty, Config, CloudTrail
- Hochverfügbarkeits- und Disaster-Recovery-Architekturen
DevOps & Platform Engineering
Infrastruktur, die Entwickler nicht ausbremst. Pipelines, die in Minuten laufen. Developer Platforms, die Self-Service ermöglichen, statt Tickets zu produzieren.
- CI/CD-Pipelines, die tatsächlich verlässlich sind
- Infrastructure as Code mit bewährten Patterns
- GitOps-Workflows für deklarative Infrastruktur
- Internal Developer Platforms für Self-Service
- Observability-Stack: Monitoring, Logging, Tracing — integriert, nicht zusammengestückelt
Architektur-Modernisierung
Der Monolith muss nicht an einem Tag sterben. Wir helfen euch, Schritt für Schritt zu modernisieren — Tech Debt abbauen, Services schneiden, Event-driven denken.
- Monolith-zu-Microservices-Strategien (Strangler Fig, Branch by Abstraction)
- Tech-Debt-Analyse mit konkretem Abbauplan und Priorisierung
- Event-driven Architecture: Events, Commands, CQRS wo es Sinn ergibt
- Domain-Driven Design für saubere Service-Grenzen
- API-Strategie und Versioning für nachhaltige Schnittstellen
Software-Entwicklung
Wir bauen Software — nicht nur Infrastruktur. Backends, APIs, Frontends, mobile Apps. Go, TypeScript, React, Svelte — was zum Problem passt.
- Backend-Entwicklung: Go, TypeScript/Node.js, REST & GraphQL APIs
- Frontend-Engineering: React, Svelte, Astro — performant und wartbar
- Fullstack-Prototypen und MVPs in Wochen statt Monaten
- Code Reviews, Pair Programming, Knowledge Transfer mit eurem Team
- Testautomatisierung, CI/CD-Integration und Production Readiness
Platform Engineering im Detail
Die Plattformarbeit oben hat eine eigene Seite: woran ihr den Engpass erkennt, was enthalten ist, was nicht, wie eine Zusammenarbeit läuft und welches Einstiegsangebot dazu passt.
Kubernetes im Detail
Der Cluster-Betrieb oben hat eine eigene Seite: woran ihr einen halbfertigen Cluster erkennt, was „produktionsreif“ konkret heißt, was enthalten ist — und wann Kubernetes die falsche Wahl ist.
Cloud-Modernisierung im Detail
Die Modernisierungsarbeit oben hat eine eigene Seite: wann ein Rewrite die falsche Antwort ist, wie eine Migration in Wellen geschnitten wird, was am Ende bei euch liegt und woran der Umbau scheitern kann.
Engineering Growth Assessment
Der Einstieg mit festem Umfang: Wir prüfen, ob Organisation, Plattform und technische Führung die nächste Wachstumsstufe tragen — und wo ihr zuerst investieren solltet. Ergebnis sind eine Risikokarte, ein priorisierter Aktionsplan und ein Readout für die Führungsebene.
Delivery Bottleneck Assessment
Für den Fall, dass die Auslieferung langsam, riskant oder unberechenbar geworden ist. Wir gehen den Weg einer Änderung von der Entscheidung bis in die Produktion ab und finden die wenigen Stellen, die den Durchsatz begrenzen — technisch, prozessual oder in der Verantwortung. Ergebnis sind eine Engpasskarte, ein priorisiertes Backlog und ein Plan für die nächsten Monate.
Nicht sicher, welche Leistung ihr braucht?
Dann fangt mit der Analyse an. Das Platform-Bottleneck-Assessment ist ein eigener Auftrag mit festem Umfang und Festpreis: Wir finden heraus, was eure Auslieferung ausbremst, und ihr bekommt es schriftlich — mit Priorisierung und einer Roadmap. Was danach passiert, entscheidet ihr.
Platform Recovery Sprint
Wenn der Weg in die Produktion nicht mehr trägt: ein Angebot mit festem Umfang und festem Endtermin — Baselines, Verantwortlichkeiten und ein Golden Path an einem echten Service, mit gemergten Änderungen statt Empfehlungen.
Kubernetes Platform Build
Wenn die Plattform erst noch entstehen muss: zwölf Wochen mit festem Umfang, an deren Ende zehn Bedingungen erfüllt sind — jede davon von eurem Team geprüft, nicht von uns behauptet.
Welcher der drei Aufträge passt zu eurer Lage?
Drei Aufträge mit festem Umfang, in der Reihenfolge, in der sie üblicherweise aufeinander folgen. Ihr braucht selten alle drei — meist beantwortet einer davon die Frage, die ihr gerade habt.
| Kriterium | Platform-Bottleneck-Assessment | Platform Recovery Sprint | Kubernetes Platform Build |
|---|---|---|---|
| Die Frage, die es beantwortet | Woran hängt unsere Auslieferung, und in welcher Reihenfolge beheben wir das? | Wie bekommen wir unseren Weg in die Produktion wieder tragfähig? | Worauf laufen unsere Anwendungen künftig, und wer betreibt das? |
| Wann es passt | Ihr merkt, dass es klemmt, seid euch im Team aber nicht einig, woran. | Ihr wisst, woran es klemmt, und wollt es an einem echten Service behoben haben. | Es gibt noch keine Plattform, die euren Weg in die Produktion trägt. |
| Dauer | 5 Arbeitstage Analyse, verteilt über 3 Wochen. | 4 Wochen mit festem Endtermin, darin 12 Tage unserer Arbeitszeit. | 12 Wochen in vier Abschnitten, darin 36 Tage unserer Arbeitszeit. |
| Was euer Team einbringt | Lesezugriff auf Code, Pipelines und Monitoring, Gespräche mit sechs bis zehn Personen, eine entscheidungsbefugte Ansprechperson. | Etwa einen Tag pro Woche je beteiligtem Teammitglied: entscheiden, reviewen, mergen. | Ebenfalls etwa einen Tag pro Woche, dazu Cloud-Konto, Identity Provider und eine benannte Person, der die Plattform danach gehört. |
| Was am letzten Tag dasteht | Sechs schriftliche Ergebnisse: Engpass-Register, Sofortmaßnahmen, Zielbild und eine Roadmap für 90 Tage. | Gemergte Änderungen in euren Repositories und ein Referenz-Service, der darüber läuft. | 10 Bedingungen, die erfüllt sind oder nicht — jede vorgeführt, geprobt oder gemessen. |
| Was danach möglich ist | Sprint, Build oder nichts davon. Die Entscheidung ist vom Auftrag getrennt. | Ihr übertragt den Golden Path auf weitere Services — mit oder ohne uns. | Euer Team betreibt die Plattform und schaltet weitere Workloads selbst auf. |
Alle drei sind Festpreisaufträge. Eine Preisliste veröffentlichen wir nicht — den Preis nennen wir im Angebot, zusammen mit dem Zuschnitt, bevor ihr euch festlegt.
Workshops & Enablement
Wenn euer Team die Arbeit danach selbst weiterführen soll: sechs Formate mit festem Umfang, fester Dauer und begrenzter Gruppengröße — von Go über Kubernetes-Betrieb bis zur moderierten Architekturentscheidung.
Wo klemmt es bei euch?
Bevor ihr eine Leistung auswählt: acht Fragen zu Auslieferung, Architektur, Betrieb und Verantwortung, ausgewertet im Browser. Das Ergebnis benennt die schwächste Stelle und was ihr dort selbst zuerst tun könnt.
Wo steht eure Plattform insgesamt?
Die Diagnose sucht die schwächste Stelle, die Scorecard zeigt das ganze Bild: zehn Bereiche von Auslieferung bis Wissen im Team, je vier Stufen, ausgewertet im Browser. Ihr bekommt eine Stufe je Bereich und den nächsten Schritt für die drei schwächsten.
Die Checkliste zum Mitnehmen
Die lange Version der Diagnose, auf Papier: vierundzwanzig Aussagen zu eurem Weg in die Produktion, gedacht zum gemeinsamen Durchgehen im Team statt zum Klicken im Browser. Was offen bleibt, ist der Engpass — und der Einstieg in ein Assessment. Als PDF, ohne Formular.
KI + EU Compliance
Für Teams mit KI-Roadmap: konkrete Einstiege zu AI-Act-Checkliste und Risikoklassen, statt abstrakter Beratung.
Häufige Fragen
Wie startet eine Zusammenarbeit?
Mit einem kurzen Erstgespräch per E-Mail oder LinkedIn — ohne Lead-Formular. Danach klären wir in einem kompakten Discovery-Block Zielbild, Engpässe und Risiken und leiten daraus einen priorisierten Umsetzungsplan ab.
Arbeitet ihr remote oder vor Ort?
Remote-first. Vor-Ort-Termine in NRW sind möglich, Projekte betreuen wir im gesamten DACH-Raum.
Bleiben wir nach dem Projekt von euch abhängig?
Nein. Wissenstransfer, Dokumentation und gemeinsame Delivery mit eurem Team gehören zum Projekt. Wir bauen Plattformen so, dass euer Team sie selbst betreiben kann.
Welche Technologien setzt ihr ein?
In der Plattformarbeit Kubernetes (EKS, self-managed, on-prem), AWS, Infrastructure as Code und GitOps. In der Software-Entwicklung Go, TypeScript, React, Svelte und Astro. Die Auswahl richtet sich nach dem Problem, nicht nach Vorlieben.
Wir haben bereits ein Plattform-Team. Was bringt ihr dann noch?
Wir ersetzen euer Plattform-Team nicht und übernehmen es nicht. Wir kommen für eine abgegrenzte Frage: eine Architekturentscheidung, bei der das Team gespalten ist, ein Cluster-Upgrade, das seit Quartalen verschoben wird, ein Golden Path, den im Alltag niemand benutzt. Gearbeitet wird mit dem Team — Pairing, Reviews, Entscheidungen schriftlich im Repository — nicht daran vorbei. Ohne ein Team, das das Wissen aufnimmt, wäre die Übergabe am Ende wertlos. Wenn euer Team die Antwort kennt und nur keine Stunden frei hat, braucht ihr Kapazität. Die verkaufen wir nicht: Wir stellen niemanden für eine offene Rolle ab. Dafür sind Freelancer oder eine Personalvermittlung der ehrlichere Weg.
Wir brauchen eigentlich nur eine zusätzliche Entwicklerin oder einen Entwickler. Passt das?
Eine zusätzliche Person löst ein Mengenproblem. Wir kommen, wenn der Engpass an einer Entscheidung oder an fehlender Erfahrung hängt — Kubernetes in Produktion, eine Migration, die zweimal gescheitert ist, eine Pipeline, die niemand mehr anfassen will. Solche Engpässe verschwinden nicht durch mehr Hände, sondern durch eine Entscheidung, die jemand schon einmal getroffen hat. Danach macht euer Team weiter, ohne dass wir bleiben. Für eine dauerhaft besetzte Rolle — Regelbetrieb, Rufbereitschaft, laufende Tickets — sind eine Festanstellung oder Freelancer günstiger und passender. Wir sind keine Personalvermittlung und übernehmen keinen Betrieb.
Wir können keinen Produktionszugang geben. Geht das trotzdem?
Analyse, Architektur und Arbeit an Infrastructure as Code laufen ohne Produktionszugang: Repositories, Konfiguration, Metriken, Kostenreports und Gespräche mit dem Team ergeben ein belastbares Bild. Wo ein Eingriff in Produktion nötig wäre, arbeiten wir über euer Team — geteilter Bildschirm, ihr führt aus, wir sitzen daneben. Vertraulichkeitsvereinbarung und Auftragsverarbeitungsvertrag klären wir vorher, nicht nebenbei. Ohne Produktionszugang und ohne Zugang zu Menschen, die ihn haben, lässt sich eine Ursache nicht finden. Für einen akuten Ausfall reicht das nicht — dann bleibt nur eine Einschätzung auf Basis dessen, was ihr zeigen könnt.
Wann wir nicht die Richtigen sind
Ehrlich vorab, damit niemand eine Woche verliert: Diese Anfragen sagen wir ab. Nicht weil die Arbeit schlecht wäre, sondern weil andere sie besser machen. Wer eine Empfehlung braucht, bekommt sie auf Nachfrage.
Rund-um-die-Uhr-Betrieb, Rufbereitschaft und SLA-gebundene Betriebsverantwortung
Wir bauen Plattformen und übergeben sie betriebsfähig. Den Betrieb selbst übernehmen wir nicht — das kann ein Managed-Service-Provider zusagen, wir nicht.
Zertifikate, Audit-Freigaben und Konformitätserklärungen
Die technische Umsetzung in Richtung ISO 27001, NIS2 oder AI Act gehört zur Arbeit. Das Testat ausstellen darf nur eine akkreditierte Prüfstelle — dafür braucht es einen Auditor, keinen Ingenieur.
Projekte ohne eigenes Entwicklungsteam
Wissenstransfer ist fester Bestandteil jeder Zusammenarbeit. Ohne Team, das übernimmt, wird daraus dauerhaftes Outsourcing — ein Modell, das wir nicht anbieten.
Transformationsprogramme mit vielen parallelen Workstreams
Ab etwa vier gleichzeitigen Strängen braucht es eine Delivery-Organisation. Wir arbeiten in kleiner Besetzung; alles andere hieße, fremde Köpfe dazuzukaufen.
Festpreis für eine Gesamttransformation, bevor jemand hineingesehen hat
Eine ungeprüfte Legacy-Landschaft zu bepreisen ist Raten. Wir schätzen nach einer kurzen Analyse — und sagen auch, wenn sich der Umbau nicht lohnt.
ERP-Modulberatung, Customizing und ABAP-Entwicklung
Cloud-native Engineering rund um eine bestehende ERP-Landschaft machen wir. Im Modul selbst arbeiten besser Leute, die den ganzen Tag nichts anderes tun.