Das Wavect-Glossar

Ein CTPO trägt die Verantwortung eines CTO und eines CPO unter einem Hals. Er besitzt, was gebaut wird, wie es gebaut wird und ob es das Problem des Kunden tatsächlich löst. Die Rolle existiert, weil Pre-PMF-Startups sich zwei Senior-Hires nicht leisten können und es sich politisch nicht leisten können, dass CTO und CPO jeden Dienstag über Priorität streiten.

Beispiel, warum die kombinierte Rolle früh gewinnt: Ein Startup mit zwei Foundern shippt immer wieder Features, nach denen der lauteste Investor gefragt hat, weil der technische Co-Founder baut, worauf das Produktgespräch landet, und niemand die Reihenfolge verantwortet. Ein CTPO bricht diese Schleife auf. Dieselbe Person, die entscheidet, dass das Checkout-Redesign wichtiger ist als das Dashboard, entscheidet auch, wie es architektiert wird und ob es in diesem Sprint shippen kann. Es gibt keine Übergabe, keine Übersetzungsschicht und kein Dienstags-Patt zwischen zwei C-Level-Egos, was die größte einzelne Quelle für vergeudeten Runway vor PMF ist.

In einem Wavect-Engagement ist ein CTPO meist fractional. Wir führen ihn als dedizierten Fractional CTPO-Retainer für Teams mit Early Traction, und vor dem PMF wird dieselbe kombinierte Rolle über unser Fractional-Co-Founder-Modell ausgeliefert. Ein Operator betreibt Produkt-Discovery und technische Architektur in derselben Woche und übergibt an einen späteren Split (CTO + CPO), sobald Umsatz und Org-Struktur beide Vollzeit-Rollen rechtfertigen. In Österreich läuft dieses Engagement normalerweise als freier Dienstvertrag, weil die Leistung laufendes Urteilsvermögen ist, kein fixes Werk.

Der ehrliche Trade-off und der häufige Founder-Fehler: Eine Person wird zum Single Point of Failure, und Founder verlieben sich in die Bequemlichkeit und behalten den CTPO weit über den Punkt hinaus, an dem die Rolle hätte gesplittet werden sollen. Die Mitigation ist ein CTPO, der weiß, wann er aufhören muss CTPO zu sein, und seine eigene Nachfolge rekrutiert; wer sich nicht selbst entlassen will, ist der falsche CTPO. Die Rolle sollte sich splitten, wenn Engineering-Management ein Vollzeitjob wird (meist ab 8 Engineers) und Produkt nicht auf einen wöchentlichen Batch warten kann. Davor erzeugt der Split nur Koordinationssteuer. Verwandt: Fractional CTO Österreich.

Ein CTO besitzt drei Dinge: worauf gebaut wird, wie zuverlässig ausgeliefert wird und ob die vor zwei Jahren gewählte Architektur dem Geschäft heute noch dient. Er ist nicht einfach der seniorste Engineer oder ein Senior Tech Lead mit schickerem Titel. Er ist der Operator, der entscheidet, welche Feuer gelöscht und welche bewusst stehengelassen werden, und der das technische Risiko trägt, das auf der Beirats-Agenda landet.

Bei Wavect unterscheiden wir drei Ausprägungen. Ein Founding CTO sitzt auf dem Cap Table und ist im Code, in den Trenches. Ein Scale-up CTO hat 20+ Engineers, die an ihn berichten, und führt Engineering vor allem über eine Engineering-Manager-Schicht. Ein Fractional CTO füllt die Lücke, wenn weder das eine noch das andere Profil bereits durch Umsatz gerechtfertigt ist.

Beispiel für den häufigsten und teuersten Fehler: Ein Seed-Stage-Startup raised eine Runde, bekommt den Rat, „einen echten CTO einzustellen", und rekrutiert einen beeindruckenden Namen aus einer Firma mit 200 Engineers. Diese Person hat fünf Jahre lang Org-Charts und Budgets geführt, keinen Code geschrieben, und landet jetzt in einem Vier-Personen-Team, das jemanden braucht, der das System architektiert und es selbst shippt. Sechs Monate und ein Viertel des Runways später hat das Team Prozess und Slide-Decks, aber das Produkt hat sich kaum bewegt. Der CV war echt; es war das falsche Profil für die Stage. Match das Profil an die Stage, nicht an das Logo.

Der ehrliche Trade-off, dem Founder ausweichen: Ein Founding-geformter CTO, der bauen kann, stößt irgendwann an eine Decke auf der Management-Seite, und ein Scale-up-CTO, der managen kann, ist bei vier Engineers verschwendet (und gelangweilt). Die Rolle verändert sich tatsächlich mit dem Wachstum der Firma, weshalb die Frage selten „brauchen wir einen CTO" lautet, sondern „welchen CTO braucht diese Stage". Lautet die Antwort „die Entscheidungsbefugnis, aber noch nicht die Vollzeitkosten", deckt die fractional Variante das ab. Siehe Fractional CTO Österreich für Wavects Pillar-Engagement.

Ein CPO besitzt das Produkt. Nicht das Design, nicht das Engineering, nicht das Marketing, sondern die Frage, was Kunden in welcher Reihenfolge bekommen. Die Rolle existiert, weil jede Shipping-Entscheidung gleichzeitig eine Entscheidung dagegen ist, etwas anderes zu shippen, und ab einer gewissen Größe braucht diese Wahl einen Verantwortlichen. Kombiniere sie mit dem CTO-Mandat in einer Person, und du bekommst einen CTPO; halte sie in Teilzeit, und du bekommst einen Fractional CPO.

Ein guter CPO spricht drei Sprachen fließend: Kunden (was schmerzt), Engineers (was möglich ist), Executive-Team (was die P&L bewegt). Fehlt eine dieser drei, entsteht Produkt-Schuld: gebaut, aber niemand kaufte; verkauft, aber niemand baute.

Beispiel für das Fehlende-Sprache-Versagen: Ein CPO, frisch aus einer sales-getriebenen Org, spricht P&L und Kunden fließend, kann aber nicht lesen, was Engineering ihm über Kosten sagt. Er legt die Roadmap auf ein Quartal voller „Quick Wins" fest, die in Wahrheit sechs Monate Plattformarbeit sind, die Termine rutschen, und auf beiden Seiten erodiert das Vertrauen. Das Spiegelbild-Versagen ist der Engineer-gewordene-CPO, der alles scopen kann, aber nicht sagen kann, welches Feature tatsächlich Umsatz bewegt. Der Job ist die Übersetzung zwischen allen dreien, und Schwäche in einer davon zeigt sich darin, dass selbstbewusst das Falsche gebaut wird.

Der ehrliche Trade-off und der häufige Fehler: Founder greifen zu früh nach einem dedizierten CPO. Vor PMF ist die Rolle Overkill, weil die eigene Kundenintuition des Founders das wertvollste Produkt-Asset der Firma ist und sich nicht delegieren lässt. Die Arbeit wird vom Founder oder einem CTPO absorbiert, bis das Engineering-Team so groß ist, dass die Entscheidung, was als Nächstes gebaut wird, ein Vollzeitjob ist. Vor diesem Punkt schiebt ein CPO meist nur eine Schicht zwischen Founder und Kunde, was das Gegenteil von dem ist, was ein frühphasiges Produkt braucht. Verwandt: Fractional CTO Österreich.

Fractional Co-Founder ist Wavects Flagship-Service und genau das, wonach es klingt. Wir embedden auf dem Level eines Co-Founders: Produktstrategie, technische Architektur, Sprint-Planung, Kundengespräche, Beirats-Prep. In Rollenbegriffen ist es meist ein fractional CTPO, Produkt und Technologie unter einem Hals. Wir kommen nicht mit getrackten Stunden. Wir kommen mit dem Ergebnis.

Pricing: 400 EUR pro Woche, wöchentlich kündbar, keine Frist, keine Exit-Gebühr. Wenn wir dich nicht überzeugen, wird die letzte Woche zurückerstattet. Wir machen das, weil der falsche Fit beide Seiten teuer kommt. Ein sauber endender Zwei-Wochen-Pilot ist ein besseres Ergebnis als ein sechsmonatiger Vertrag, der sich dahinschleppt.

Beispiel, wann das die richtige Form ist: Ein nicht-technischer Founder hat Umsatz, heuert aber immer wieder Agenturen an, die das Falsche bauen, weil niemand im Inneren das Briefing hinterfragen kann. Ein Fractional Co-Founder sitzt zwischen ihm und den Buildern, verantwortet die Roadmap, trifft die Architekturentscheidungen und sagt dem Founder, wann das Feature, an dem er emotional hängt, die falsche Wette ist. Diese Haltung, Eigentümer statt Contractor, ist der ganze Unterschied zum Fractional CTO, der technische Autorität abdeckt, aber nicht das Produkt- und Eigentümergewicht trägt.

Die österreichische rechtliche Nuance: Das wird als freier Dienstvertrag engagiert, nicht als Werkvertrag, weil wir laufendes Urteilsvermögen und Verfügbarkeit schulden statt eines fixen Werks, und anders als ein echter Co-Founder gibt es standardmäßig keine Equity und keinen Cap-Table-Eintrag. Der ehrliche Trade-off, und wo Founder es falsch machen: Das ist kein Körper, um Tickets abzuarbeiten (dafür nimmt man einen Contractor), und kein Ersatz für die eigene Überzeugung des Founders. Wer jemanden braucht, der sonntags um 23 Uhr unter einem klaren SoW eine harte Architekturentscheidung mitträgt, will diese Form von Engagement. Nach PMF und brauchst stattdessen einen CTO? Siehe Fractional CTO Österreich.

Der Markt für Fractional CTOs existiert, weil ein Vollzeit-CTO zu früh teuer und zu spät tödlich ist. Ein Fractional CTO überbrückt die Lücke: Er trifft Architekturentscheidungen, führt den Hiring-Loop für Senior Engineers, sitzt in Beiratssitzungen und schreibt die technischen Teile der Investor-Decks.

Beispiel: Eine Seed-Stage-Firma hat zwei starke Mid-Level-Engineers, einen Founder, der Code lesen, aber kein System architektieren kann, und einen Investor, der fragt, warum die Roadmap immer wieder rutscht. Sie braucht keinen Vollzeit-CTO für 180k plus Equity. Sie braucht jemanden für zwei Tage pro Woche, der die Architektur setzt, die zwei Engineers entblockt und die Roadmap in Milestones verwandelt, die der Beirat verfolgen kann. Das ist das Lehrbuch-Mandat eines Fractional CTO, und es läuft meist sechs bis zwölf Monate, bis ein Vollzeit-Hire gerechtfertigt ist.

Was er meistens nicht macht: Production-Code schreiben. Wer einen starken Einzel-IC braucht, will einen Senior Engineer mit CTO-Sounding-Board, nicht einen Fractional CTO, der selber das Engineering macht. Bei Wavect verwischen wir diese Linie manchmal, wenn das Team so klein ist, dass auch der CTO shippen muss; der SoW macht die Grenze explizit.

Die rechtliche Nuance in Österreich: Ein Fractional CTO wird normalerweise als Dienstvertrag oder freier Dienstvertrag engagiert, nicht als Werkvertrag, weil er laufendes Urteilsvermögen und Verfügbarkeit schuldet, nicht ein einzelnes fixes Werk. Das zählt für die Haftung und dafür, wie das Engagement verbucht wird. Lass dir von einem Anbieter keinen Fractional-CTO-Retainer als Fixed-Scope-Vertrag verkaufen; die Pflichten sind unterschiedlich.

Der häufige Founder-Fehler: einen Fractional CTO mit einem Fractional Co-Founder zu verwechseln. Der CTO deckt technische Autorität ab. Die Co-Founder-Haltung ergänzt Produktstrategie und Eigentümerverhalten. Wer jemanden will, der die Roadmap hinterfragt und nicht nur den Stack, will Letzteres. Der ehrliche Trade-off jedes fractional Modells ist Kontinuität: Eine Teilzeit-Führungskraft hat nie die Kontexttiefe einer Vollzeitkraft, also funktioniert das Engagement nur, wenn der Scope begrenzt ist und die Übergabe von Tag eins an geplant wird.

Achtung bei Anbietern, die „Fractional CTO" als umbenannte Account-Manager-Rolle verkaufen. Ein echter Fractional CTO hat Entscheidungsbefugnis, sitzt in denselben Meetings wie ein Vollzeit-CTO und steht in deinen Beiratsunterlagen.

Ein Interim CTO ist eine Vollzeit-Führungskraft auf Zeit, die das Engineering durch eine Übergangsphase führt, meist 3 bis 12 Monate. Der Auslöser ist ein Vakuum: Der bisherige CTO ist mitten im Fundraising gegangen, wurde freigesetzt, oder die Firma ist ihm schneller entwachsen, als ein Nachfolgeplan existierte. Der Interim übernimmt mit voller Kapazität, stabilisiert die Organisation und übergibt an den permanenten Hire, den er oft selbst mit rekrutiert.

Der Unterschied zum Fractional CTO ist die Form des Commitments, nicht die Seniorität. Fractional heißt 1 bis 3 Tage pro Woche, laufend, für eine Firma, die CTO-Autorität braucht, aber keine Vollzeit-Präsenz. Interim heißt fünf Tage pro Woche mit geplantem Enddatum, für eine Firma, die jetzt ein Loch in Vollzeitgröße hat. Entscheide nach der Größe des Lochs, nicht danach, welcher Titel seniorer klingt.

Beispiel: Ein Scale-up verliert seinen CTO acht Wochen vor einer Tech Due Diligence. Vierzig Engineers, drei Teams, kein Stellvertreter. Ein Fractional-Operator mit zwei Tagen pro Woche kann das nicht abfedern. Die Org braucht jemanden in jedem Leadership-Meeting, jeder Eskalation, jedem Diligence-Call, und das ist ein Interim-Mandat. Der Spiegelfall, ein Seed-Startup mit vier Engineers und rutschender Roadmap, hat ein Zwei-Tage-pro-Woche-Problem. Ein Vollzeit-Interim verbrennt dort Runway für Präsenz, die niemand braucht.

Die österreichische Rechts-Nuance entspricht dem Fractional-Modell: Ein Interim CTO läuft normalerweise als Dienstvertrag oder freier Dienstvertrag, weil die Leistung laufendes Urteilsvermögen und Verfügbarkeit ist, kein fixes Werk. Der ehrliche Trade-off beim Interim ist die Klippe: Alles, was der Interim gelernt hat, geht bei der Übergabe mit raus. Das Mandat muss deshalb Entscheidungs-Dokumentation und Nachfolger-Recruiting enthalten. Ein Interim, der bei seinem eigenen Exit-Plan vage bleibt, plant zu bleiben, und das ist ein anderes, teureres Produkt.

Wavects Engagements sind bewusst fractional, 1 bis 2 Tage pro Woche mit zwei Gründern auf jedem Mandat. Wenn du ein echtes Vakuum hast, das fünf Tage pro Woche braucht, stell einen Interim ein, und genau das sagen wir dir auch im ersten Call. Wo sich die beiden Formen überschneiden, steht auf Fractional CTO Österreich.

Seltener als das Fractional-CTO-Modell, aber zunehmend real. Ein Fractional CPO joint 1 bis 3 Tage pro Woche, betreibt Produkt-Discovery, sequenziert die Roadmap und besitzt die Kundeninterview-Kadenz. Engineering verantwortet er nicht. Design auch nicht, sofern man ihn nicht darum bittet.

Der Fit ist eng: Die Firma braucht Produkt-Seniorität, kann aber noch keinen Vollzeit-CPO rechtfertigen, UND der Founder ist bereit, die Produktentscheidung abzugeben. Wenn der Founder auch der Produktmensch ist und diese Autorität nicht teilen will, ist ein Fractional CPO ein Reibungsgenerator.

Beispiel: Eine Firma hat frühe Traktion erreicht, der Founder steckt im Vertrieb fest, und das Engineering-Team shippt, was der lauteste Kunde letzte Woche gefragt hat. Ein Fractional CPO kommt rein, um ein Priorisierungs-Framework zu installieren, eine ordentliche Discovery-Kadenz zu fahren und Engineering eine sequenzierte Roadmap statt einer Warteschlange von Einzelwünschen zu geben. Drei Tage pro Woche reichen, weil der Job Urteilsvermögen und Struktur ist, kein Ausführungsvolumen.

Der häufige Fehler von Foundern ist, einen Fractional CPO zu holen, um Produktentscheidungen vor PMF nicht selbst treffen zu müssen. Das funktioniert nie. Vor PMF ist die Intuition des Founders für den Kunden das einzelne wertvollste Asset der Firma und lässt sich nicht auslagern. Ein Fractional CPO skaliert eine Produktfunktion, die bereits einen Standpunkt hat; er erfindet keinen. In Österreich ist das Engagement typischerweise ein freier Dienstvertrag, wie die meisten fractional Executive-Rollen, weil die Leistung laufendes Urteilsvermögen ist statt eines fixen Werks.

Der ehrliche Trade-off: Ein Teilzeit-CPO hinkt einer Vollzeitkraft beim Kontext immer hinterher, und Produktkontext kumuliert. Wenn deine Roadmap-Entscheidungen täglich aus Gesprächen getroffen werden müssen, in denen der CPO nicht war, bricht das Modell. Es funktioniert, wenn Entscheidungen wöchentlich gebatcht werden können und das Team zwischen den Sessions ausführen kann.

Verwandt: Fractional CTO Österreich.

Ein Tech Lead ist zuerst Individual Contributor und zweitens Koordinator. Er schreibt Code. Er reviewt Code. Er entscheidet, wenn zwei Engineers über Implementierung streiten. Er ist kein Manager: Beförderungen, Performance Reviews und Hiring-Loops außerhalb des eigenen Teams gehören nicht dazu. Genau diese Unterscheidung trennt ihn von einem Engineering Manager, und sie falsch zu machen ist teuer.

Bei Wavect setzen wir oft einen Tech Lead neben einem Fractional CTO ein. Der CTO verantwortet Architektur und teamübergreifende Koordination. Der Tech Lead verantwortet die tägliche Output-Qualität des Teams: Code-Review-Standards, wie das Team Agile praktiziert, ob die Definition of Done echt oder Theater ist. Beide Rollen zu vermischen ist der häufigste Fehler in Series-A-Startups.

Beispiel für diesen Fehler: Eine Firma befördert ihren besten Engineer zum „Tech Lead" und packt dann still 1:1s, Hiring-Interviews und Headcount-Planung obendrauf. Sechs Monate später ist die Codebasis abgedriftet, weil niemand Senior sie reviewt, und der neue Lead ist ausgebrannt, weil er zwei Jobs schlecht macht. Die Lösung ist, den Split explizit zu benennen: Technische Autorität bleibt beim Tech Lead, People-Autorität wandert zu einem EM, auch einem fractional.

Der ehrliche Trade-off: Ein starker Tech Lead mit externem CTO-Sounding-Board schlägt auf dem Papier oft einen junioren Vollzeit-CTO und kostet weit weniger. Die Decke ist Entscheidungsbefugnis außerhalb des Teams. Ein Tech Lead verantwortet keine produktübergreifende Architektur und kein technisches Risiko auf Beiratsebene, und so zu tun verzögert nur den Moment, an dem man wirklich einen CTO braucht.

Wie viel sollte ein Tech Lead tatsächlich coden? Die meiste Zeit, und genau hier zerbrechen Founder die Rolle still. Der Instinkt, sobald jemand „der Lead" ist, ist, ihn in Meetings, Planung und Koordination zu ziehen, bis er zehn Prozent der Woche codet. Ein Tech Lead, der aufhört zu shippen, verliert den technischen Respekt des Teams und driftet von der Codebasis ab, von der er die tiefste Kenntnis haben sollte. Die Faustregel ist mindestens die halbe Zeit hands-on, der Rest für Review, Design und Entblocken. An dem Tag, an dem die Koordinationslast das wirklich übersteigt, hast du keinen überlasteten Tech Lead, sondern einen unbesetzten Engineering-Management-Sitz.

Verwandt: Fractional CTO Österreich.

Engineering Manager führen Menschen, nicht Architektur. Sie sitzen zwischen Engineers und dem Rest der Firma: Sie übersetzen Strategie in Team-Level-Prioritäten, besitzen den Hiring-Loop und führen die Gespräche, die kein Engineer führen möchte. Die technischen Entscheidungen bleiben beim Tech Lead; der EM sorgt dafür, dass die Menschen, die diese Entscheidungen treffen, wachsen, gestützt sind und nicht kurz vorm Kündigen stehen.

Ein guter EM hat technische Glaubwürdigkeit (Engineers respektieren ihn), ohne den Senior-ICs des Teams Konkurrenz zu machen. Ein schlechter ist entweder zu losgelöst, um zu führen, oder zu nah am Code, um zu managen. Die Rolle ist eine der schwersten zu hiren; die meisten frühphasigen Startups überhiren technisch und unterhiren im Management, weswegen Teams ab acht Personen zu wackeln beginnen.

Beispiel: Ein Team wächst in einem Jahr von fünf auf zehn Engineers. Niemand hat Management ergänzt, also fährt der Founding-CTO jetzt zehn 1:1s, drei Hiring-Loops und zwei Performance-Probleme, während er noch immer Architektur verantworten will. Die Velocity bricht ein, zwei Leute gehen, und alle geben „dem Prozess" die Schuld. Die eigentliche Ursache ist ein fehlender EM. Das Signal kommt Monate vor der Abwanderung: Die seniorste Person verbringt mehr Zeit in Meetings über Menschen als in der Codebasis oder im SDLC.

Der häufige Fehler ist, einen starken Senior Engineer ohne Training in die Rolle zu befördern und anzunehmen, die People-Skills würden den technischen folgen. Das tun sie meist nicht; die zwei Skillsets sind nahezu unabhängig. Befördere für nachgewiesenes Interesse an der People-Arbeit, dann lehre den technischen Kontext, nicht umgekehrt.

Der ehrliche Trade-off: Ein großartiger EM macht den Output des Teams für den Founder weniger lesbar, weil seine beste Arbeit (Retention, Entblocken, harte Gespräche) auf keinem Gantt-Chart auftaucht. Founder, die nur geshippte Features messen, neigen dazu, die Rolle zu unterschätzen und unterzubesetzen, bis das Wackeln zur Abwanderung wird.

Verwandt: Fractional CTO Österreich.

Ein Product Manager verantwortet das Was und das Warum, nicht das Wie. Er entscheidet, welches Problem das Team als Nächstes löst, warum es wichtig ist und was “fertig” für den Kunden bedeutet. Er schreibt nicht den Code, er führt den Sprint nicht als Vorgesetzter, und er entwirft nicht die Architektur. Seine Aufgabe ist es, dafür zu sorgen, dass das Team das Richtige baut, bevor irgendjemand darüber streitet, wie man es gut baut.

Die Rolle besteht vor allem aus Urteilsvermögen und Kommunikation unter widersprüchlichem Druck. Der Vertrieb will das Feature, das den Deal abschließt. Der Support will den Bug behoben. Der Gründer will die mutige Wette. Ein guter PM hält das alles aus, sagt zu den meisten Dingen laut Nein und liefert die eine Sache, die das Geschäft voranbringt. Er ist für das Ergebnis verantwortlich, was bedeutet, dass ihm die Roadmap und die Priorisierungsentscheidungen gehören, nicht nur die Pflege des Backlogs.

Product Manager versus Product Owner ist die Stelle, an der die meisten Teams durcheinanderkommen. Product Owner ist eine spezifische Scrum-Rolle: Sie besitzt und ordnet das Backlog, damit das Entwicklungsteam klar weiß, was als Nächstes zu bauen ist. Product Manager ist die breitere Geschäftsrolle: Markt, Strategie, Input zur Preisgestaltung, Abstimmung mit Stakeholdern und das Warum hinter der Roadmap. In einem kleinen Team trägt eine Person beide Hüte. In einem größeren gibt der PM die Richtung vor, und der PO macht daraus geordnete, baufertige Arbeit.

Die häufige Fehlbesetzung ist ein PM ohne Autorität. Wenn die Roadmap in Wahrheit vom lautesten Stakeholder bestimmt wird und der PM nur Tickets schreibt, hat man einen Projektkoordinator eingestellt und ihn Produkt genannt. Wir setzen Produktverantwortung in Gründungsteams als Teil eines Fractional-Co-Founder-Engagements ein, wenn der Gründer zu tief im Bauen steckt, um sie selbst zu tragen.

Ein Product Engineer ist ein Softwareentwickler, dem das Problem gehört, nicht nur die Umsetzung. Ein normaler Entwickler bekommt eine Spezifikation und baut sie gut. Ein Product Engineer fragt, ob die Spezifikation überhaupt das Richtige ist, spricht mit den Nutzern, die das Problem haben, entscheidet, was tatsächlich ausgeliefert wird, und schreibt dann den Code. Er führt den Product Manager und den Entwickler in einem Kopf zusammen. Das Ergebnis ist nicht “das Feature wie spezifiziert”, sondern “das Problem des Nutzers, gelöst”.

Die Rolle existiert, weil Produkte an der Übergabe sterben. Ein PM schreibt eine Spezifikation, ein Entwickler baut genau das, und drei Wochen später nutzt niemand das Feature, weil die Spezifikation ein Detail übersehen hat, das nur die Person am Code oder der Nutzer selbst bemerkt hätte. Ein Product Engineer fängt das mitten im Bauen ab, weil ihm beide Enden gehören. Er ist nicht per Definition erfahrener als ein normaler Entwickler. Er ist anders verdrahtet: Ihm geht es darum, dass die Kennzahl sich bewegt, nicht darum, dass das Ticket geschlossen wird.

Beispiel, warum die Verschmelzung gewinnt: Ein SaaS-Team liefert einen Onboarding-Flow exakt wie entworfen. Die Aktivierung bewegt sich nicht. Der PM gibt dem Bauen die Schuld, das Engineering der Spezifikation, und ein Monat ist weg, bevor irgendwer die eigentliche Hypothese testet. Ein Product Engineer hätte in drei Tagen eine dünnere Version ausgeliefert, fünf echten Nutzern dabei zugesehen, wie sie an Schritt zwei hängen bleiben, und Schritt zwei vor Sprintende neu gebaut. Gleiche Personalstärke, ein Zehntel der Durchlaufzeit, weil es keine Übergabe und keine Schuldzuweisungsschleife gab. Der Weg von “Nutzer hängen fest” zu “in Produktion behoben” lief in einem einzigen Kopf ab.

Das ist ein guter Teil dessen, was Wavect tatsächlich tut. Die meisten unserer Fractional-Co-Founder- und CTPO-Engagements sind Product Engineering unter anderem Namen: ein Operator, der das MVP scopt, mit euren Nutzern spricht und den Code ausliefert, statt eines PMs, eines Designers und dreier Dienstleister, die stille Post spielen. Der ehrliche Trade-off: Ein Product Engineer ist schwer zu finden und skaliert nicht linear. Man kann nicht zwanzig davon auf ein Produkt setzen, und die, die es gibt, sind teuer, weil die Kombination selten ist. Der Fehler, den Gründer machen: einen brillanten Coder ohne Interesse am Nutzer einstellen und sich dann wundern, warum die Roadmap voller eleganter Features ist, nach denen niemand gefragt hat. Die Lösung ist keine dickere PM-Schicht obendrauf, sondern ein Entwickler, der lieber mit einem Kunden spricht als eine Build-Pipeline zu tunen. Verwandt: Full-Stack Software-Entwicklung.

Ein Software Architect verantwortet die Entscheidungen, die schwer rückgängig zu machen sind. Wie das System in Services oder Module aufgeteilt wird, wie die Daten durch es fließen, wo die Grenzen liegen, auf welche Technologien sich der Stack festlegt und wie das Ganze unter Last, Ausfall und Wachstum standhält. Einzelne Features sind günstig zu ändern. Diese strukturellen Entscheidungen sind es nicht, weshalb jemand auf Systemebene und nicht auf Feature-Ebene denken muss.

Der eigentliche Wert liegt in den nicht-funktionalen Anforderungen: Performance, Skalierbarkeit, Sicherheit, Zuverlässigkeit, Wartbarkeit. Das sind die Dinge, die keinem einzelnen Feature-Ticket gehören und die ein Produkt im Stillen versenken, wenn man sie ignoriert. Die Aufgabe des Architekten ist es, die Trade-offs laut zu benennen. Jetzt schneller bauen versus später günstiger ändern. Einfach und begrenzt versus flexibel und komplex. Es gibt keine kostenlose Architektur, nur Trade-offs, die man bewusst gewählt hat, oder Trade-offs, die man aus Versehen geerbt hat.

Die meisten Startups brauchen keinen dedizierten Software Architect, und einen früh einzustellen ist meist ein Fehler. Bei kleiner Größe ist die Architektur klein, und der Tech Lead oder CTO trägt sie als Teil seiner Arbeit. Ein Vollzeit-Architekt ohne Code zum Schreiben und ohne Team zum Führen produziert tendenziell Diagramme und Standarddokumente, die das Team dann ignoriert. Die Rolle verdient ihren Platz, sobald das System groß genug ist, dass niemand mehr das ganze Bild im Kopf hat.

Die ehrliche Einschätzung: “Solutions Architect” im Organigramm eines Anbieters bedeutet oft eine Pre-Sales-Rolle, die Systeme entwirft, die sie nie warten muss. Ein guter Architekt bleibt nah genug am Code, um die Konsequenzen seiner eigenen Entscheidungen zu spüren. Wenn die Person, die die Kästchen zeichnet, nie in ihnen leben muss, werden die Kästchen falsch sein.

Wann das im Softwareprojekt zählt. Sobald das System groß genug ist, dass niemand mehr das ganze Bild im Kopf hält. Die strukturellen Entscheidungen, Service-Grenzen, Datenfluss, Stack-Festlegungen, sind die teuer zu revidierenden, also brauchen sie Denken auf Systemebene.

Was Founder meistens falsch machen. Sie stellen zu früh einen dedizierten Architekten ein. Bei kleinem Maßstab ist die Architektur klein und der Tech Lead oder CTO trägt sie; ein Vollzeit-Architekt ohne Code zu schreiben produziert meist Diagramme, die das Team dann ignoriert.

Wie Wavect damit umgeht. Unsere Architekten bleiben nah genug am Code, um die Konsequenzen ihrer eigenen Entscheidungen zu spüren, was der ganze Punkt ist. Die richtige Struktur früh zu wählen beginnt beim Stack, behandelt in wie man einen Tech-Stack für ein MVP wählt.

Ein Scrum Master hat einen einzigen echten Job: das Team effektiver zu machen, indem er Dinge aus dem Weg räumt. Das heißt, Blocker beseitigen, das Team vor Störungen mitten im Sprint abschirmen, die Standups und Retros so moderieren, dass sie nützlich sind statt Theater, und das Team coachen, wie man tatsächlich arbeitet, nicht nur die Zeremonien aufsagt. Er ist ein Diener des Teams, kein Chef über ihm. Er teilt keine Arbeit zu, er besitzt nicht das Backlog, und er macht keine Leistungsbeurteilungen.

Die Rolle wird in zwei Richtungen missverstanden. Manche behandeln sie als aufgewerteten Meeting-Planer, der das Standup-Skript abliest. Andere machen still einen Projektmanager daraus, der das Team auf Termine drängt. Beides verfehlt den Punkt. Der Wert liegt darin, zu erkennen, was das Team ausbremst, oft etwas Organisatorisches und Unbequemes, und das Standing zu haben, es zu beheben. Ein Scrum Master, der nur Meetings durchführt, ist Overhead.

Die ehrliche Einschätzung: Kleine Teams brauchen selten einen Vollzeit-Scrum-Master. Ein Team aus vier oder fünf Entwicklern kann seine eigenen Zeremonien durchführen, und die Moderationsarbeit sind ein paar Stunden pro Woche, die ein Tech Lead oder Senior Engineer auffangen kann. Ein dedizierter Vollzeit-Scrum-Master verdient den Platz, wenn man mehrere Teams koordiniert, wenn die Organisation rund um das Team die Hauptquelle der Blocker ist oder wenn ein Team sich noch wirklich nicht selbst organisieren kann. Darunter ist der Titel ein Kostenpunkt auf der Suche nach einer Rechtfertigung.

Wir haben viele Teams gesehen, die glücklicher und schneller waren, nachdem sie den Vollzeit-Scrum-Master gestrichen und die Arbeit ins Team verlagert hatten. Wir haben auch Teams gesehen, die untergingen, weil niemand die Blocker verantwortete. Die Rolle ist echt, die Vollzeit-Variante oft nicht.

CTO as a Service ist ein Verpackungs-Label, kein anderer Job. Unter dem Label verkauft ein Anbieter CTO-Urteilsvermögen (Architekturentscheidungen, Hiring-Loops, Vendor-Management, board-taugliches Reporting) als wiederkehrenden Service mit definiertem Zeit-Commitment. Zieh das Branding ab, und übrig bleibt ein Fractional CTO auf Retainer: gleiche Autorität, gleiche Meetings, ein Abo statt eines Gehalts.

Das Label ist relevant wegen dem, was es verstecken kann. “As a Service” suggeriert, die Person sei austauschbar, und CTO-Arbeit ist die am wenigsten austauschbare Arbeit, die eine Firma einkauft. Kontext verzinst sich: Die Architekturentscheidung aus Monat eins versteht nur, wer in Monat vier die Trade-offs hat landen sehen. Anbieter, die hinter einer Service-Marke Berater rotieren, setzen diesen Kontext bei jeder Rotation auf null, und der Kunde zahlt jedes Mal das Re-Onboarding.

Beispiel für den Failure Mode: Ein Startup unterschreibt ein CTO-as-a-Service-Paket bei einer Agentur. Im ersten Monat sitzt ein Senior-Architekt im Call. Ab Monat drei führt ein Account-Manager das wöchentliche Meeting und reicht Fragen an einen Pool weiter. Das Startup zahlt weiter Executive-Sätze, aber niemand im Raum kann ohne Rückfrage nach oben Nein zu einem Feature sagen. Das ist Account-Management mit CTO-Sticker, und es ist die häufigste Beschwerde, mit der Founder aus dieser Kategorie zu uns kommen.

Was du vor der Unterschrift prüfst: wer genau auftaucht (benannte Personen, kein Pool), ob diese Personen Entscheidungsbefugnis haben oder an jemanden eskalieren, den du nie triffst, und wie das Engagement endet (Übergabeplan, kein Renewal-Pitch). In Österreich läuft das normalerweise als Retainer im Dienstvertrags-Stil, nicht als Werkvertrag, weil die Leistung laufendes Urteilsvermögen ist. Eine saubere wöchentliche oder monatliche Kündigungsklausel ist die ehrliche Version von “as a Service”.

Wavects Version ist das Fractional CTO Österreich Engagement: CTO-on-Call ab 2.500 EUR pro Monat oder ein eingebetteter Operator mit 1 bis 2 Tagen pro Woche, zwei benannte Gründer auf jedem Mandat, wöchentlich kündbar.

Ein Statement of Work ist das Dokument, das aus einer mündlichen Abmachung einen Vertrag macht. Es listet die Leistung in konkreten Worten („Feature X live auf Production, erfüllt Akzeptanzkriterien A, B, C"), den Preis, die Frist und die Abnahmebedingungen.

Im österreichischen und deutschen Recht ist das entsprechende Instrument der Werkvertrag, der stärker ist als die englischsprachige SoW: Der Anbieter ist rechtlich zur Lieferung der Arbeit verpflichtet, nicht nur zum Aufwand, und der Kunde kann die Zahlung zurückhalten, bis die Arbeit abgenommen ist. Ein Time-&-Material-Vertrag im selben Rechtsrahmen ist ein Dienstvertrag, der nur Aufwand schuldet. Wavects Fixpreis-Engagements sind Werkverträge.

Beispiel, warum die Akzeptanzkriterien den ganzen Vertrag tragen: Ein SoW, das sagt „bau das Reporting-Feature, das Feature soll gut funktionieren", ist nicht durchsetzbar, weil „gut funktionieren" eine Meinung ist. Ein SoW, das sagt „Endpoint /reports liefert die Monatszahlen für Eingabebereich R innerhalb von 200 ms unter Last L, übereinstimmend mit den Werten in Spezifikation S", ist testbar, und „fertig" ist keine Verhandlung mehr. Der häufigste Founder-Fehler ist, ein vage formuliertes SoW zu unterschreiben, um am Anfang Zeit zu sparen, und dann sechs Monate darüber zu streiten, ob ein halbfunktionierendes Feature als geliefert zählt. Ein Anbieter, der sich gegen präzise Akzeptanzkriterien sträubt, schützt sein Recht, diesen Streit später zu führen.

Das SoW ist auch das Dokument, das Scope-Creep verhindert: Alles, was nicht drinsteht, ist per Definition außerhalb des Scopes und wird per Change Request behandelt. Beachte die Schichtung: Ein MSA (Master Services Agreement) deckt den rechtlichen Rahmen (IP, Haftung, Gerichtsstand) einmal ab, und viele SoWs leben über die Zeit darunter. Der ehrliche Trade-off ist, dass ein enges SoW echte Arbeit zum Schreiben kostet und sich vorab langsam anfühlt, was genau die Arbeit ist, für die eine bezahlte Discovery-Phase existiert. Verwandt: Fractional CTO Österreich erklärt das Werkvertrag-Modell in der Praxis.

Wann das im Softwareprojekt zählt. In dem Moment, in dem Geld den Besitzer wechselt. Das SoW ist der Ort, an dem „was du kaufst" aufhört, ein Gespräch zu sein, und durchsetzbar wird. Es entscheidet allein, ob ein späterer Streit per Vertrag oder per Lautstärke geklärt wird.

Was Founder meistens falsch machen. Sie unterschreiben ein schwammig formuliertes SoW, um schneller zu starten, und streiten dann monatelang, ob ein halbfertiges Feature als geliefert zählt. Die Akzeptanzkriterien tragen den ganzen Vertrag; „soll gut funktionieren" ist eine Meinung, keine Leistung.

Wie Wavect damit umgeht. Wir schreiben Akzeptanzkriterien präzise genug, um testbar zu sein, bevor jemand unterschreibt, und führen zuerst eine bezahlte Discovery durch, damit der Scope echt ist. Unser Leitfaden zur Wahl einer Softwareagentur und der Leitfaden Fixpreis vs Time & Material erklären die Vertragsentscheidung in Klartext.

Time & Material ist das Default-Modell bei Staffing-Agenturen und den meisten Freelance-Verträgen. Du zahlst Stunden- oder Tagessatz; der Anbieter loggt Stunden; die Rechnung kommt monatlich. Es gibt keine vertraglich geschuldete Leistung, nur vertraglich geschuldeten Aufwand. Im österreichischen und deutschen Recht entspricht das einem Dienstvertrag: Der Anbieter schuldet Aufwand und Sorgfalt, kein fertiges Werk. Genau diese rechtliche Unterscheidung ist das ganze Spiel, und sie ist der Grund, warum ein Statement of Work (ein Werkvertrag) ein grundlegend anderes Instrument ist, nicht nur ein anderer Abrechnungsstil.

Das Modell ist insofern ehrlich, als niemand vorgibt, der Anbieter würde das Ergebnis verantworten. Es ist auch das am schlechtesten ausgerichtete der gängigen Modelle: Der Anbieter hat ein Interesse, mehr Stunden abzurechnen, nicht schneller fertig zu werden. Kluge Kunden deckeln T&M-Engagements mit Budget-Cap und klarem Scope, was im Kern ein Fixpreis-Engagement ohne die juristischen Zähne ist.

Beispiel, wie T&M schiefgeht: Ein Founder unterschreibt einen „T&M, um flexibel zu bleiben"-Vertrag für ein Feature, auf das sich bereits alle geeinigt haben. Drei Monate und 40k später ist es zu 70 % fertig, die Agentur schlägt weitere sechs Wochen vor, und der Founder hat keinen vertraglichen Hebel, weil er nie eine Leistung benannt hat. Wäre dieselbe Arbeit als Werkvertrag gescoped gewesen, wäre das 70-Prozent-fertig-Problem auf Kosten des Anbieters zu lösen gewesen.

Wavect nutzt T&M für explorative Engagements, in denen der Scope tatsächlich noch nicht definierbar ist. Wir nutzen es nicht als Default. Der ehrliche Trade-off ist real: T&M ist wirklich das richtige Modell für offene Forschung oder unvorhersehbare Wartung, wo ein erzwungener Fixed Scope uns nur zum Aufpolstern der Schätzung oder zum Streit über „fertig" zwingen würde. Faustregel: Nutze T&M, wenn noch niemand die Leistung beschreiben kann, und wechsle zu einem Retainer oder einem SoW, sobald jemand es kann. Wer dich für Arbeit mit klarer Leistung zu T&M drängt, schiebt das Risiko auf dich.

Wann das im Softwareprojekt zählt. Immer dann, wenn ein Anbieter Stundenabrechnung für Arbeit vorschlägt, auf die sich bereits alle geeinigt haben. Genau da wandert das Lieferrisiko still vom Anbieter zu dir, und die meisten Founder merken es erst, wenn die Rechnung den Output überholt.

Was Founder meistens falsch machen. Sie wählen T&M „um flexibel zu bleiben" für ein Feature, das nie wirklich unsicher war. Drei Monate und eine fünfstellige Rechnung später ist es zu 70 Prozent fertig und sie haben keinen vertraglichen Hebel, weil sie nie eine Leistung benannt haben.

Wie Wavect damit umgeht. Wir nutzen T&M nur für wirklich offene Arbeit und deckeln es mit Budget-Cap und wöchentlichem Burn-down. Der Leitfaden Fixpreis vs Time & Material zeigt genau, wann welches Modell die ehrliche Wahl ist.

Ein Fixpreis-Engagement verschiebt das Lieferrisiko vom Kunden zum Anbieter. Der Preis steht vor Arbeitsbeginn fest. Der Scope ist schriftlich benannt. Die Frist ist Vertragsbestandteil. Wenn der Anbieter über Budget oder Zeit läuft, ist das Problem des Anbieters, nicht deines.

Damit das echt und kein Theater ist, muss der Vertrag ein Werkvertrag (AT/DE-Recht) oder das jeweils lokale Äquivalent sein. Ein Werkvertrag bindet den Anbieter rechtlich an die Lieferung der Arbeit, nicht nur an den Aufwand, und der Kunde kann die Zahlung zurückhalten, bis die Arbeit abgenommen ist. „Fixed Price" als mündliche Zusage über einem Time-&-Material-Vertrag ist kein Fixpreis; das ist ein Marketingsatz. Das zugrundeliegende SoW ist der Ort, an dem die Garantie tatsächlich lebt oder stirbt.

Beispiel: Ein Anbieter quotiert „rund 25k, fix", aber das SoW sagt „Zahlung monatlich gegen Stunden" und listet keine Akzeptanzkriterien. Das ist T&M mit Fixpreis-Hut. Die ehrliche Version benennt die Leistung („Checkout-Flow live, besteht Akzeptanztests A, B, C, bis Datum X"), nennt den Preis und legt das Überschreitungsrisiko auf den Anbieter. Wer das nicht aufschreibt, hat keinen Fixpreis.

Wavect arbeitet fixpreislich für Engagements mit gut definiertem Scope, bei denen die Discovery bereits stattgefunden hat. Für vor-Discovery-Arbeit führen wir zuerst eine 2- bis 3-wöchige Discovery-Phase durch, die selbst zum Fixpreis läuft. Die Kosten werden bei einem Folgeauftrag von der Build-Rechnung abgezogen.

Der ehrliche Trade-off und der häufigste Founder-Fehler: Fixpreis auf wirklich unsicheren Scope zu zwingen. Wenn die Unbekannten groß sind, polstert ein Fixpreis-Anbieter die Schätzung um 30 bis 100 % auf, um das Risiko zu absorbieren, oder unterbietet und schneidet dann an der Qualität, um im Budget zu bleiben. Keines dient dir. Mach zuerst Discovery, fixiere den Preis auf das, was du tatsächlich weißt, und halte die wirklich unbekannten Teile in einem anderen Modell. Wavects Fixpreis-Garantie bedeutet: unterzeichneter Werkvertrag, rechtlich an Lieferung gebunden. Sie bedeutet nicht Rückerstattung bei Fristüberschreitung.

Verwandt: Fractional CTO Österreich veröffentlicht Fixpreise pro Stufe.

Wann das im Softwareprojekt zählt. Wenn der Scope feststeht und du willst, dass das Lieferrisiko beim Anbieter liegt, nicht bei dir. Fixpreis ist nur ehrlich, nachdem die Unbekannten aufgelöst sind, meist über eine Discovery.

Was Founder meistens falsch machen. Sie zwingen Fixpreis auf wirklich unsicheren Scope, um das Budget zu deckeln. Der Anbieter polstert die Schätzung dann um 30 bis 100 Prozent auf, um das Risiko zu absorbieren, oder unterbietet und schneidet an der Qualität. Keines dient dir, und eine Fixpreis-Garantie ist die Verpflichtung, den unterzeichneten Scope zu liefern, kein Refund bei Fristverzug.

Wie Wavect damit umgeht. Wir fixieren den Preis nur auf das, was die Discovery tatsächlich festgezurrt hat, unterzeichnen einen Werkvertrag und legen das Überschreitungsrisiko auf uns. Der Leitfaden Fixpreis vs Time & Material zeigt, wann man einen Preis fixiert und wann man flexibel bleibt.

Ein Retainer ist ein Abo auf die Zeit des Anbieters. Du zahlst monatlich; im Gegenzug bekommst du eine definierte Zahl Tage oder eine definierte Team-Kapazität. Der konkrete Scope verschiebt sich; die Verfügbarkeit nicht.

Retainer funktionieren gut, wenn die Arbeit dauerhaft ist und Prioritäten sich zu schnell ändern, als dass ein Statement of Work mithalten könnte. Produktteams nutzen Retainer für Designpartner, Engineering-Teams für fractional Senior-Rollen, und fast jede juristische Beratung ist ein Retainer. In Österreich ist ein Retainer meist als Dienstvertrag oder freier Dienstvertrag strukturiert, weil du reservierte Verfügbarkeit und Urteilsvermögen kaufst statt eines fixen Werks.

Das Risiko ist die Umkehr von T&M: Der Anbieter wird bezahlt, auch wenn es nichts zu tun gibt. Kluge Kunden hängen eine „Reasonable Use"-Klausel an und reviewen den Retainer quartalsweise, um zu bestätigen, dass die Kapazität genutzt wird. Liegt die Auslastung unter 60 %, ist der Retainer die falsche Form und ein per-Engagement-SoW passt besser.

Beispiel: Ein Startup setzt einen Senior-Advisor „zur Sicherheit" auf einen 10-Tage-pro-Monat-Retainer. Zwei Monate lang ist er voll genutzt; dann shippt der Launch und die Arbeit fällt auf zwei Tage im Monat, die Rechnung aber nicht. Sie zahlen jetzt für acht Leerlauftage. Die Lösung ist nicht, die Beziehung zu kündigen, sondern sie richtig zu dimensionieren: auf einen kleineren Retainer runtergehen, plus die Option, einen Fixpreis-Build zu scopen, wenn eine echte Leistung auftaucht. Gesunde Retainer liegen bei 70 bis 85 % Auslastung; darunter kaufst du Versicherung, über 95 % fährst du den Anbieter als Personal ohne Spielraum für die Arbeit, die zählt.

Der ehrliche Trade-off ist Vorhersehbarkeit gegen Effizienz. Ein Retainer kauft dir bekannte Monatskosten und ein reserviertes Senior-Hirn, zum Preis, in den ruhigen Monaten für Kapazität zu zahlen. Verwandt: Fractional CTO Österreich läuft als wöchentlicher Retainer, den du jede Woche kündigen kannst, was den meisten Lock-in entfernt, der traditionelle Retainer riskant macht.

Discovery ist die Arbeit, die passieren muss, bevor ein Fixpreis-Build seriös quotiert werden kann. Sie produziert vier Artefakte: eine Software-Architektur, einen Milestone-Plan, die kritischen technischen Flows und einen Launch-Plan. Daraus kann der Anbieter einen echten Fixpreis quotieren und ein belastbares SoW schreiben.

Wavect betreibt Discovery als 2- bis 3-wöchiges Fixpreis-Engagement zu 3.500 EUR. Wenn du mit uns für den Build weitermachst, wird die Discovery-Gebühr von der ersten Rechnung abgezogen. Wenn nicht, behältst du alle vier Artefakte und kannst sie zu einem anderen Anbieter mitnehmen. Genau das ist der Test einer ehrlichen Discovery: Der Output sollte nützlich sein, selbst wenn du weggehst.

Beispiel, warum das zählt: Ein Founder sammelt drei „kostenlose" Angebote für dieselbe App und bekommt 30k, 70k und 110k. Die Spanne ist keine Anbietergier, sondern dass keiner die Arbeit tatsächlich gescoped hat, also hat jeder für ein anderes Set imaginierter Unbekannter aufgepolstert. Eine bezahlte Discovery kollabiert diese Spanne, indem sie Vermutungen durch eine Architektur und einen Milestone-Plan ersetzt, womit auch ein ehrlicher SDLC startet. Dieselben Artefakte lassen dich den Unterschied erkennen zwischen einem MVP, das du in acht Wochen shippen kannst, und einer Plattform, auf die du dich still für ein Jahr festlegst.

Der Grund, Discovery zu bepreisen: Kostenlose Scoping-Arbeit ist entweder unehrlich (der Anbieter holt sich die Kosten in der Build-Schätzung wieder) oder qualitativ schlecht (der Anbieter macht sie schnell, weil sie unbezahlt ist). Bepreisen behebt das Incentive. Der ehrliche Trade-off ist, dass sich Discovery anfühlt, als gäbe man Geld aus, bevor man etwas vorzuzeigen hat. Du hast etwas: Die vier Artefakte sind ein portables Asset, und die Alternative (sechsstellig in einen Build committen, den niemand gescoped hat) ist die teure Option, nicht die billige.

Verwandt: Fractional CTO Österreich listet Discovery als eine von vier Preisstufen.

Wann das im Softwareprojekt zählt. Bevor du ein Build-Budget auf etwas committest, das du noch nicht präzise beschreiben kannst. Discovery ist der billigste Ort, um herauszufinden, dass du gerade das Falsche bauen willst, denn jede übersprungene falsche Annahme wird in Code zementiert und später bezahlt.

Was Founder meistens falsch machen. Sie sammeln drei „kostenlose" Angebote, bekommen wild unterschiedliche Zahlen und halten die Spanne für Anbietergier. Die Spanne ist, dass niemand die Arbeit gescoped hat, also hat jeder für andere imaginierte Unbekannte aufgepolstert. Discovery zu überspringen, um Wochen zu sparen, kostet regelmäßig Monate an Rework.

Wie Wavect damit umgeht. Wir betreiben Discovery als kurzes Fixpreis-Engagement, das mit einer portablen Architektur, einem Milestone-Plan und quotierbarem Scope endet, nützlich selbst wenn du weggehst. Siehe was eine Discovery-Phase ist und wie man einen Tech-Stack für ein MVP wählt.

Sprint ist ein Scrum-spezifischer Begriff, der in den allgemeinen Sprachgebrauch übergegangen ist und jede kurze, zeitlich begrenzte Arbeitseinheit meint. Die ursprüngliche Definition verlangt drei Dinge: feste Länge, Planungssession am Anfang, Review am Ende. Die meisten Teams behalten die ersten zwei und lassen die dritte fallen, weswegen viele Teams ihre Kadenz „Sprints" nennen, aber kein vorzeigbares Inkrement produzieren. Ein Sprint ohne Demo ist nur eine Deadline; ein Sprint ohne Retro ist ein Laufband.

Die Dauer zählt. Einwöchige Sprints erzwingen engen Scope und decken Lieferprobleme schnell auf. Zweiwöchige Sprints bieten Platz für substanzielle Arbeit, absorbieren aber mehr Drift. Dreiwöchige Sprints werden meistens zu zwei schlecht geplanten.

Beispiel für das stille Versagen: Ein Team fährt sechs Monate lang zweiwöchige „Sprints", trifft jedes Planungsmeeting und shippt nichts, das ein Stakeholder anklicken kann. Der Beirat rutscht immer weiter, weil Arbeit nach Hoffnung geschätzt wird, nicht nach dem, was reinpasst, und es gibt kein Review, das das Team zwingt, sich einem lauffähigen Inkrement zu stellen. Die Lösung ist brutal und einfach: Am Ende jedes Sprints muss jemand außerhalb des Teams nutzen können, was gebaut wurde. Kann er das nicht, ist die Kadenz Theater, und das Schrumpfen auf einwöchige Sprints legt meist innerhalb von zwei Wochen offen, warum.

Der ehrliche Trade-off und der häufigste Founder-Fehler: Sprints als Weg zu behandeln, eine feste externe Deadline zu treffen. Die Kadenz ist darum gebaut, die Zeitbox zu fixieren und den Scope zu flexen, was das Gegenteil eines harten Launch-Termins mit fixem Scope ist. Für wirklich termingetriebene Arbeit mit fixem Scope willst du einen Fixpreis-Plan mit expliziten SDLC-Milestones, kein Sprint-Board. Sprints passen zu laufender Agile-Auslieferung und iterativer Arbeit Richtung MVP; zu Research- und Design-Arbeit passen sie schlecht, wo eine zeitlich begrenzte Exploration mit schriftlicher Zusammenfassung eine erzwungene Demo schlägt. Sie hängen außerdem von gesundem CI/CD ab, denn ein Sprint, der an seinem Ende nicht shippen kann, ist kein Sprint.

Wann das im Softwareprojekt zählt. Immer dann, wenn du laufende, iterative Auslieferung kaufst und in stetiger Kadenz lauffähige Software sehen willst statt einer großen Enthüllung am Ende.

Was Founder meistens falsch machen. Sie behandeln Sprints als Weg, einen fixen externen Launch-Termin zu treffen, was genau verkehrt ist: Die Kadenz fixiert die Zeitbox und flext den Scope. Sie lassen außerdem Demo und Retro fallen, bekommen also Planungsmeetings und shippen nichts, das ein Stakeholder anklicken kann.

Wie Wavect damit umgeht. Wir behalten Demo und Retro, und ein lauffähiges Inkrement, das jemand außerhalb des Teams nutzen kann, ist am Ende jedes Sprints die Messlatte. Für wirklich termingetriebene Arbeit mit fixem Scope planen wir stattdessen gegen explizite Milestones, wie in der QA-Checkliste vor dem Launch beschrieben.

Staff Augmentation ergänzt dein bestehendes Team um externe Entwickler. Sie sitzen in deinen Standups, arbeiten dein Backlog ab und folgen deinen Prozessen. Die Führung, die Architekturentscheidungen und die Verantwortung bleiben bei dir. Der Anbieter stellt Köpfe und rechnet nach Zeit ab. Das ist das ganze Modell.

Es passt, wenn du ein funktionierendes Team und einen funktionierenden Plan hast und schlicht für einen bekannten Arbeitsabschnitt mehr Hände an der Tastatur brauchst. Es passt nicht, wenn du noch nicht weißt, was gebaut werden soll, wenn intern niemand die neuen Entwickler steuern kann, oder wenn du jemanden brauchst, der ein Ergebnis verantwortet statt ein Ticket abzuarbeiten. Für Verantwortung willst du ein Dedicated Team oder eine fraktionale Senior-Rolle, nicht Augmentation.

Die Senioritätsfalle steht in keiner Broschüre. Die meisten Augmentation-Anbieter werben mit Senior-Profilen und besetzen dann mit Junioren, die genauso viel Anleitung brauchen wie deine eigenen Junioren, nur zahlst du jetzt Agentursätze dafür. Du trägst den Führungsaufwand, der Anbieter trägt kein Lieferrisiko. Lies die namentlichen CVs, interviewe die echte Person und schreib eine Austausch-Klausel in den Vertrag.

Es gibt eine österreichische Rechtsfeinheit, die erwähnenswert ist: Staff Augmentation kann in Arbeitskräfteüberlassung übergehen, ein regulierter Rahmen mit eigenen Pflichten dazu, wer den Arbeitenden anweist und wie er behandelt wird. Wenn ein „augmentierter" Entwickler über einen längeren Zeitraum vollständig unter deiner Anweisung eingebunden ist, kann das Verhältnis rechtlich eher wie überlassene Arbeitskraft aussehen als wie ein Werk- oder Dienstvertrag, mit Folgen für beide Seiten. Bei kurzen, klar umrissenen Einsätzen ist das selten ein Problem, aber es lohnt sich, die Vertragsform von vornherein richtig zu setzen, statt die Einordnung erst bei einer Prüfung zu entdecken.

Wavect betreibt keine Body-Shop-Vermietung. Wir sind ausschließlich Senior-Operatoren; wenn wir in deinem Team sitzen, macht die Arbeit die Person von der Softwareentwicklung-Seite, kein Name auf einer Liste, der in Woche drei still ausgetauscht wird.

Wann das im Softwareprojekt zählt. Wenn du bereits ein funktionierendes Team und einen funktionierenden Plan hast und schlicht mehr Hände für einen bekannten Arbeitsabschnitt brauchst. Du behältst Management, Architektur und Verantwortung; der Anbieter liefert Personen.

Was Founder meistens falsch machen. Sie kaufen beworbene Senior-Profile und bekommen Juniors, die dasselbe Hand-Holding brauchen wie die eigenen, nur zu Agentursätzen, während der Anbieter kein Lieferrisiko trägt. Sie greifen außerdem zu Augmentation, wenn niemand intern die neuen Engineers überhaupt anleiten kann.

Wie Wavect damit umgeht. Wir besetzen ausschließlich Senior, kein stiller Austausch in Woche drei. Wenn du ein verantwortetes Ergebnis brauchst statt abgearbeiteter Tickets, sagen wir das. Die Leitfäden zur Wahl einer Softwareagentur und Freelancer vs Agentur vs Inhouse helfen, das richtige Modell zu wählen.

Technical Due Diligence ist das, was ein seriöser Investor oder Käufer beauftragt, bevor Geld den Besitzer wechselt. Sie beantwortet eine direkte Frage: trägt die Technologie die Bewertung wirklich, oder ist die Story besser als die Codebasis. Eine saubere Prüfung umfasst Codequalität und Wartbarkeit, die Architektur und ob sie über die nächste Größenordnung hinaus skaliert, die Security-Lage, den Zustand von Testsuite und Delivery-Pipeline, die echte Tiefe des Teams und das Key-Person-Risiko, das im Kopf einer einzelnen Gründerin steckt.

Für die Käuferseite ist Tech DD Risikobewertung. Du suchst keinen perfekten Code; jedes Unternehmen in dieser Phase hat Schulden. Du suchst die Lücke zwischen dem, was das Deck behauptet, und dem, was das Repository zeigt, und die Tretminen, die nach dem Closing zu Notfällen werden: ein einzelner Entwickler, der weiß, wie alles funktioniert, eine Lizenz, die ein kommerzielles Produkt vergiftet, ein Compliance-Loch, eine Architektur, die das Wachstum nicht überlebt, für das du zahlst.

Für die Verkäuferseite ist eine eigene Tech DD, bevor der Raum sie für dich macht, eine der günstigsten Möglichkeiten, eine Bewertung zu schützen. Überraschungen während der Diligence kosten dich Verhandlungsmacht; Befunde, die du bereits verstanden und für die du einen Plan hast, nicht. Gründer mit einer vorbeugenden Prüfung gehen mit Antworten in den Datenraum statt mit Erklärungen.

Wavect führt Technical Due Diligence als Senior-Operator durch, nicht als Checklisten-Prüfer. Wir haben sie auf beiden Seiten des Tisches gemacht, auch bei datenlastigen und regulierten Plattformen, und schreiben Befunde, mit denen ein nicht-technisches Board handeln kann. Das passt natürlich zu unserer Fractional Co-Founder-Arbeit, bei der dieselbe Person, die das Risiko bewertet, auch beim Beheben helfen kann.

Wann das im Softwareprojekt zählt. Bevor Geld den Besitzer wechselt, auf beiden Seiten einer Runde oder Übernahme. Die eine blunte Frage ist, ob die Technologie die Bewertung tatsächlich trägt oder die Story besser ist als die Codebasis.

Was Founder meistens falsch machen. Auf der Verkaufsseite betreten sie den Datenraum mit Erklärungen statt Antworten. Ein Befund, den der Käufer aufdeckt, ein undokumentiertes Modul eines einzelnen Engineers, eine Lizenz, die ein kommerzielles Produkt vergiftet, kostet echtes Geld am Term Sheet; derselbe Befund, den du zuerst aufgedeckt hast, kostet nichts.

Wie Wavect damit umgeht. Wir prüfen als Senior-Operatoren, nicht als Checklisten-Prüfer, und schreiben Befunde, mit denen ein nicht-technisches Board handeln kann. Dieselbe Schärfe treibt unsere bezahlte Discovery, daher ist der Leitfaden zur Wahl einer Softwareagentur ein nützlicher Einstieg ins Beurteilen der echten Tiefe eines Build-Teams.

Ein Proof of Concept existiert, um genau ein technisches Risiko auszuräumen. Schafft dieses Modell die nötige Latenz. Funktioniert diese Integration wirklich gegen das Altsystem. Können wir die Kryptografie beweisen, bevor wir ein Produkt darum herum entwerfen. Ein PoC beantwortet „ist das möglich" und sonst nichts. Er wird schnell gebaut, danach beurteilt, ob er funktioniert, und dann weggeworfen.

Die Unterscheidung, die Unternehmen am meisten kostet, ist PoC gegen MVP gegen Prototyp. Ein PoC beantwortet „ist das technisch möglich" und richtet sich an dein eigenes Team. Ein Prototyp beantwortet „fühlt sich das richtig an" und richtet sich an Design und Usability, oft ganz ohne echtes Backend. Ein MVP beantwortet „wird das wirklich jemand nutzen und dafür zahlen" und ist ein echtes Produkt, ausgespielt an echte Nutzer, nur auf die kleinste lohnende Version zugeschnitten. Sie haben unterschiedliche Zielgruppen, unterschiedliche Qualitätsmaßstäbe und unterschiedliche Definitionen von „fertig".

Der häufige und teure Fehler ist, einen PoC auszuspielen, als wäre er Produktion. Der Code, der bewiesen hat, dass etwas möglich ist, wurde geschrieben, um zu beweisen, dass etwas möglich ist: keine Fehlerbehandlung, keine Tests, kein Security-Review, überall Abkürzungen. Wenn der Demo jemanden beeindruckt und entschieden wird, „das einfach auszuliefern", erbst du all das als dein Fundament. Der ehrliche Zug ist, den PoC als Antwort auf eine Frage zu behandeln und dann das echte Ding sauber zu bauen.

Ein Weg, diese Disziplin unter Druck zu halten: Schreib die eine Frage auf, die der PoC beantworten soll, bevor du startest, samt Kriterien für ein Ja oder Nein. „Kann dieses Modell Support-Tickets mit 90% Genauigkeit auf unseren letzten 500 Tickets klassifizieren" ist eine Frage mit klarem Urteil. Ohne diese aufgeschriebene Frage mutiert ein PoC still zum Halbprodukt, das Team poliert weiter, weil er „fast funktioniert", und du bist ins Bauen einer V1 auf Wegwerf-Fundamenten gerutscht, ohne dass es jemand entschieden hätte. Die aufgeschriebene Frage schützt dich auch vor dem Sunk-Cost-Sog, den Wegwerf-Code doch auszuliefern: Ist die Frage beantwortet, hat der PoC seine Aufgabe erfüllt und seine Löschung verdient, egal wie schön der Demo aussah.

Wavect baut einen PoC, wenn es ein echtes technisches Risiko gibt, das sich vor der Festlegung auf einen Build auszuräumen lohnt. Die meisten Projekte brauchen keinen; sie brauchen eine Discovery-Phase, die die Arbeit scoped. Wir sagen dir, welcher Fall vorliegt.

Ein Dedicated Team ist ein externer Trupp, der deinem Produkt zugeordnet ist, mit eigenem technischem Lead, und einen Workstream von der Planung bis zur Lieferung verantwortet. Anders als bei Staff Augmentation führst du nicht einzelne Entwickler Ticket für Ticket. Du gibst Richtung und Prioritäten vor; der Lead des Teams übernimmt die tägliche Umsetzung, die interne Koordination und die Lieferung. Der Anbieter verantwortet das Ergebnis, nicht nur die Zeit auf dem Weg dorthin.

Es passt, wenn du ein ganzes Problem abgeben willst statt eine Lücke zu füllen: eine Produktlinie, eine Plattform, einen Workstream, der mit einer klaren Schnittstelle zum Rest deiner Organisation laufen kann. Es passt, wenn du nicht die interne Führungskapazität hast, einzelne Auftragnehmer zu steuern, weil das Team sich selbst managt. Es passt nicht, wenn die Arbeit tief mit den täglichen Entscheidungen deines bestehenden Teams verflochten ist; genau für diese Verflechtung gibt es Staff Augmentation.

Der ehrliche Trade-off ist die Schnittstelle. Ein Dedicated Team senkt deinen Führungsaufwand pro Entwickler, führt aber eine Koordinationsgrenze zwischen zwei Gruppen ein, die an einem Produkt arbeiten. Diese Grenze kostet dich immer dann, wenn Prioritäten schnell wechseln oder Kontext ständig hin und her fließen muss. Die Teams, bei denen das gut funktioniert, investieren in einen einzigen klaren Ansprechpartner, eine gemeinsame Definition von „fertig" und genug überlappende Stunden, um die Grenze dünn zu halten.

Der Failure-Mode, auf den du achten musst, ist das Dedicated Team, das nur dem Namen nach dediziert ist und still über drei andere Kunden zeitgeteilt wird. Du zahlst für reservierte Kapazität und ein verantwortetes Ergebnis; wenn dieselben Entwickler zwischen deinem Produkt und zwei weiteren kontextwechseln, bekommst du weder die Verantwortung noch den Fokus, nur Augmentation mit Aufschlag. Frag, wer konkret im Team ist, ob sie Vollzeit auf deinem Workstream sind und was mit der Kontinuität passiert, wenn einer von ihnen abgezogen wird. Ein echtes Dedicated Team hat stabile Besetzung und einen benannten Lead, der den Kontext trägt; ein falsches hat eine rotierende Besetzung und einen Projektmanager, der deine Nachrichten weiterleitet.

Wavect hält Teams klein und senior, sodass das Team, das deinen Workstream verantwortet, aus Operatoren besteht, die Entscheidungen treffen, nicht aus einer Schicht Junioren mit einem Projektmanager davor. Siehe die Softwareentwicklung-Seite dazu, wie wir Delivery strukturieren.

Nearshoring heißt, Entwicklung an einen Anbieter in einem nahen Land auszulagern, meist innerhalb einiger weniger Zeitzonen. Für DACH-Unternehmen bedeutet das typischerweise Osteuropa statt Süd- oder Südostasien. Onshore ist ein Anbieter im eigenen Land zu den eigenen Sätzen. Offshore ist das ferne Ende: niedrigste Tagessätze, größter Zeitzonen-Abstand, längste Kommunikationskette. Nearshore liegt in der Mitte und wird als der Sweet Spot verkauft: günstiger als onshore, einfacher zusammenzuarbeiten als offshore.

Die beworbene Zahl ist der Tagessatz, und beim Tagessatz gewinnt Nearshore. Die Zahl, die niemand ins Angebot schreibt, ist die Koordinationssteuer: die Stunden, die an einer Zeitzonen-Überlappung verloren gehen, die kürzer ist als sie aussieht, die Nacharbeit durch Spezifikationen, die über eine Sprach- und Kulturlücke schlecht reisen, die Senior-Zeit auf deiner Seite für Review, Korrektur und erneutes Erklären. Ein günstigerer Entwickler, der doppelt so viel Anleitung braucht und Arbeit liefert, die du neu machen musst, ist nicht günstiger. Die Billig-Tarif-Rechnung bricht in dem Moment, in dem die Arbeit enge Zusammenarbeit braucht statt gut spezifizierter, in sich geschlossener Aufgaben.

Nearshore kann die richtige Wahl sein. Für klar abgegrenzte, sauber spezifizierte Arbeit mit stabilen Anforderungen und einer dünnen Schnittstelle zu deinem Team ist die Tarifersparnis real und die Koordinationssteuer klein. Sie bricht zusammen bei mehrdeutiger, schnell wechselnder oder tief kollaborativer Arbeit, also genau bei der Arbeit, die die meisten Frühphasen- und produktgetriebenen Unternehmen tatsächlich machen. Sei ehrlich, welche Art du hast, bevor du auf den Tagessatz optimierst.

Wavect ist eine DACH-Beratung: gleiche Zeitzone, gleiche Sprache für die Gespräche, auf die es ankommt, Senior-Leute, die einmal Anleitung brauchen statt dreimal. Wenn du uns gegen den Nearshore-Tarif vergleichst, vergleiche die All-in-Kosten inklusive Koordinationssteuer, nicht die Zeile auf der Rechnung. Siehe Softwareentwicklung dazu, wie wir arbeiten.

Web3 bezeichnet eine Familie von Technologien, keine einzelne Sache. Gemeinsam ist: Nutzer-State (Assets, Identität, manchmal Daten) liegt auf einer öffentlichen Blockchain statt in einer zentralen Datenbank. Der Nutzer signiert Transaktionen mit einem Private Key, den er selbst hält. Der Anbieter kann seinen Account weder einfrieren noch löschen.

Praktisch deckt der Begriff Wallets, Smart Contracts, dezentrale Exchanges, NFTs, DAOs, Account Abstraction, ZK-basierte Systeme, Cross-Chain-Bridges und die Anwendungsschicht über all dem ab. Wavect baut in diesem Feld über EVM (Ethereum und kompatible Chains), Solana, Cosmos, Polkadot, Near, Ton und ICP.

Beispiel für die Entscheidung: Ein Founder will eine Loyalty-Points-App, und ein Pitch Deck sagte ihm, sie „on-chain" zu legen. Wende drei Tests an. Müssen die Punkte die Insolvenz der Firma überleben? Müssen mehrere Parteien, die einander nicht vertrauen, das Register ohne zentralen Operator teilen? Brauchen sie erlaubnisfreie Komponierbarkeit mit anderen On-Chain-Systemen? Für ein Single-Company-Loyalty-Schema lautet die Antwort nein, nein und nein, also ist das richtige Werkzeug eine Datenbank, und es auf eine Blockchain zu legen, addiert nur Gas-Kosten, Key-Management-Support-Tickets und einen regulatorischen Kopfschmerz. Dreh eine Antwort auf ja (etwa Punkte, einlösbar über konkurrierende Händler hinweg), und die Rechnung ändert sich.

Die österreichische und EU-Nuance, die Founder unterschätzen: Ein Token, der wie ein Zahlungsinstrument oder ein Wertpapier aussieht, zieht MiCA, Prospektpflichten und steuerliche Behandlung in den Scope. „Dezentral" befreit dich nicht, und die rechtlichen Kosten einer falschen Token-Klassifikation überwiegen die Engineering-Kosten des Contracts bei weitem. Scope das, bevor du den Smart Contract schreibst, nicht danach.

Die ehrliche Version: Die meisten Web3-Projekte brauchen keine Blockchain. Diejenigen, die sie brauchen (Assets, die die Insolvenz des Anbieters überleben müssen; Multi-Party-Vertrauen ohne zentralen Operator; erlaubnisfreie Komponierbarkeit), sind wertvoll. Der Rest sind VC-finanzierte Ablenkungen. Der Trade-off ist, dass Permanenz in beide Richtungen schneidet: Dieselbe Unveränderlichkeit, die Web3 vertrauenswürdig macht, bedeutet, dass ein geshippter Bug ein Bug für immer ist und ab Minute eins Werte auf dem Spiel stehen. Wir sagen dir, in welche Kategorie du fällst.

Ein Zero-Knowledge-Beweis erlaubt einer Partei (dem Prover), eine andere Partei (den Verifier) davon zu überzeugen, dass sie eine Information besitzt, ohne die Information selbst zu offenbaren. Klassisches Beispiel: nachweisen, dass man über 18 ist, ohne das Geburtsdatum zu nennen.

In Produktion erscheinen ZK-Verfahren in zwei Ausprägungen. ZK-SNARKs sind kleiner und schneller verifizierbar, brauchen aber ein Trusted Setup. ZK-STARKs sind größer und langsamer, benötigen kein Trusted Setup und sind post-quanten-sicher. Die meisten Chains bieten inzwischen fertige Circuits für gängige Beweise (Identität, Saldo, Wahlberechtigung) an, sodass kein Kryptograph im Haus nötig ist, um einen Smart Contract zu shippen, der sie verifiziert.

Beispiel, wo ZK sich verdient: Eine regulierte Exchange muss einem Prüfer beweisen, dass jeder Nutzer KYC bestanden hat, ohne dem Prüfer eine Datenbank aus Namen und Passnummern auszuhändigen. Ein Zero-Knowledge-Beweis lässt die Exchange bezeugen „diese Menge an Accounts ist vollständig KYC-verifiziert", während die zugrundeliegenden Identitäten privat bleiben. In der EU, wo die DSGVO diese Passdatenbank zu einer Haftung macht, die man lieber nicht hält, ist die Privatsphäre kein Nice-to-have, sondern der Punkt. Das Gegenbeispiel ist genauso lehrreich: Würde eine vertrauenswürdige Datenbankabfrage den Verifier zufriedenstellen, ist ZK teures Theater.

Der ehrliche Engineering-Trade-off und der häufigste Founder-Fehler: anzunehmen, der schwere Teil sei die Kryptografie. Die Mathematik ist solide. Das Risiko liegt im Circuit. Ein subtil falscher Circuit produziert einen Beweis, der perfekt verifiziert, während er die falsche Aussage beweist, und dieser Bug ist unsichtbar, bis ihn jemand ausnutzt. Deshalb gehört ZK-Arbeit in die Nähe von Account Abstraction und anderen On-Chain-Primitiven, bei denen Audits nicht verhandelbar sind, nicht als Marketing-Feature drangeschraubt. Der Business Case ist enger als der Hype: ZK ist tatsächlich wertvoll, wenn man on-chain (oder gegenüber einer Gegenpartei) eine Eigenschaft beweisen muss, ohne die Daten zu leaken. Für die meisten Consumer-Apps und die meisten Web3-Projekte, die es als Schlagwort nennen, ist es Overkill.

In einer Standard-EVM-Chain ist jedes Konto entweder ein Externally Owned Account (ein Private Key) oder ein Smart Contract. ERC-4337 führt eine dritte Klasse ein: ein Smart-Contract-Konto, mit dem der Nutzer als Sender auftritt. Weil das Konto ein Contract ist, kann es Logik enthalten. Diese Logik kann Gas sponsern, bei verlorenem Key über Guardians wiederherstellen, mehrere Calls in eine Transaktion bündeln oder eigene Auth-Regeln wie ein Tageslimit durchsetzen.

Die UX-Konsequenzen sind groß. Mit AA kann ein Endnutzer sich per E-Mail und Passkey statt per Seed Phrase einloggen. Gas-Gebühren können von der Anwendung oder im App-Token bezahlt werden statt in ETH. Die Wallet kann verdächtige Transaktionen ratebegrenzen. Der Trade-off: erhöhte On-Chain-Komplexität und höhere Gas-Kosten pro Transaktion.

Beispiel: Eine Consumer-Payments-App will nicht-krypto-native Nutzer. Ohne AA heißt Onboarding „schreib dir diese zwölf Wörter auf, verlier sie und dein Geld ist für immer weg", was den Funnel killt. Mit AA meldet sich der Nutzer per Passkey an, die App sponsert die ersten Transaktionen, sodass er nie eine Gas-Gebühr sieht, und ein verlorenes Gerät stellt sich über Guardians wieder her statt über eine Seed Phrase. Dasselbe Pattern lässt die Wallet ein Tages-Ausgabenlimit on-chain durchsetzen, was die Art Garantie ist, die eine zentralisierte App nie glaubwürdig geben könnte.

Der häufige Founder-Fehler ist, AA als Checkbox zu behandeln. Es ändert das Sicherheitsmodell: Social Recovery entfernt die Seed-Phrase-Falle für normale Nutzer, führt aber Guardian-Kompromittierung als neue Angriffsklasse ein, was für Power-User, die lieber selbst den Key halten, strikt schlechter ist. Der ehrliche Trade-off ist, dass AA Mainstream-UX kauft, zum Preis von mehr zu auditierendem Contract-Code und mehr Gas pro Aktion. Wavect hat Account-Abstraction-Wallets und Snaps (MetaMask-Plugins) in Produktion ausgeliefert. Die Technologie ist real und zunehmend Mainstream. Die Implementierung ist nicht trivial. Wenn ein Anbieter AA als günstiges Add-on quotiert, frag, welche Infrastruktur eingesetzt wird und welche Security-Audits der Contract-Code durchlaufen hat. Dieselbe Audit-Disziplin, die für Zero-Knowledge-Circuits gilt, gilt auch hier.

Ein AI Agent ist die Schleife, nicht das Modell. Das Modell (Claude, GPT, Gemini, ein Open-Weights-LLM) ist der Entscheider. Der Agent ist die Runtime: Er gibt dem Modell ein Ziel, lässt es Tools (Datenbank, API, Code-Interpreter, anderer Agent) aufrufen, oft über MCP, beobachtet das Ergebnis und füttert die Schleife, bis fertig.

Die Unterscheidung zählt, weil agentische Systeme anders versagen als reine LLM-Anwendungen. Ein Chatbot, der irrt, ist ein Nutzer, der weiterzieht. Ein Agent, der irrt, schickt eine E-Mail, führt eine Transaktion durch oder löscht eine Datei. Production-Agents brauchen Authorisierungs-Gates, Observability und Circuit Breakers, die die meisten Prototypen weglassen.

Beispiel für das häufigste Production-Versagen: Ein Support-Agent bekommt ein „Ticket lösen"-Ziel und ein Set an Tools. Ein fehlerhaftes Ticket schickt ihn in eine Schleife, in der er dasselbe Lookup-Tool dutzende Male aufruft, an einem Nachmittag das Modellbudget verbrennt und nie zu einer Lösung kommt. Die Lösung ist kein klügerer Prompt, sondern Engineering: ein hartes Step-Limit, eine Kostendecke und ein Circuit Breaker, der die Schleife stoppt und an einen Menschen eskaliert. Alles, was schreibt (eine Nachricht sendet, eine Zahlung tätigt, einen Datensatz löscht), bekommt ein Human-in-the-Loop-Gate; reine Read-only-Schleifen können meist unbeaufsichtigt laufen.

Der ehrliche Trade-off und der zu vermeidende Founder-Fehler: Agents addieren Nicht-Determinismus, Latenz und einen weit größeren Blast Radius als eine feste Pipeline, im Tausch dafür, Aufgaben zu bewältigen, deren Schritte sich nicht vorab aufzählen lassen. Die meisten als „agentisch" gepitchten Workflows sind gut verstanden und besser in einer deterministischen Pipeline mit einem oder zwei LLM-Calls in der Mitte aufgehoben, oft gestützt durch RAG zur Erdung. Wavects Haltung: zuerst fragen, ob KI hier das richtige Werkzeug ist, dann, ob ein Agent die richtige Form von KI dafür ist. Wenn du die Schritte aufschreiben kannst, lass das Modell sie nicht improvisieren.

Model Context Protocol (MCP) ist für AI Agents das, was HTTP für das Web ist: ein gemeinsamer, offener Standard dafür, wie das Modell mit dem Rest der Welt spricht. Anthropic hat es Ende 2024 eingeführt; 2025 und 2026 wurde es breit adoptiert.

Die technische Form: Ein MCP-Server stellt Resources, Tools und Prompts über ein definiertes Schema bereit. Jeder MCP-fähige Client (Claude Desktop, Claude Code, die API, ein IDE-Plugin) kann diese Tools entdecken und aufrufen, ohne pro Anbieter Klebstoff zu schreiben. Integration einmal bauen, jeder MCP-Client profitiert.

Beispiel für den Hebel: Eine Firma verpackt ihr internes CRM, ihr Analytics-Warehouse und ihren Dokumentenspeicher als drei MCP-Server. Dieses Quartal ist das Team auf Claude; nächstes Quartal testet es aus Kostengründen ein anderes Modell. Mit Function-Calling, das an einen Anbieter gebunden ist, bedeutet dieser Wechsel, jede Integration neu zu schreiben. Mit MCP zeigt es den neuen Client auf dieselben drei Server und macht weiter. Die Integrationskosten wurden einmal gezahlt, nicht pro Modell. Diese Server mit RAG über den Dokumentenspeicher zu paaren, liefert geerdete Antworten aus internen Daten ohne maßgeschneiderte Verrohrung.

Der ehrliche Trade-off und der Founder-Fehler: MCP ist nur dann die richtige Wahl, wenn du erwartest, Modelle zu wechseln, oder Portabilität willst; bist du dauerhaft bei einem Anbieter, ist schlichtes Function-Calling einfacher und in Ordnung. Das größere Risiko ist Sicherheit. MCP ist ein Transportprotokoll, kein Berechtigungsmodell. Ein schlampiger MCP-Server, der ein schreibfähiges Tool mit schwacher Auth exponiert, ist ein wartender Confused-Deputy-Fehler, bei dem das Modell dazu verleitet wird, etwas aufzurufen, das es nicht sollte. Wir bauen MCP-Server regelmäßig und haben sie in Produktion ausgeliefert; wir schreiben außerdem für jeden ein Security-Review, weil der Standard sich noch bewegt und der Fehlerfall deine internen Systeme sind, nicht ein Chatbot, der etwas Dummes sagt. Wir verpacken ein Tool nur dann in MCP, wenn es innerhalb einer Modell-Schleife wirklich nützlich ist und das Sicherheitsmodell den Aufruf durch ein Modell erlaubt, mit Human-in-the-Loop bei allem Destruktiven.

RAG ist die Architektur, die einem LLM erlaubt, Fragen zu Daten zu beantworten, auf denen es nie trainiert wurde. Die Mechanik ist geradlinig: Frage des Nutzers nehmen, die relevantesten Chunks aus deinem Korpus per Vector-Search, Keyword-Search oder Hybrid abrufen, in den Prompt packen, das Modell antworten lassen. Es ist die Erdungsschicht unter den meisten nützlichen AI Agents.

Der Grund, warum RAG existiert: Ein Modell auf privaten Daten zu trainieren ist teuer, langsam und veraltet, sobald die Daten sich ändern. RAG umgeht das, indem es die Daten als Laufzeit-Kontext behandelt. Der Trade-off: Retrieval-Qualität wird der Engpass. Ein Modell mit schlechtem Kontext produziert selbstbewusst falsche Antworten.

Beispiel für das klassische Versagen: Eine Firma baut einen Support-Bot über ihre Hilfe-Docs, die Demo ist beeindruckend, und dann zitiert er in Produktion selbstbewusst die falsche Rückerstattungsrichtlinie. Der Instinkt ist, das Modell zu beschuldigen und ein größeres zu versuchen. Die Antworten bleiben falsch, weil das Problem upstream liegt: Die Docs wurden mitten im Satz gechunkt, die Embeddings können „Rückerstattung" nicht von „Rückgabe" unterscheiden, und es gibt keinen Reranker, der die richtige Passage nach oben schiebt. Tausch besseres Chunking, Hybrid Search und einen Reranker ein, und dasselbe Modell wirkt plötzlich klug. Die Lehre verallgemeinert: Wenn RAG falsch liegt, verdächtige fast immer das Retrieval vor der Generierung.

Der ehrliche Trade-off und wo RAG zusammenbricht: Es glänzt bei lookup-förmigen Fragen, die aus wenigen Passagen beantwortbar sind, und verschlechtert sich, wenn die Antwort eine Synthese über viele Dokumente verlangt oder Widersprüche im Korpus auflösen muss. An diesem Punkt willst du einen kleineren kuratierten Korpus, eine agentische Pipeline, die in Schritten denkt, oder Fine-Tuning, keinen größeren Retriever. Die unsexy Wahrheit ist, dass 80 % der Arbeit gutes Retrieval ist (Chunking, Embeddings, Reranking, Hybrid Search) und 20 % das Modell. Deine Datenquellen als MCP-Server zu verpacken, macht die Retrieval-Schicht portabel, aber nicht gut. Anbieter, die RAG als Ein-Klick-Feature pitchen, pitchen den einfachen Teil.

Ein Smart Contract ist ein Programm, das auf eine Blockchain deployed wird. Nach Deployment ist sein Bytecode unveränderlich, sein State öffentlich lesbar, seine Ausführung wird von Konsens-Regeln gesteuert, die niemand überschreiben kann. Diese Permanenz ist Feature und Risiko: Ein Bug in Produktion ist ein Bug für immer, sofern keine Upgrade-Mechanik eingebaut wurde (die selbst eine Angriffsfläche ist).

Die meisten Production-Smart-Contract-Systeme sind kein einzelner Contract, sondern eine Reihe: ein Proxy für Upgradeability, ein Implementation-Contract für die Logik, oft ein Access-Control-Contract für Governance. Das Pattern kennt jeder, der versionierte APIs gebaut hat; die Kosten beim Fehler sind höher.

Beispiel, warum sich die Deployment-Disziplin von normaler Software unterscheidet: Ship einen Bug in einem SaaS-Backend, und du patchst und redeployst in einer Stunde. Ship einen Reentrancy-Bug in einem Contract, der Nutzergelder hält, und ein Angreifer kann ihn leeren, bevor du reagieren kannst, weil es kein Rollback gibt und der Wert ab Block eins live ist. Deshalb lautet die Frage nicht „sollen wir auditieren", sondern „wie strukturieren wir Upgrades sicher". Die übliche Antwort ist ein Proxy-Pattern hinter einem Timelock und einem Multisig: Sofortige Upgrade-Autorität ist ein Single Point of Failure, kein Upgrade-Pfad lässt dich mit dem ersten Bug festsitzen, und timelocked, für Nutzer transparente Upgrades sind der Mittelweg, auf den die meisten Production-Systeme konvergieren.

Der ehrliche Trade-off und der häufige Founder-Fehler: Founder behandeln den Contract wie ein Feature und das Audit wie einen optionalen Posten. Für jeden Contract, der nicht-triviale Werte hält, ist das Audit die billigste Versicherung, die du je kaufst, meist 1 bis 2 Wochen des Build-Budgets gegen den gesamten Wert, der auf dem Spiel steht. Wavect schreibt Smart Contracts in Solidity für EVM-Chains und Rust für Solana, Near und ICP, und die Sprache ist downstream davon, welche Chain dein Web3-Use-Case verlangt, keine Präferenz. Wir empfehlen ein Drittanbieter-Audit vor Mainnet bei allem, was zählt, und wir haben auditierte Contracts in Produktion ausgeliefert. Das Audit zu überspringen ist die Art, wie Teams das auf die teure Weise lernen.

Die EVM ist die Execution-Layer, die Ethereum erfunden hat und die zum De-facto-Standard für Smart-Contract-Chains wurde. Ein zu EVM-Bytecode kompilierter Contract läuft auf Ethereum Mainnet, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche C-Chain und einer langen Reihe von L2s und Sidechains.

Praktisch heißt das: Contracts in Solidity (oder Vyper) schreiben, auf Ethereum-Testnets testen und auf jene EVM-Chain deployen, die deine Kosten- und Latency-Anforderung trifft. Die Portabilität ist real. Die Trade-offs zwischen Chains liegen in Geschwindigkeit, Finalität, Dezentralisierung und im verwendeten L2-Framework.

Beispiel für die Chain-Wahl: Ein DeFi-Protokoll, das mit bestehenden Lending- und DEX-Contracts komponieren muss, gehört auf Ethereum Mainnet oder einen großen L2, wo dieses Ökosystem lebt, selbst bei höherem Gas. Eine High-Volume-Consumer-App, deren Nutzer dollargroße Gebühren nicht tolerieren, gehört auf einen L2 wie Arbitrum, Optimism oder Base (gleiches Sicherheitsmodell, ein Zehntel bis ein Hundertstel der Kosten) oder ganz weg von der EVM Richtung Solana. Die Entscheidung ist der Sicherheits-gegen-Kosten-Trade-off, nicht die Chain mit dem lautesten Marketing in diesem Quartal.

Der ehrliche Trade-off und der Fehler, der Teams immer wieder erwischt: EVM-kompatibel ist nicht dasselbe wie Ethereum-äquivalent. Subtile Unterschiede in Gas-Pricing, Precompiles, Opcode-Unterstützung und Konsensverhalten bedeuten, dass ein Contract, der auf Mainnet besteht, auf einer Sidechain brechen kann. Die Portabilität ist ein Startpunkt, keine Garantie; immer pro Chain neu testen, bevor du deployst. Account-Level-UX-Features wie Account Abstraction variieren auch in der Reife über Chains hinweg, also bestätige die Unterstützung, bevor du sie versprichst.

Der tiefere Trade-off ist, was du für günstige Gebühren aufgibst. Weg von Mainnet auf eine günstigere EVM-Chain zu ziehen heißt fast immer, ein anderes Vertrauensmodell zu erben: Eine Sidechain wie Polygon PoS betreibt ihr eigenes Validator-Set, statt Ethereums Sicherheit zu borgen, und ein Rollup addiert einen Sequencer, von dem du nun abhängst, sowie eine Withdrawal-Verzögerung zurück zu L1. Nichts davon taucht im Gas-Gebühren-Vergleich auf, den ein Anbieter ins Deck setzt. Entscheide, was deine Anwendung tatsächlich garantieren muss, bevor du auf die Kosten pro Transaktion optimierst. Für Web3-Builds bevorzugen wir Solidity vor Vyper wegen des breiteren Toolings und der Auditor-Vertrautheit, sofern es keinen starken Grund gibt, gegen den Strom zu schwimmen.

Solana ist nicht EVM-kompatibel. Smart Contracts (auf Solana „Programs" genannt) werden in Rust geschrieben, als BPF-Bytecode deployed und von der Solana-Runtime ausgeführt. Die Architektur optimiert auf Durchsatz (Tausende TPS) und niedrige Gebühren, zum Preis höherer Hardware-Anforderungen für Validatoren und eines anderen (manche sagen zentralisierteren) Dezentralisierungs-Profils.

Für Consumer-Anwendungen, bei denen der Nutzer sub-Cent-Gebühren zahlt und Bestätigung im Sub-Sekunden-Bereich liegt, ist Solana schwer zu schlagen. Für tiefe DeFi-Komposabilität mit dem EVM-Ökosystem ist die Brücke nicht trivial. Die richtige Chain hängt davon ab, welcher Trade-off für dein Produkt wichtiger ist.

Beispiel für den Stolperstein, der EVM-Teams beißt: Solanas Programmiermodell ist account-basiert, nicht contract-state-basiert. Du übergibst jeden Account, den eine Transaktion berührt, explizit, du verwaltest Rent auf Accounts, und du denkst von Anfang an über parallele Ausführung nach. Ein in Solidity flüssiges Team unterschätzt diesen Einstieg regelmäßig, shippt Code, der im Happy Path funktioniert, und stößt dann auf Edge Cases rund um Account-Ownership und Rent, die kein Ethereum-Pendant haben. Plane echte Zeit für den Modellwechsel ein; es ist keine Syntax-Übersetzung.

Der ehrliche Trade-off und der Founder-Fehler „nimm die schnelle billige Chain": Solanas Validator-Hardware-Anforderungen sind höher als die von Ethereum, also ist das Validator-Set kleiner, und historisch gab es Netzwerkausfälle (zuletzt seltener). Für Consumer-Payments und High-Volume-Apps ist dieser Trade-off meist in Ordnung, und der Durchsatz ist es wert. Für ein System, dessen Kernversprechen Zensurresistenz ist, prüfe das Bedrohungsmodell sorgfältig, bevor du annimmst, dass Solana die Latte schafft.

Die Ökosystem-Kosten sind die andere Hälfte der Entscheidung. Das tiefe, komponierbare DeFi und Tooling, das auf EVM-Chains lebt, existiert nicht alles auf Solana, und Assets hinüberzubrücken ist eine nicht-triviale, sicherheitssensible Operation für sich, kein kostenloser Import. Wenn dein Produkt sich in bestehende On-Chain-Protokolle einklinken muss, ist dieser Zug-zur-EVM real und sollte gegen Solanas rohe Performance abgewogen werden. Ist dein Produkt weitgehend in sich geschlossen und durchsatzgebunden (Payments, Consumer-Apps, Gaming), gewinnt die Performance, und das kleinere Ökosystem beißt selten. Wavect liefert sowohl in Solana als auch in EVM über den Web3-Stack. Wir haben keine Chain-Vorliebe; wir haben eine Use-Case-Vorliebe.

LoRaWAN ist die Netzwerkschicht, die großflächige IoT-Projekte ökonomisch macht. Geräte laufen jahrelang mit Knopfzellen, senden kleine Payloads (ein paar hundert Byte) und erreichen Gateways über Kilometer. Die Trade-offs: niedrige Bandbreite, seltene Updates, nicht-triviale Deployment-Phase, um Gateway-Abdeckung richtig zu setzen.

Anwendungen, die wir geliefert haben: Smart-City-Sensornetze (Parken, Umwelt, Abfall), Agrar-Monitoring, industrielle Telemetrie. Das Muster ist immer gleich: günstige, dumme Sensoren an der Edge; Gateways aggregieren zum Netzwerk-Server; der Netzwerk-Server schickt an dein Application-Backend.

Beispiel, wohin das Budget tatsächlich geht, und der Fehler, den Founder machen: Sie bepreisen die Sensoren und vergessen die Abdeckung. Eine Farm oder ein Stadtviertel braucht Gateways so positioniert, dass jeder Sensor mindestens eines erreicht, und das falsch zu machen bedeutet Funklöcher, Retransmissionen und Batterien, die in Monaten statt Jahren leerlaufen. Bei einem echten Deployment sind das Site-Survey und die Gateway-Platzierung oft die schwerere Hälfte des Projekts, lange nachdem die Kosten pro Sensor abgesegnet wurden. Wände, Gelände und Metallsilos fressen Reichweite, und du findest es nur durch Messen vor Ort heraus.

Die andere Entscheidung, die Founder überstürzen, ist, wem das Netz gehört. Mit LoRaWAN betreibst du typischerweise deine eigenen Gateways, was keine Mobilfunkrechnung pro Gerät bedeutet, aber eine echte Verantwortung: Du betreibst die Gateways, den Netzwerk-Server und die Abdeckung. Die Mobilfunk-Alternativen (NB-IoT, LTE-M) drehen das um, der Carrier besitzt die Abdeckung überall, wo er hinreicht, und du zahlst im Gegenzug einen Datentarif pro Gerät. Für ein dichtes, festes Deployment, das du kontrollierst (ein Campus, eine Farm, ein Stadtviertel), gewinnt das Eigenbetreiben über die Gerätelebensdauer meist bei den Kosten. Für eine geringe Gerätezahl, unvorhersehbar über Regionen verstreut, ist das Zahlen an den Carrier günstiger als das Bauen einer Abdeckung, die du kaum nutzen wirst.

Der ehrliche Trade-off: LoRaWAN tauscht Bandbreite und Latenz gegen Reichweite und Batterielaufzeit, und dieser Tausch ist nicht verhandelbar, nicht justierbar. Es ist das richtige Werkzeug, wenn du viele Sensoren über eine weite Fläche mit mehrjähriger Batterielaufzeit brauchst und nur ab und zu ein paar Byte sendest. Es ist das falsche Werkzeug, wenn du hohe Bandbreite, niedrige Latenz oder per-Device-Konnektivität brauchst, die dem Gerät folgt; dafür ist 5G NB-IoT oder LTE-M meist der bessere Fit. Entscheide, auf welcher Achse dein Produkt tatsächlich lebt, bevor du dich auf das Funkprotokoll festlegst.

Ein LLM ist ein Modell, das auf enormen Textmengen trainiert wurde, um genau eine Sache zu tun: den nächsten Token (grob gesagt das nächste Wortfragment) auf Basis von allem Vorherigen vorherzusagen. Stapelt man genug davon, entstehen flüssige Antworten, Zusammenfassungen, Übersetzungen und Code. Das ist der ganze Trick. Es ist kein Denken im menschlichen Sinn, sondern sehr gute Mustervervollständigung.

Das ist wichtig, weil es Magie und Grenzen zugleich erklärt. Ein LLM hat kein Gedächtnis für dein Geschäft, kein Wissen jenseits seines Trainings-Cutoffs und keine eingebaute Garantie, dass die flüssige Antwort auch stimmt. Es nennt einen falschen Fakt mit exakt derselben Überzeugung wie einen richtigen. Behandle es als Werkzeug, nicht als Orakel.

Das LLM ist das falsche Werkzeug, wenn du deterministische, prüfbare Ergebnisse brauchst: Steuerberechnungen, regulatorische Logik, alles wo “meistens richtig” ein Risiko ist. Der richtige Weg ist, das Modell mit der unspektakulären Technik drumherum zu umgeben: Retrieval für Fakten, Validierung für die Ausgabe und ein Mensch im Prozess, wo ein Fehler teuer wird. Genau das bauen wir unter Künstliche Intelligenz.

Die ehrliche Zusammenfassung: Ein LLM ist eine probabilistische Text-Engine. Für die richtigen Aufgaben (Entwürfe, Klassifikation, Extraktion, Suche über die eigenen Daten) ist es ein echter Verstärker. Als Quelle der Wahrheit ist es ein selbstbewusstes Risiko.

Prompt Engineering ist die Praxis, das zu strukturieren, was du an ein Modell schickst: die Aufgabenbeschreibung, die Beispiele, die Vorgaben, das Ausgabeformat und den Kontext. Das Modell hat keine Ahnung, was du willst, bis du es ihm sagst, und wie du es sagst, verändert das Ergebnis drastisch. Ein vager Prompt bekommt eine vage Antwort. Ein präziser Prompt mit Beispielen und definiertem Ausgabeschema bekommt etwas, das du tatsächlich ausliefern kannst.

Der Hype stilisiert das zur mystischen Fähigkeit. Die Realität ist nüchterner und nützlicher: Es ist iteratives Engineering. Du schreibst einen Prompt, testest ihn an echten Fällen, siehst wo er scheitert, schärfst die Anweisungen oder ergänzt Beispiele, misst erneut. Der System-Prompt (die stehenden Anweisungen über jeder Nutzernachricht) ist der Ort, an dem das dauerhafte Verhalten lebt, also fließt dorthin die eigentliche Arbeit.

Hier der ehrliche Teil: Prompt Engineering ist real, aber kein Karriere-Burggraben. Die Techniken sind in einer Woche erlernbar, und die Modelle werden immer besser darin, schlampige Prompts zu verstehen. Nicht zur Massenware wird das Wissen, auf welches Problem man das Modell ansetzt, wie man es in ein echtes System einbindet und ob man die Ausgabe als vertrauenswürdig bewerten kann. Das ist Engineering, und genau das tun wir unter Künstliche Intelligenz.

Sei vorsichtig bei jedem, der “Prompt Engineering” als eigenständiges Produkt verkauft. Der Prompt ist der billige Teil. Der teure Teil ist alles drumherum: Retrieval, Evaluation, Leitplanken und die Integration, die aus einem cleveren Prompt ein verlässliches Feature macht.

Fine-Tuning nimmt ein vortrainiertes Modell und trainiert es weiter auf einem kuratierten Satz eigener Beispiele, wobei die Gewichte des Modells so angepasst werden, dass es zum gezeigten Verhalten tendiert. Du nutzt es, um einen konsistenten Ton, ein bestimmtes Ausgabeformat, ein Fachvokabular oder eine Aufgabe einzubacken, die das Basismodell unbeholfen behandelt. Es ändert, wie das Modell antwortet, nicht auf welche Fakten es Zugriff hat.

Die Entscheidung, auf die es wirklich ankommt, ist Fine-Tuning gegen RAG, und ständig wird sie falsch herum getroffen. RAG speist frische, sich ändernde Fakten zur Laufzeit ein, indem es aus deinen Daten abruft, die Antwort ist also nur so aktuell wie dein letztes Dokument-Update. Fine-Tuning lehrt dauerhaftes Verhalten, friert das Wissen aber zum Trainingszeitpunkt ein, ist also das falsche Werkzeug, wenn sich deine Fakten ändern. Die Faustregel: Tunen für die Form, abrufen für die Fakten. Viele echte Systeme nutzen beides, ein fine-getuntes Modell, das im eigenen Hausstil antwortet, geerdet durch Retrieval für die Live-Daten.

Die Kostenrealität ist weniger furchteinflößend als früher, aber real. Du brauchst einen sauberen, gelabelten Datensatz (meist Hunderte bis Tausende Beispiele), den Trainingslauf selbst und die laufenden Kosten für erneutes Tuning, jedes Mal wenn sich das Basismodell verbessert oder deine Anforderungen verschieben. Diese letzten Kosten vergessen Teams. Ein Fine-Tune ist kein einmaliges Projekt, sondern eine Wartungsverpflichtung.

Praxisbeispiel, wo Fine-Tuning klar gewinnt: Ein Unternehmen braucht jede Modellantwort als striktes JSON nach einem internen Schema, mit einem bestimmten knappen Hausstil, über Millionen von Aufrufen hinweg. Prompting schafft das meistens, aber die gelegentliche fehlerhafte Antwort bricht das nachgelagerte System, und den vollständigen Styleguide samt Schema in jeden Prompt zu stopfen verbrennt bei jedem Aufruf Token. Ein Fine-Tune backt Format und Ton in die Gewichte des Modells, sodass die Anweisungen nicht mehr im Kontext wiederholt werden müssen, was Antworten bei diesem Volumen sowohl verlässlicher als auch pro Aufruf günstiger macht. Das ist der Sweet Spot: dauerhaftes Verhalten, hohes Aufrufvolumen und ein Format, das Prompting nicht ganz konsistent trifft.

Wann gewinnt Fine-Tuning klar? Wenn Prompting plus Retrieval das nötige Format oder Verhalten nicht verlässlich erzeugen können und du genug hochwertige Beispiele hast, um es zu lehren. Im Zweifel schöpfe zuerst Prompting und RAG aus, denn sie sind billiger zu ändern. Diese Build-gegen-Tune-Entscheidung treffen wir unter Künstliche Intelligenz.

Eine Vektordatenbank speichert Embeddings: numerische Repräsentationen von Text (oder Bildern oder Audio), bei denen ähnliche Bedeutung auf nahe Punkte im Raum abgebildet wird. Statt exakte Stichwörter abzugleichen, bettest du die Nutzeranfrage auf dieselbe Weise ein und fragst die Datenbank nach den nächstgelegenen Vektoren. Das ist Ähnlichkeitssuche, und sie lässt ein System “wie kündige ich meinen Tarif” finden, wenn im Dokument eigentlich “Vorgang zur Abo-Beendigung” steht.

In einer RAG-Pipeline ist das die Retrieval-Schicht. Die Qualität deiner Antworten hängt stark davon ab: gute Embeddings und gute Suche liefern die richtigen Chunks ans Modell, schlechte liefern Müll, und das Modell fasst diesen Müll überzeugt zusammen. Deshalb entscheidet meist das Retrieval, nicht das Modell, über Erfolg oder Scheitern eines RAG-Projekts.

Hier der Teil, den Anbieter überspringen: Oft brauchst du gar keine dedizierte Vektordatenbank. Ist dein Korpus klein (Tausende, nicht Millionen Chunks), ist eine Vektor-Erweiterung auf dem ohnehin laufenden Postgres (pgvector) einfacher, billiger und ein System weniger zu betreiben. Ist deine Suche vorwiegend stichwortgetrieben, schlägt schlichte Volltextsuche die Vektorsuche unter Umständen klar. Greife zur spezialisierten Vektor-DB, wenn Skalierung, Latenz oder hybride Suche bei hohem Volumen es tatsächlich rechtfertigen, nicht weil sie im Architekturdiagramm steht.

Praxisbeispiel fürs Over-Engineering: Ein Team baut einen internen Doku-Assistenten über ein paar tausend Seiten und greift zu einer gemanagten Vektordatenbank, einer separaten Embedding-Pipeline und einem Reranking-Service, bevor es einen einzigen Nutzer hat. Es betreibt jetzt vier Systeme, um Fragen zu beantworten, die pgvector auf dem bestehenden Postgres erledigt hätte, und jedes davon ist eine neue Sache zum Überwachen, Absichern und Bezahlen. Die langweilige Variante geht in einer Woche live und skaliert gut, bis der Korpus wirklich groß wird. Greife zur spezialisierten Datenbank, wenn die Zahlen es erzwingen (Millionen Vektoren, harte Latenzbudgets, hybride Suche bei hohem Volumen), nicht weil das Architekturdiagramm seriöser aussieht.

Wir wählen bewusst die ausreichend langweilige Option unter Künstliche Intelligenz, denn jedes zusätzliche System ist eine weitere Sache, die man um 3 Uhr morgens am Leben halten muss.

Eine Halluzination ist, wenn ein Modell etwas erzeugt, das richtig klingt und falsch ist: eine erfundene Quelle, eine ausgedachte API, ein plausibler, aber falscher Fakt. Es ist kein Fehler, den man wegpatchen kann. Ein LLM sagt wahrscheinlichen Text voraus, und eine flüssige, überzeugt klingende Antwort ist statistisch wahrscheinlich, egal ob sie zufällig stimmt. Das Modell hat kein inneres Gespür für “das weiß ich nicht”, also füllt es die Lücke mit etwas, das ins Muster passt.

Weil es strukturell ist, lautet die ehrliche Einordnung Risikoreduktion, nicht Beseitigung. Der größte Hebel ist Erdung: Gib dem Modell die tatsächlichen Fakten zur Laufzeit per Retrieval (RAG), damit es aus echtem Quelltext antwortet statt aus seiner Trainings-Vermutung. Schränke Ausgabeformate ein, damit weniger Raum zum Improvisieren bleibt. Lass das Modell Quellen nennen, die du prüfen kannst. Und entscheidend: evaluiere, baue ein Testset echter Fragen, miss wie oft das System falsch liegt, und behandle diese Zahl als Qualitätskennzahl, die du wie jede andere verfolgst.

Hier trifft KI auf QA, und die meisten Teams überspringen das. Ein LLM-Feature ohne Evaluations-Harness auszuliefern heißt, ungetesteten Code auszuliefern und es fertig zu nennen. Du musst deine Fehlerrate kennen, bevor deine Nutzer sie für dich finden. Das behandeln wir als nicht verhandelbar unter Software Quality Assurance.

Praxisbeispiel, warum der Evaluations-Harness nicht verhandelbar ist: Ein Team liefert einen Rechtsdokument-Assistenten aus, nachdem es ihn von Hand an einem Dutzend Fragen getestet hat, die alle großartig aussahen. In Produktion zitiert er überzeugt eine Klausel, die im hochgeladenen Vertrag gar nicht existiert, ein Nutzer handelt danach, und jetzt gibt es ein echtes Haftungsrisiko. Der Harness, der das abgefangen hätte, ist unglamourös: ein paar hundert echte Fragen mit bekannten korrekten Antworten, bei jeder Änderung ausgeführt, die eine einzige Zahl erzeugen, den Prozentsatz, den das System falsch hatte. Ohne ihn kennst du deine Fehlerrate nicht, das heißt deine Nutzer entdecken sie für dich, eine schlechte Antwort nach der anderen. Mit ihm kannst du vor dem Launch entscheiden, ob die Rate für den Einsatz akzeptabel ist.

Der Vertrauensaspekt ist in regulierten oder risikoreichen Domänen das ganze Spiel. Eine Halluzination in einem Chatbot, der einen Film empfiehlt, ist ein Achselzucken. Dieselbe Halluzination in Finanz-, Rechts- oder medizinischer Ausgabe ist ein Risiko. Passe die Leitplanken an die Kosten des Irrtums an, und lass nie eine flüssige Antwort eine geprüfte ersetzen.

Das Context Window ist das Arbeitsgedächtnis des Modells für eine einzelne Anfrage, gemessen in Token (ein Token ist grob drei Viertel eines Wortes). Alles muss hineinpassen: dein System-Prompt, der Gesprächsverlauf, alle Dokumente, die du einfügst, und die Antwort, die das Modell erzeugt. Überschreitest du das Fenster, kann das Modell den Überlauf schlicht nicht sehen.

“Pack einfach alles in den Prompt” scheitert aus drei Gründen, selbst wenn das Fenster groß ist. Erstens Kosten: die meisten Anbieter rechnen pro Token ab, ein riesiges Dokument in jedem Aufruf vervielfacht also die Rechnung. Zweitens Latenz: mehr Token bedeuten eine langsamere Antwort. Drittens, am wenigsten offensichtlich, Qualität, Modelle achten weniger zuverlässig auf Information, die mitten in einem sehr langen Kontext vergraben ist, mehr ist also nicht immer besser. Ein fokussierter Prompt schlägt oft einen aufgeblähten.

Genau deshalb existiert RAG. Statt deinen ganzen Korpus ins Fenster zu kippen, rufst du nur die paar relevanten Chunks pro Frage ab und schickst nur diese. Du bekommst den Nutzen einer großen Wissensbasis, ohne dafür zu zahlen, sie bei jeder Anfrage komplett zu verarbeiten. Das Context Window ist das Budget, Retrieval ist, wie du es klug ausgibst.

Praxisbeispiel für den “Lost in the Middle”-Effekt, der Teams überrascht: Ein Unternehmen fügt ein 40-seitiges Richtliniendokument in den Prompt ein und stellt eine Frage, deren Antwort auf Seite 20 steht. Das Modell liegt trotzdem falsch, obwohl das ganze Dokument technisch in seinem Fenster liegt, weil die Aufmerksamkeit für Material nachlässt, das mitten in einem langen Kontext vergraben ist. Dasselbe Modell antwortet korrekt, wenn man ihm nur die zwei relevanten Absätze gibt, die das Retrieval herausgezogen hat. Größere Fenster lösten das Problem nicht; besser zugeschnittener Kontext schon. Das ist der kontraintuitive Teil, den Founder übersehen, wenn ein neues Modell mit einer schlagzeilenträchtigen Fenstergröße erscheint: mehr Kapazität ist nicht mehr Verlässlichkeit.

Die praktische Erkenntnis: Behandle das Context Window als knappe Ressource mit Preisschild, nicht als Gratisraum. Genau um dieses Budget herum entwerfen wir bewusst unter Künstliche Intelligenz.

Eine Blockchain ist eine Datenbank mit zwei ungewöhnlichen Eigenschaften. Erstens ist sie nur erweiterbar: Man kann Datensätze hinzufügen, aber bestehende nicht umschreiben, ohne dass alle Teilnehmer es bemerken. Zweitens kontrolliert sie keine einzelne Partei. Ein Netzwerk von Knoten betreibt dieselbe Software und einigt sich über einen Konsensmechanismus (Proof-of-Work, Proof-of-Stake oder eine erlaubnispflichtige Variante) auf den nächsten Block. Das Ergebnis ist ein Register, dem mehrere Parteien vertrauen können, ohne einander zu vertrauen.

Es gibt zwei grobe Arten. Eine öffentliche Blockchain (Ethereum, Bitcoin, Solana) ist offen: Jeder kann sie lesen, einen Knoten betreiben oder Transaktionen durchführen. Eine private oder erlaubnispflichtige Blockchain schränkt die Teilnahme ein, was meist bedeutet, dass man eine langsamere, komplexere Version einer normalen Datenbank mit zusätzlichen Schritten nachgebaut hat. Wenn ein Unternehmen alle Knoten kontrolliert, hat man keinen Blockchain-Vorteil, sondern ein verteiltes System, das man nun betreiben muss.

Praxisbeispiel für die Frage, die alles klärt: Ein Logistikunternehmen will eine Blockchain, “damit Partner den Versanddaten vertrauen können”. Geh die drei Tests durch. Müssen die Datensätze die Insolvenz des Unternehmens überleben? Eigentlich nicht, das Unternehmen betreibt ja selbst das Netzwerk. Müssen sich gegenseitig misstrauende Parteien Zustand ohne Betreiber teilen? Näher dran, aber in der Praxis ist eine Partei klar der Knotenpunkt, an den sich alle anderen anbinden. Brauchen sie erlaubnisfreie Komponierbarkeit mit anderen On-Chain-Systemen? Nein. Was sie also tatsächlich wollen, ist eine sauber berechtigte gemeinsame Datenbank mit Audit-Log und signierten Einträgen, die günstiger und schneller ist und die ihr bestehendes Team betreiben kann. Der Blockchain-Pitch löste ein Vertrauensproblem, das eine Signatur und eine Read-Replica längst lösen.

Die ehrliche Haltung: Die meisten Projekte, die angeblich eine Blockchain brauchen, brauchen keine. Eine Blockchain rechtfertigt ihre Komplexität nur, wenn man Assets benötigt, die die Insolvenz des Betreibers überleben, geteilten Zustand zwischen Parteien, die einander nicht vertrauen, oder erlaubnisfreie Komponierbarkeit. Alles andere ist eine Datenbank. Wir haben echte Blockchain-Systeme ausgeliefert und mehr Kunden davon abgeraten, als wir gebaut haben. Unsere Blockchain-Arbeit beginnt mit der Frage, ob du überhaupt eine brauchst.

Ein Layer 2 ist eine Blockchain, die ihre Sicherheit von einem Layer 1 (meist Ethereum) bezieht, statt einen eigenen Konsens von Grund auf zu betreiben. Der L2 führt Transaktionen außerhalb der Basis-Chain aus, bündelt sie und schreibt das Ergebnis an L1 zurück. Nutzer erhalten die Sicherheitsgarantien von Ethereum zu einem Bruchteil der Kosten und mit deutlich höherem Durchsatz. L2s existieren, weil Blockplatz auf der Basisschicht knapp und teuer ist: Wenn Ethereum ausgelastet ist, kann eine einfache Überweisung mehr kosten als der überwiesene Betrag.

Das dominierende Design ist der Rollup, der in zwei Varianten kommt. Optimistic Rollups (Arbitrum, Optimism, Base) gehen davon aus, dass Transaktionen gültig sind, und erlauben ein Einspruchsfenster, in dem jeder ein betrügerisches Bündel anfechten kann. ZK-Rollups nutzen einen Zero-Knowledge-Beweis, um mathematisch zu belegen, dass jedes Bündel gültig ist, bevor es auf L1 landet, was die Einspruchsverzögerung entfernt, allerdings auf Kosten schwererer Beweis-Infrastruktur. Optimistic ist heute einfacher und günstiger zu bebauen; ZK ist die Richtung, in die sich die Technologie bewegt.

Das Detail, das Nutzer überrascht und Founder verbrennt, die nicht damit geplant haben: Auszahlungen zurück an L1. Bei einem Optimistic Rollup bedeutet das Einspruchsfenster, dass das Bewegen von Geldern vom L2 zum Ethereum-Mainnet rund eine Woche dauern kann, es sei denn, du bezahlst eine “Fast Bridge” eines Dritten, die die Liquidität vorstreckt. Ein Nutzer, der in Sekunden eingezahlt hat und in Sekunden auszahlen will, liest deine Doku über Fraud-Proof-Fenster nicht; er denkt, deine App sei kaputt oder stehle sein Geld. Wenn du auf einem Optimistic L2 baust, ist das Auszahlungserlebnis ein Produktproblem, um das du ab Tag eins herum designen musst, kein Implementierungsdetail.

Wavect hat auf einem L2 (Boba Network) in Produktion ausgeliefert, einschließlich seines Hybrid-Compute-Modells, das einen Smart Contract während der Ausführung Off-Chain-Code aufrufen lässt. Dieses Muster ist mächtig, um reale Daten oder schwere Berechnungen in einen Vertrag zu bringen, und es ist tatsächlich schwer sicher zu betreiben. Wenn ein Anbieter eine L2-Bereitstellung als kostenlosen Skalierungsgewinn anpreist, frag, wie Auszahlungen an L1 funktionieren, wie hoch die Finalitätsverzögerung ist und wer den Sequencer betreibt. Unsere Blockchain-Arbeit deckt L2-Auswahl und -Bereitstellung ab.

DeFi ersetzt den Vermittler in einer Finanztransaktion durch Code. Statt eines Brokers, der Trades zusammenführt, nutzt eine dezentrale Börse (DEX) einen automatisierten Market Maker: einen Smart Contract, der zwei Assets in einem Pool hält und Swaps über eine Formel bepreist. Statt einer Bank, die entscheidet, wer einen Kredit erhält, lässt ein Lending-Protokoll jeden gegen Sicherheiten leihen, die er in einem Vertrag sperrt, mit algorithmisch über Angebot und Nachfrage gesetzten Zinssätzen. Niemand genehmigt dich; der Vertrag führt einfach aus.

Die echte Innovation ist Komponierbarkeit. Weil jedes Protokoll ein öffentlicher Vertrag auf derselben Chain ist, lassen sie sich wie Lego zusammenstecken. Eine Position in einem Protokoll kann Sicherheit in einem anderen sein, die in einem dritten verpackt und gehandelt wird, alles in einer einzigen Transaktion. Das kann der traditionelle Finanz-Stack mit seinen abgeschotteten APIs und Abwicklungsverzögerungen nicht. Es ist auch der Grund, warum DeFi-Ausfälle kaskadieren: Wenn ein Baustein bricht, bricht alles darauf Gestapelte mit.

Die Risiken sind real und konkret. Smart-Contract-Risiko: Ein Bug leert den Pool, und es gibt keine Rückbuchung. Oracle-Risiko: Protokolle hängen von Preis-Feeds ab, und ein manipuliertes Oracle lässt einen Angreifer gegen gefälschte Sicherheiten leihen.

Das Risiko, das Founder am meisten unterschätzen, ist regulatorisch, nicht technisch. In der EU kann ein Geschäft, das auf DeFi-Schienen baut oder DeFi-nahe Dienste anbietet, unter MiCA, Geldwäsche-Pflichten und Lizenzanforderungen fallen, von denen „dezentral" dich nicht befreit. Regulatoren schauen zunehmend darauf, wer ein Protokoll tatsächlich kontrolliert und daran verdient, nicht aufs Marketing. Wenn dein Modell annimmt, dass die erlaubnisfreie Natur von DeFi keine Compliance-Last bedeutet, kalkuliere eine rechtliche Prüfung ein, bevor du shippst, denn die falsche Klassifikation kostet weit mehr als die Contract-Arbeit. Wir haben Zahlungsinfrastruktur ausgeliefert, die DeFi-Schienen berührt (Scramble), und unsere Position ist, dass DeFi mächtig ist für den engen Satz an Anwendungsfällen, die erlaubnisfreie, komponierbare Finanzen brauchen, und eine Belastung für alle, die es als Rendite-Casino nutzen. Unsere Blockchain-Arbeit beginnt damit, welcher von beiden du bist.

Eine DAO ist eine Möglichkeit, ein Kollektiv zu führen, bei dem die Regeln für Mitgliedschaft, Abstimmung und Ausgaben in Smart Contracts liegen. Die Treasury ist ein On-Chain-Wallet, das Mittel nur freigibt, wenn ein Vorschlag eine Abstimmung besteht. Die Stimmkraft folgt meist dem Token-Bestand oder der Mitgliedschaft. Das Versprechen: Koordination wird transparent und manipulationssicher. Jeder kann die Treasury prüfen, jede Stimme wird festgehalten, und kein einzelner Unterzeichner kann die Mittel heimlich abziehen.

DAOs funktionieren gut für eine bestimmte Aufgabe: das Verwalten einer geteilten On-Chain-Treasury, bei der sich die Mitglieder nicht vollständig vertrauen und nachprüfbare Regeln dafür brauchen, wer was ausgeben darf. Investmentclubs, Governance von Protokollparametern und Förderfinanzierung sind echte Anwendungsfälle. Wir haben die On-Chain-Governance und Treasury-Logik für FTW DAO gebaut, wo die Struktur ihre Komplexität rechtfertigt, weil echtes Geld parteiübergreifend gebündelt wird.

Den rechtlichen Status übergehen die meisten DAO-Pitches, und in Österreich und der weiteren EU zählt er. Eine DAO ist keine anerkannte Rechtsform. Solange die Mitglieder sie nicht in eine echte Rechtsform packen (eine GmbH, einen Verein, eine Stiftung), kann ein Gericht die Teilnehmer als Personengesellschaft mit solidarischer Haftung behandeln, ein Mitglied könnte also persönlich für die Verpflichtungen des Kollektivs haften. „Der Code ist die Organisation" ist ein gutes Engineering-Prinzip und ein gefährliches rechtliches. Jede DAO, die echtes Geld oder echte Gegenparteien berührt, braucht einen echten rechtlichen Mantel unter den Smart Contracts, entschieden vor dem Launch, nicht nach dem ersten Streit.

Wo DAOs zum Theater werden: Governance über Entscheidungen, die gar nicht On-Chain sind, token-gewichtete Abstimmung, die Macht bei einer Handvoll Wale konzentriert, und „Community-Governance", die ein Marketing-Etikett über einem Team ist, das immer noch die Admin-Schlüssel kontrolliert. Wenn die harten Entscheidungen weiterhin in einem privaten Chat fallen und die Abstimmung ein Abnicken ist, hast du ein normales Unternehmen im DAO-Kostüm. Wir sagen dir, welches du baust. Siehe unsere Blockchain-Arbeit.

Ein NFT ist ein Token-Standard (ERC-721 auf Ethereum ist der gängige) für Assets, die nicht austauschbar sind. Ein Euro ist fungibel: Jeder Euro ist so gut wie jeder andere. Eine Urkunde für ein bestimmtes Haus ist es nicht. Ein NFT ist das On-Chain-Äquivalent dieser Urkunde: ein einzigartiger Eintrag, an eine Eigentümeradresse gebunden, übertragbar und von jedem überprüfbar. Was der Token tatsächlich repräsentiert, ist eine Designentscheidung, und ein Großteil der Wertfrage hängt davon ab, diese Entscheidung richtig zu treffen.

Die ehrliche Unterscheidung verläuft zwischen Nutzen und Spekulation. Echter Nutzen: tokenisiertes Eigentum an einem realen Vermögenswert (RWA), ein Zugangsrecht, das einen Dienst oder ein Event freischaltet, ein Mitgliedschaftsnachweis oder ein In-Game-Gegenstand, den der Spieler wirklich kontrolliert. In diesen Fällen erledigt der NFT eine Aufgabe, die eine Datenbankzeile nicht kann, weil der Eigentümer ihn erlaubnisfrei übertragen oder verkaufen kann und er den Herausgeber überlebt. Wir haben NFT-gestützte Mechaniken für LivLive gebaut, wo der Token reale Erlebnisse freischaltet, statt als Sammlerstück zu dienen.

Ein Detail, das naive NFT-Projekte still zerbricht: Der Token on-chain ist meist nur ein Zeiger, und worauf er zeigt, liegt oft auf einem normalen Webserver. Geht dieser Server runter oder hört die Firma auf, dafür zu zahlen, zeigt der „permanente" NFT jetzt auf nichts, ein kaputter Bild-Link mit einer Blockchain dahinter. Projekte, die den Eigentumsanspruch ernst nehmen, speichern das referenzierte Asset auf content-adressiertem Speicher wie IPFS oder direkt on-chain, sodass das, was der Token repräsentiert, so lange überlebt wie der Token. Wenn ein Anbieter dir nicht sagen kann, wo das eigentliche Asset liegt und wer es am Leben hält, ist die Permanenz Marketing.

Der Spekulationsfall ist der Großteil des Marktes: ein Token, der auf ein JPEG zeigt, dessen einziger Wert der nächste Käufer ist, der mehr zahlt. Daran ist technisch nichts falsch, aber es ist ein Sammlermarkt mit Blockchain-Abwicklung, kein Produktivitätswerkzeug. Wenn ein Anbieter NFTs für dein Unternehmen anpreist, ist die Frage immer dieselbe: Was lässt der Token den Inhaber tun, das eine Datenbank nicht kann, und muss dieses Eigentum dein Unternehmen überleben? Unsere Blockchain-Arbeit beginnt dort.

Ein Crypto Wallet hält keine Coins; die Coins liegen auf der Blockchain. Das Wallet hält den privaten Schlüssel, der sie kontrolliert, und nutzt ihn, um Transaktionen zu signieren, die Assets bewegen oder ausgeben. Das ist das ganze Spiel: Wer den Schlüssel hält, hält die Assets. Verliert man den Schlüssel, sind die Mittel ohne Wiederherstellung weg; gibt man ihn preis, leert ein Angreifer das Konto sofort. Die meisten Wallets sichern den Schlüssel als Zwölf-Wort-Seed-Phrase, die die menschenlesbare Form dieses einzelnen Versagenspunkts ist.

Die erste Gabelung ist verwahrt versus selbstverwahrt. Ein verwahrtes Wallet (ein Börsenkonto) hält den Schlüssel für dich, wie eine Bank dein Geld hält: bequem, vom Support wiederherstellbar und nur so sicher wie das Unternehmen und nur so verfügbar wie dessen Zahlungsfähigkeit. Ein selbstverwahrtes Wallet legt den Schlüssel in die Hände des Nutzers: Niemand kann die Assets einfrieren oder beschlagnahmen, und niemand kann helfen, wenn der Nutzer die Seed-Phrase verliert. Dieser Kompromiss, zwischen Kontrolle und Sicherheitsnetz, ist das prägende UX-Problem des gesamten Bereichs.

Eine regulatorische Linie, die du verstehen solltest, weil sie deine Pflichten komplett verändert: Ein echtes selbstverwahrtes Wallet, bei dem nur der Nutzer Mittel bewegen kann und du nie seine Schlüssel berührst, hält dich in der Regel aus den Money-Transmitter- und Custody-Lizenzregimen heraus, die Börsen regeln. In dem Moment, in dem dein Produkt Nutzergelder bewegen, Schlüssel halten oder bei der Wiederherstellung einspringen kann, bist du womöglich in Verwahr-Territorium mit allem Lizenz-, KYC- und AML-Gewicht, das dazugehört. Recovery-Features sind genau die Stelle, an der das subtil wird: Ein „Social-Recovery"-Schema, bei dem deine Firma einer der Guardians ist, sieht für einen Regulator ganz anders aus als eines, bei dem nur die vom Nutzer gewählten Kontakte Anteile halten. Entwirf das Recovery-Modell mit Blick auf die rechtliche Klassifikation, nicht nur auf die UX.

Account Abstraction ist der glaubwürdigste Ausweg. Indem man das Wallet selbst zu einem Smart Contract macht, kann man Social Recovery (vertrauenswürdige Guardians stellen den Zugang wieder her), gaslose Transaktionen, Ausgabenlimits und eine Anmeldung per E-Mail und Passkey statt einer Seed-Phrase hinzufügen. Wir haben selbstverwahrte Wallets in Produktion ausgeliefert, darunter Scramble und MetaMask Snaps, und unsere Sicht ist, dass reine Seed-Phrase-Wallets für Mainstream-Nutzer eine Sackgasse sind. Die Wiederherstellungsfrage muss gelöst sein, bevor eine nicht-technische Person nennenswerte Werte halten sollte. Siehe unsere Blockchain-Arbeit.

Ein Stablecoin ist ein Token, der versucht, an ein stabiles Asset gekoppelt zu bleiben, fast immer den US-Dollar. Der Sinn ist, die Abwicklungsgeschwindigkeit und globale Reichweite einer Blockchain zu behalten, ohne die Volatilität, die Bitcoin oder ETH als Recheneinheit unbrauchbar macht. Man kann einen Stablecoin halten, senden und empfangen wie E-Mail für Geld: in Sekunden final, grenzüberschreitend, ohne eine Bank dazwischen. Das ist der echte Anwendungsfall, besonders für Zahlungen und Überweisungen in und aus Regionen mit schwacher Bankinfrastruktur.

Wie die Kopplung hält, definiert das Risiko. Fiat-gedeckte Stablecoins (USDC, USDT) halten echte Dollar und Staatsanleihen auf einem Bankkonto und prägen einen Token pro Dollar. Die Kopplung ist nur so gut wie die Reserven und die Ehrlichkeit des Herausgebers, weshalb Reservenachweise zählen. Krypto-besicherte Stablecoins (DAI) überbesichern mit On-Chain-Assets und tauschen Verwahrungsrisiko gegen Liquidationsrisiko bei einem Markteinbruch. Algorithmische Stablecoins versuchen, die Kopplung über Angebotsmechanik und ohne echte Deckung zu halten, und der Friedhof (Terra/UST, Milliarden verdampft) ist der Grund, warum seriöse Akteure sie meiden.

Das EU-Regulierungsbild ist inzwischen konkret, nicht theoretisch. Unter MiCA fallen Stablecoins (E-Geld-Token und wertreferenzierte Token) ausdrücklich in den Anwendungsbereich, mit Anforderungen an Reserven, Offenlegung und Zulassung des Herausgebers, und die Regeln beschränken, wie Nicht-Euro-Stablecoins für alltägliche Zahlungen in großem Maßstab innerhalb der Union verwendet werden dürfen. Für jedes Unternehmen, das in Österreich oder der weiteren EU Zahlungsflüsse auf Stablecoin-Schienen baut, lautet die Frage nicht mehr “ist das erlaubt”, sondern “welcher Coin, ausgegeben von wem, unter welcher Zulassung”. Das ist eine Designentscheidung, die du vor der Integration triffst, denn Compliance nachträglich auf ein bereits gelaunchtes Zahlungsprodukt aufzusetzen ist der teure Weg.

Wir haben Zahlungsinfrastruktur auf Stablecoin-Schienen gebaut (Scramble) und an Stablecoin-nahen Systemen gearbeitet (Zybra), also ist die Position fundiert: Stablecoins sind das wirklich nützlichste Primitiv in Krypto, um Wert zu bewegen, und die Kopplung ist nie umsonst. Wisse immer, was den Coin deckt, wer ihn einfrieren kann und was bei einem Ansturm passiert. Unsere Blockchain-Arbeit behandelt das Kopplungsmodell als erstklassige Designentscheidung.

Microservices bedeutet, eine Anwendung in viele kleine Services zu zerlegen, von denen jeder ein Stück des Geschäfts verantwortet und jeder für sich deploybar ist. Statt eines Programms, in dem alles im selben Prozess läuft, bekommt man eine Flotte von Services, die über das Netzwerk miteinander reden. Das Versprechen ist echt: Teams können unabhängig liefern, man kann nur die Teile skalieren, die es brauchen, und ein Service kann ausfallen, ohne das ganze System mitzureißen.

Die Kosten sind ebenfalls echt und werden meist unterschätzt. In dem Moment, in dem aus Funktionsaufrufen Netzwerkaufrufe werden, hat man ein verteiltes System, und verteilte Systeme sind schwer. Man erbt Netzwerkausfälle, Latenz, über viele Datenbanken verstreute Daten ohne einfache Transaktionen, Versionierung zwischen Services und die Betriebslast, viele bewegliche Teile statt eines zu betreiben, zu überwachen und zu debuggen. Ein Bug, der früher ein Stacktrace war, ist jetzt eine Spur über fünf Services und drei Queues.

Die ehrliche Haltung: Die meisten Startups sollten mit einem Monolithen starten. Eine gut strukturierte einzelne Anwendung ist schneller zu bauen, weit einfacher zu debuggen und durchaus in der Lage, einen bis zu echtem Umsatz zu tragen. Man teilt in Microservices auf, wenn man einen konkreten Grund hat, ein Team groß genug, dass eine Codebasis ein Engpass ist, oder eine Last, die wirklich unabhängige Skalierung braucht, nicht weil Microservices die modische Antwort sind. Verfrühte Microservices sind die Art, wie kleine Teams aus einem schweren Problem zehn machen.

Polity lief auf sieben Microservices, und das war für seine Größe und Teamstruktur die richtige Entscheidung. Genau das ist der Punkt: Die Architektur sollte dem Problem und dem Organigramm folgen, nicht einem Konferenzvortrag. Wähle die Grenzen dort, wo sie die Kopplung tatsächlich reduzieren, und akzeptiere, dass jede Grenze, die du ziehst, ein Netzwerkaufruf ist, den du jetzt verteidigen musst.

Eine API ist die definierte Art, wie eine Software mit einer anderen redet. Sie sagt: Hier sind die Dinge, um die du mich bitten kannst, hier ist genau, wie du fragst, und hier ist, was du zurückbekommst. Der ganze Sinn ist, dass der Aufrufer nicht wissen muss, wie die Arbeit intern erledigt wird, nur was er senden und was er erwarten soll. Die Wetter-App auf deinem Telefon weiß nicht, wie der Wetterdienst funktioniert. Sie kennt nur die API, sendet eine Anfrage und bekommt eine Vorhersage.

Die Kernidee ist der Vertrag. Beide Seiten einigen sich auf die Form der Anfragen und Antworten, und solange dieser Vertrag hält, kann jede Seite ihr Innenleben frei ändern. Die zwei gängigen Stile, von denen man hört, sind REST, das alles als Ressourcen modelliert, die man über Standard-Webanfragen liest und schreibt, und das der Standard für die meisten Web- und Mobile-Backends ist, und GraphQL, das dem Aufrufer erlaubt, in einer Anfrage genau die Felder zu erbitten, die er will. Beide sind nur disziplinierte Arten, denselben Vertrag zu definieren.

API-Design ist eine der langlebigsten Entscheidungen, die man trifft. Internen Code kann man an einem Wochenende refaktorieren. Bei einer öffentlichen API hängt fremde Software von genau ihrer Form ab, also brechen Änderungen deren Integrationen, was bedeutet, dass man sie oft gar nicht ändern kann ohne eine schmerzhafte Versionierung. Eine saubere, gut benannte, konsistente API altert gut. Eine schludrige wird zu einer dauerhaften Steuer, die man bei jeder künftigen Änderung zahlt. Wir behandeln API-Design als erstklassigen Teil der Softwareentwicklung, nicht als nachträglich angeschraubten Gedanken.

Die ehrliche Einschätzung: Die meisten “die Integration ist ein Albtraum”-Klagen lassen sich auf eine API zurückführen, die in Eile entworfen wurde, um ein Feature zu liefern, und dann zehn tragen musste. Investiere früh die Zeit in den Vertrag. Das ist der Teil, den du später am wenigsten ändern kannst.

SaaS ist ein Liefer- und Geschäftsmodell, keine Technologie. Statt dir eine Kopie der Software zu verkaufen, die du selbst installierst und betreibst, hostet der Anbieter sie, betreibt sie und gibt dir gegen eine wiederkehrende Gebühr Zugang über das Web. Du loggst dich ein, du nutzt sie, du fasst nie die Server an. Salesforce, Slack und Notion sind SaaS. Der Kunde mietet Fähigkeit, statt Software zu kaufen und zu warten.

Das prägende technische Merkmal ist Mandantenfähigkeit (Multi-Tenancy): Ein laufendes System bedient viele Kunden gleichzeitig, mit voneinander isolierten Daten. Diese eine Entscheidung prägt alles. Man entwirft für Isolation und Sicherheit zwischen Mandanten, für das Ausrollen von Updates an alle auf einmal, ohne irgendjemanden zu brechen, und für Skalierung beim Hinzukommen von Kunden, statt einmal im Jahr eine neue Version auszuliefern. Es ändert auch den Betrieb, denn der Anbieter trägt nun Verfügbarkeit, Backups und Sicherheit als laufende Verantwortung, nicht der Kunde.

Das Geschäftsmodell ist die andere Hälfte. Der Umsatz ist ein Abonnement, meist monatlich oder jährlich, was bedeutet, dass die Beziehung nicht beim Verkauf endet, sie beginnt dort. Die Kennzahlen, die zählen, werden wiederkehrender Umsatz, Churn und die Kosten, jeden Kunden zu bedienen. Die Preisgestaltung knüpft meist an Wert oder Nutzung an: pro Platz, pro Stufe oder pro Volumen. Macht man das Preismodell falsch, verliert ein technisch exzellentes Produkt trotzdem bei jedem Kunden Geld, also ist Preisgestaltung ebenso eine Architektur- wie eine Vertriebsentscheidung.

Wir bauen SaaS-Produkte von Anfang bis Ende, von der mandantenfähigen Architektur bis zur Web-App, in die sich Kunden einloggen. Polity ist ein SaaS-Produkt. Der ehrliche Teil, den Gründer unterschätzen: Das wiederkehrende Modell heißt, du verpflichtest dich zu dauerhafter Verantwortung für Verfügbarkeit, Sicherheit und Support, was echte Betriebskosten sind, kein einmaliges Bauen.

Agile ist älter, als die meisten denken (das Manifest stammt aus 2001) und schlechter umgesetzt, als die meisten Teams zugeben. Der Ursprungsgedanke war simpel: weiter zu planen, als man vorhersagen kann, ist vergeudete Arbeit. Also: kurz planen, shippen, lernen, neu planen. Alles andere (Scrum, Kanban, SAFe, Sprints, Retros, Story Points) ist Implementierungsdetail obendrauf.

Die nützlichste Frage an ein Team, das sagt „wir machen Agile": Wann hat sich der Plan zuletzt aufgrund dessen geändert, was letzte Woche geshippt wurde? Lautet die Antwort nie, macht das Team Wasserfall in Zwei-Wochen-Häppchen.

Beispiel für den Unterschied: Zwei Teams fahren beide zweiwöchige Sprints. Team A demot, sieht, dass das Feature, das niemand auf der Roadmap vorhergesagt hat, das ist, das Nutzer tatsächlich anklicken, und ordnet den nächsten Sprint darum neu. Team B demot, notiert das Feedback in einem Doc und macht mit dem im Januar geschriebenen Plan weiter, weil der Plan der Plan ist. Team A ist agile. Team B hat agile Zeremonien und ein Wasserfall-Gehirn. Die Zeremonien sind identisch; nur die Bereitschaft, auf Evidenz zu handeln, unterscheidet sich, und das ist das ganze Spiel.

Der ehrliche Trade-off und der Founder-Fehler: Agile ist kein Freibrief, Planung zu überspringen, und es ist nicht gratis. Es tauscht Langhorizont-Vorhersehbarkeit gegen schnelles Lernen, was genau falsch ist, wenn Scope, Regulierung oder ein Interface-Vertrag wirklich nicht ändern können (zertifizierte Medizingeräte, Avionik, manche Hardware). Selbst dort gelten die ursprünglichen Prinzipien innerhalb des Teams; der nach außen sichtbare Prozess sieht nur mehr nach Wasserfall aus. Wavect ist agile im ursprünglichen Sinn: Wir arbeiten in kurzen Zyklen, demoen oft, lehnen uns auf CI/CD, damit Shippen billig ist, und sind bereit, Arbeit wegzuwerfen, die sich als falsch herausstellte. Wir sind skeptisch gegenüber der Zertifikatsindustrie-Version von Agile, bei der die Meeting-Kadenz zum Ziel wird und eine TDD-Suite zur Schau statt für Vertrauen geschrieben wird.

Wann das im Softwareprojekt zählt. Wenn der Scope sich noch ändern kann, weil der Markt dir laufend etwas beibringt, was bei den meisten frühen Produkten der Fall ist. Agile tauscht Langhorizont-Vorhersehbarkeit gegen schnelles Lernen, und dieser Tausch zahlt sich nur aus, wenn du wirklich bereit bist, auf das zu handeln, was geshippt wird.

Was Founder meistens falsch machen. Sie kaufen die Zeremonien und behalten ein Wasserfall-Gehirn: Zwei-Wochen-Sprints, Story Points, Retros, und ein Plan, der sich seit Januar nicht geändert hat. Zeremonien ohne die Bereitschaft, auf Evidenz den Kurs zu ändern, sind Wasserfall in Verkleidung.

Wie Wavect damit umgeht. Wir sind agile im ursprünglichen Sinn: kurze Zyklen, häufige Demos, billiges Shippen via CI/CD, und wir werfen Arbeit weg, die sich als falsch herausstellte. Wenn Scope wirklich nicht beweglich ist, sagen wir das und planen entsprechend; der Leitfaden Fixpreis vs Time & Material behandelt diese Vertragswahl.

Test-Driven Development ist eine Disziplin, keine Methodik. Die Schleife: rot (failing Test schreiben), grün (einfachsten Code schreiben, der grün macht), refactor (sauber machen, ohne den Test zu brechen). Wörtlich umgesetzt produziert es Code mit hoher Testabdeckung und einer Zwangsfunktion gegen Over-Engineering. Die Disziplin zahlt sich nur aus, wenn diese Tests bei jeder Änderung laufen, weshalb TDD und CI/CD Geschwister sind, keine getrennten Anliegen.

Warum die meisten Teams behaupten TDD zu machen, es aber nicht tun: Den Test zuerst zu schreiben fühlt sich im Moment langsamer an. Der Compounding-Payoff (Refactor-Sicherheit, Regressionsschutz, Designdruck zu kleineren Einheiten) zeigt sich erst Monate später. Bis dahin hat das Team aufgehört, Tests zuerst zu schreiben, und sich eingeredet, es habe nie einen Unterschied gemacht.

Beispiel, wo TDD seine Kosten verdient versus wo es Theater ist: Ein Payments-Reconciliation-Modul hat fiese Edge Cases (Teilrückerstattungen, Währungsrundung, Retries). Den failing Test zuerst zu schreiben zwingt dich, das erwartete Verhalten zu benennen, bevor der Code existiert, und die Suite fängt die Regression sechs Monate später ab, wenn jemand die Rundung „vereinfacht". Das ist TDD, das sich selbst bezahlt. Stell dem ein Wegwerf-Daten-Import-Skript gegenüber, das du in zwei Wochen löschst: Tests zuerst zu schreiben ist dort reiner Overhead. Die ehrliche Regel ist, die logik-lastige, teuer-falsch-zu-machende Code per TDD zu schreiben und den Rest nicht.

Der häufigste Fehler ist, Coverage als Ziel zu behandeln. Jag 90 % nach, und das Team schreibt Tests für Getter und Setter, um die Zahl zu treffen, während es die Integrationstests überspringt, wo die echten Bugs leben. Coverage ist ein nützliches Diagnostikum und ein schreckliches Ziel; es ist eine Metrik, die gegamed wird. Wavect nutzt TDD, wo es sich rechnet: Integrationstests für alles Geldförmige, Contract-Tests für alles Customer-Facing, BDD-artige Akzeptanztests, wo Produkt sie lesen können muss, Unit-Tests für nicht-triviale Logik. Wir testen die schweren Teile gut, nicht alle Teile gleich, und behandeln es als eine Praxis innerhalb einer gesunden Agile-Schleife, nicht als Häkchen.

Behavior-Driven Development ist TDD mit umgeschriebener Testsprache, sodass Nicht-Engineers sie lesen können. Tools wie Cucumber nutzen ein Given/When/Then-Format, das ein Product Manager unterschreiben kann. Ziel: Tests am Business-Verhalten ausrichten, das sie validieren, statt an der gerade existierenden Implementierung.

Beispiel, wo sich das tatsächlich auszahlt: Ein Versicherungsprodukt hat eine Regel, dass ein Claim unter 30 Tagen mit gültiger Police automatisch genehmigt wird. Als Gherkin-Szenario geschrieben („Given eine seit 30 Tagen aktive Police, When ein Claim innerhalb des Deckungsfensters eingereicht wird, Then wird er automatisch genehmigt"), können der Product Owner und der Compliance-Prüfer es lesen, bestätigen, dass es der echten Regel entspricht, und den Off-by-One abfangen, bevor er shippt. Dieser Gemeinsame-Sprache-Check ist der ganze Wert von BDD, und er lebt auf der Akzeptanz- und Integrationsebene, wo die Lücke zwischen dem, was Produkt meinte, und dem, was Engineering baute, dort ist, wo Bugs geboren werden.

Es gibt außerdem Wartungskosten, die Teams spät entdecken. Gherkin-Szenarien sitzen auf einer Schicht aus „Step Definitions", Glue-Code, der jede Klartext-Zeile auf echte Testaktionen abbildet. Dieser Klebstoff ist echte Software, die synchron gehalten werden muss, während sich das Produkt ändert, und eine große BDD-Suite mit schlampigen Step Definitions wird zur eigenen Wartungslast, langsam im Lauf und brüchig im Editieren. Der Nutzen (ein Stakeholder kann das Verhalten lesen und unterschreiben) bezahlt diesen Overhead nur, wenn ein Stakeholder sie tatsächlich liest. Wird das Gherkin von Engineers geschrieben, von Engineers gelesen und von niemandem sonst gesehen, zahlst du für eine Übersetzungsschicht ohne Publikum.

Der ehrliche Trade-off und der häufige Fehler: BDD ist kein Ersatz für TDD, es ist eine Schicht obendrauf, und es überall anzuwenden ist der Fehler. „Given zwei Zahlen, When ich sie addiere, Then bekomme ich die Summe" für eine triviale Funktion zu schreiben ist Zeremonie, die kein Business-Stakeholder je liest. Heb dir Gherkin für die Tests auf, die ein Nicht-Engineer wirklich unterschreiben muss, und nutze schlichte Unit-Tests unterhalb dieser Linie. Wie all diese Praktiken ist BDD eine Stufe in einem vernünftigen SDLC und ein Werkzeug für ein echtes Kommunikationsproblem, kein Prozess, den man um seiner selbst willen adoptiert.

Das Wort „Viable" trägt die Last in MVP, und fast jeder versteht es falsch. Viable heißt nicht „abgespeckte Variante des späteren Produkts". Viable heißt „ausreichend, um die Hypothese zu testen, ob dieses Produkt gebaut werden sollte". Eine Landing Page mit Warteliste kann ein MVP sein. Ein lauffähiges Produkt mit drei Features kann ein schlechteres MVP sein als die Landing Page.

Beispiel: Ein Founder ist überzeugt, seine Hypothese sei „Nutzer zahlen für automatisierte Rechnungs-Reconciliation". Der Instinkt ist, drei Monate damit zu verbringen, die Reconciliation-Engine zu bauen. Das billigere MVP, das die tatsächliche Hypothese testet, ist ein manuelles: eine Landing Page, ein Preis und ein Mensch, der die Reconciliation hinter den Kulissen von Hand macht (ein Wizard-of-Oz-MVP). Zahlt niemand für die manuelle Version, wären die Engine drei vergeudete Monate gewesen. Der Build startet erst, sobald die Zahlungsbereitschaft bewiesen ist, was genau die Art De-Risking ist, für die eine Discovery-Phase da ist.

Es gibt eine österreichische Förder-Falte, die man kennen sollte. aws Preseed und ähnliche Förderungen sind oft um das Erreichen eines „Prototyp"- oder „MVP"-Meilensteins herum formuliert, und Founder lassen manchmal die Definition der Förderung den Build diktieren, polstern das MVP mit Features auf, die ein Förder-Häkchen abhaken, statt eine Hypothese zu testen. Nutze das Geld, um schneller zu lernen, nicht um ein schwereres MVP zu bauen, als das Lernen verlangt. Die Förderung belohnt einen Meilenstein; der Markt belohnt eine validierte Annahme, und das sind nicht immer dasselbe Artefakt.

Der häufigste Fehler ist, das MVP zu bauen, das man sich vor sechs Monaten vorgestellt hat, statt jenes MVP, das die diese-Woche-unsicherste Annahme testet. Jede Woche verschiebt sich die riskanteste Annahme, und die meisten MVPs sind veraltet, bevor sie shippen. Der ehrliche Trade-off: Ein MVP unterbaut bewusst, also wird es neben dem polierten Ding in deinem Kopf unbeeindruckend aussehen, und dieses Unbehagen ist der Preis fürs schnelle Lernen. Läuft die Build-Phase über 8 bis 12 Wochen, baust du kein MVP, sondern V1 unter einem netteren Namen. Wavect fährt kurze Agile-Zyklen Richtung MVP und benennt die Hypothese, bevor wir den Build scopen. Verwandt: Fractional CTO Österreich übernimmt MVP-Leadership end-to-end.

Wann das im Softwareprojekt zählt. Ganz am Anfang, wenn das Wertvollste, das du kaufen kannst, das Lernen ist, ob die Idee falsch ist, und zwar billig, bevor du ein Build-Budget darauf committest.

Was Founder meistens falsch machen. Sie lesen „minimal" als „kleine Version des fertigen Produkts" und bauen das MVP, das sie sich vor sechs Monaten vorgestellt haben, statt jenes, das die riskanteste Annahme dieser Woche testet. Läuft der Build über 8 bis 12 Wochen, ist es V1 unter einem netteren Namen.

Wie Wavect damit umgeht. Wir benennen die Hypothese, bevor wir überhaupt etwas scopen, und bauen dann das kleinste Artefakt, das sie testet. Siehe was eine Discovery-Phase ist zur Entrisikung der Idee und wie man einen Tech-Stack für ein MVP wählt, um sie günstig änderbar zu halten.

Product-Market Fit ist berüchtigt schwer zu definieren und berüchtigt leicht zu erkennen. Marc Andreessens Heuristik gilt noch: Du weißt, dass du ihn hast, wenn das Produkt von Nutzern, Presse und Cap Table gleichzeitig gezogen wird und dein Problem nicht mehr darin besteht, Kunden zu finden, sondern mit ihnen Schritt zu halten.

Vor PMF ist fast alles, was du machst, eine Wette. Das richtige Org-Chart, der richtige Tech-Stack, der richtige Hiring-Plan hängen davon ab, welches Kundensegment tatsächlich zieht. Nach PMF werden die Fragen operativ: Team skalieren, Stack härten, Burn kontrollieren.

Beispiel für den teuersten Pre-PMF-Fehler: Ein Team raised eine Seed-Runde, stellt vier Engineers ein und verbringt neun Monate damit, eine Kubernetes-gestützte, multiregionale Microservices-Plattform zu bauen, „damit wir skalieren können". Sie skalieren auf vierzig Nutzer, der Runway geht aus, und die Architektur, die sie für Millionen gebaut haben, wird nie von Hunderten getestet. Das Gegenversagen ist seltener, aber real: Ein Team findet den Zug, wird gefeatured, und der einzelne überlastete Server fällt um in der einen Woche, in der der ganze Markt zuschaute. Die Engineering-Entscheidung ist vollständig eine Funktion davon, auf welcher Seite der PMF-Linie du stehst, weshalb die Linie ehrlich zu benennen mehr zählt als jede Stack-Entscheidung.

Der ehrliche Trade-off, dem Founder ausweichen: Zuzugeben, dass man pre-PMF ist, fühlt sich an wie Versagen einzugestehen, also beschreiben Decks das mühsame Verkaufen Kunde für Kunde als „frühe Traktion". Wenn Akquise noch ein Kampf ist und Churn hoch genug, dass Mundpropaganda das Wachstum nicht tragen kann, bist du pre-PMF, egal was das Deck sagt, und der richtige Zug ist, das billigste MVP zu shippen, das die nächste Unsicherheit auflöst, statt für eine Skalierung zu bauen, die du nicht verdient hast. Eine Discovery-Phase hilft dir, die riskanteste Annahme zu benennen; ein fractional Operator kann teure technische Fehler während der Suche verhindern, aber nicht die unermüdliche Kundenobsession des Founders ersetzen, die den Zug tatsächlich erzeugt. Nach PMF brauchst du typischerweise einen CTO, keinen Co-Founder. Siehe Fractional CTO Österreich.

Software Development Lifecycle ist der Sammelbegriff für die Phasen, die Software von Idee bis Außerbetriebnahme durchläuft. Verschiedene Methoden (Agile, Wasserfall, DevOps, Continuous Delivery) definieren andere Phasengrenzen und andere Übergangsmodi. Die Phasen selbst sind weitgehend invariant: Discovery, Design, Build, Test, Deploy, Operate, Retire.

Nützlich als Vokabular, nicht als Prozess. Teams, die ein strenges SDLC erzwingen, landen bei Dokumentations-Overhead, der den zweiten Sprint nicht überlebt. Teams, die das SDLC völlig ignorieren, entdecken jede Phase auf die schmerzhafte Art neu („wir haben ohne Deploy-Plan geshippt", „wir haben nie überlegt, wie wir das System abschalten").

Beispiel für die Phase, die alle überspringen: Ein Startup baut über zwei Jahre drei interne Services, shippt sie und macht weiter. Niemand verantwortet „Operate" und niemand plante „Retire". Achtzehn Monate später laufen zwei der drei Services noch, niemand erinnert sich warum, der eine Engineer, der sie verstand, ist gegangen, und das Abschalten könnte etwas brechen oder auch nicht. Das sind die unverrechneten Kosten, die hintere Hälfte des Lifecycles zu überspringen. Die Lösung ist billig, wenn vorab gemacht (einen Owner benennen, einen Deploy- und einen Teardown-Plan schreiben), und teuer, wenn später entdeckt.

Die Methode, die du wählst, entscheidet vor allem, wie starr die Grenzen zwischen Phasen sind. Ein Wasserfall-SDLC läuft sie strikt in Sequenz mit Sign-offs an jedem Gate; ein agiles SDLC verschränkt Design, Build und Test fortlaufend und kehrt zu früheren Phasen zurück, während es lernt. Die Phasen sind in beiden Fällen dasselbe Set, was die nützliche Einsicht ist: „Agile versus Wasserfall" zu streiten heißt eigentlich, darüber zu streiten, wie durchlässig die Grenzen sein sollen, und die richtige Antwort hängt davon ab, wie sehr sich deine Anforderungen noch ändern können.

Der ehrliche Trade-off und der häufige Fehler: Founder hören „SDLC" und überformalisieren es entweder zu einem gated, Sign-off-lastigen Prozess, der Tempo killt, oder tun es als Enterprise-Theater ab und überspringen die unglamourösen Phasen. Die richtige Haltung ist, es als Checkliste von Dingen zu behandeln, die irgendwo passieren müssen, nicht als Sequenz, die man durchmarschiert. Wavects bevorzugte Form: eine bezahlte Discovery-Phase vorne, Design und Build in kurzen Zyklen verschränkt, automatisiertes TDD und CI/CD von Tag eins, Operate mit klarer Ownership, Retire mit dokumentierten Migrationspfaden.

Wann das im Softwareprojekt zählt. Als Checkliste von Phasen, die irgendwo passieren müssen: Discovery, Design, Build, Test, Deploy, Operate, Retire. Überspringst du die unglamouröse hintere Hälfte, kommt die Rechnung später als verwaiste Services, die niemand anfassen will.

Was Founder meistens falsch machen. Sie schwingen in eines von zwei Extremen: Sie überformalisieren den SDLC zu einem gated, Sign-off-lastigen Prozess, der Tempo killt, oder tun ihn als Enterprise-Theater ab und entdecken jede Phase nach dem Launch auf die schmerzhafte Weise neu.

Wie Wavect damit umgeht. Bezahlte Discovery vorne, Design und Build in kurzen Zyklen verschränkt, automatisierte Tests und CI/CD ab Tag eins, klare Operate-Ownership, dokumentierter Teardown. Die QA-Checkliste vor dem Launch und was eine Discovery-Phase ist decken die Phasen ab, die Founder am häufigsten überspringen.

Continuous Integration heißt, der Team-Code wird bei jeder Änderung gemerged und gebaut, statt bei einer Big-Bang-Integration am Ende. Continuous Delivery heißt, jeder erfolgreiche Build ist einen Knopfdruck von Production entfernt. Continuous Deployment entfernt den Knopf: Jeder grüne Build geht automatisch live. Die drei sind eine Reifeleiter, keine Synonyme.

Die meisten Teams machen CI gut, CD sporadisch und Continuous Deployment fast nie. Der Engpass ist selten das Tooling. Es ist das Vertrauen in die Testsuite und die Bereitschaft, einen kaputten Build binnen einer Stunde zu reparieren. Ohne beides shippen automatische Deploys nur Bugs schneller.

Beispiel für den Hebel, der in der Pipeline-Geschwindigkeit versteckt ist: Ein Team hat eine CI-Pipeline, die 25 Minuten braucht. Engineers hören auf, sie lokal laufen zu lassen, batchen ihre Änderungen und mergen auf Hoffnung, um das Warten zu vermeiden. Bugs sammeln sich zwischen Merges, und der Integrationsschmerz, den das Team mit CI vermeiden wollte, kommt still zurück. Schneide diese Pipeline für den Inner Loop auf unter 10 Minuten, und Engineers lassen sie ständig laufen, fangen Probleme ab, solange der Kontext frisch ist, und die ganze Agile-Schleife zieht sich enger. Pipeline-Geschwindigkeit ist kein Nice-to-have; sie ist ein Kraftmultiplikator für jeden Engineer-Tag.

Der ehrliche Trade-off und der häufige Fehler: Founder fragen nach „vollem CI/CD", als wäre es ein einzelner Schalter, während CI vor allem Tooling und CD vor allem Disziplin ist. CI kannst du an einem Nachmittag haben. Echtes Continuous Delivery verlangt eine Testsuite, der das Team hinter einer TDD-Gewohnheit vertraut, einen in Minuten gemessenen Rollback-Pfad und jemanden auf Abruf, der reagiert, wenn ein Deploy etwas anzündet. Wavect shippt jedes Projekt mit CI ab Tag eins, als Teil eines vernünftigen SDLC; die CD-Konfiguration hängt davon ab, ob das Projekt die Abdeckung und operative Disziplin hat, um sie sicher zu machen. Wir sagen dir, welche du hast.

Wann das im Softwareprojekt zählt. Vor dem Launch und bei jeder Änderung danach. Eine gesunde Pipeline ist das, was ein Team sicher shippen und Regressionen fangen lässt, solange der Kontext frisch ist, statt Änderungen zu bündeln und auf Hoffnung zu mergen.

Was Founder meistens falsch machen. Sie fragen nach „vollem CI/CD", als wäre es ein einzelner Schalter. CI ist vor allem Tooling, das du an einem Nachmittag haben kannst; echtes Continuous Delivery ist vor allem Disziplin, eine Testsuite, der das Team vertraut, ein Rollback in Minuten und jemand auf Abruf. Ohne das shippen automatisierte Deploys nur schneller Bugs.

Wie Wavect damit umgeht. Wir konfigurieren CI ab Tag eins und schalten automatisierte Auslieferung erst frei, wenn Abdeckung und operative Disziplin sie sicher machen. Die QA-Checkliste vor dem Launch listet genau, was eine Pipeline leisten muss, bevor echte Nutzer kommen.

Continuous Delivery ist die verantwortliche Cousine von Continuous Deployment. Jede Änderung durchläuft dieselbe automatisierte Build-, Test- und Release-Vorbereitungs-Pipeline (das CI/CD-Rückgrat). Das Artefakt am Ende ist shippbar. Ob es tatsächlich shippt, entscheidet ein Mensch.

Warum die meisten Teams bei CD stoppen statt zu Continuous Deployment überzugehen: Die Kosten eines schlechten Deploys sind hoch genug, dass ein Mensch in der Schleife die Latenz wert ist. Auf Continuous Deployment wechseln, wenn Monitoring, Testabdeckung und Rollback-Story gut genug sind, dass der Mensch kein Signal mehr addiert.

Beispiel für die Wahl pro Service, nicht pro Firma: Dieselbe Firma betreibt eine Marketing-Site und ein Payments-Ledger. Die Marketing-Site ist ein großartiger Fit für volles Continuous Deployment, wo ein schlechter Deploy einen Tippfehler bedeutet und ein Rollback trivial ist, also kann jeder grüne Build unbeaufsichtigt shippen. Das Payments-Ledger bleibt bei Continuous Delivery mit einem Menschen, der den Knopf drückt, weil ein schlechter Deploy dort Geld falsch bewegt und der Mensch wirklich Signal addiert, nicht nur Latenz. „Sollen wir Deploys automatisieren" als eine firmenweite Entscheidung zu behandeln ist der Fehler; es ist ein Risiko-Urteil pro Service.

Es gibt eine regulatorische Dimension, die es zu benennen lohnt. In Domänen mit Change-Control- oder Audit-Anforderungen (Finanzen, Gesundheit, alles, was personenbezogene Daten unter der DSGVO berührt) ist der menschliche Freigabeschritt in Continuous Delivery nicht nur Risikomanagement, sondern oft die dokumentierte Kontrolle, die ein Prüfer sehen will: wer dieses Release freigab, gegen welche Evidenz, wann. Teams in solchen Umfeldern sollten volles Continuous Deployment nicht als Reife-Abzeichen jagen; das manuelle Gate ist ein Feature, von dem ihre Compliance-Story abhängt. Automatisiere alles bis zum Knopf, dann lass den Knopf, wo der Audit-Trail ihn braucht.

Der ehrliche Trade-off: Continuous Delivery kauft dir den Großteil der Geschwindigkeit voller Automatisierung, während ein menschliches Veto auf dem unumkehrbaren Schritt bleibt, zum Preis, dass dieses Veto ein Engpass ist, wenn der Mensch langsam oder abwesend ist. Die Voraussetzung, darüber hinauszuwachsen, ist real, nicht aspirativ: eine TDD-gestützte Suite, hinter der das Team shippt, ein Minuten-nicht-Stunden-Rollback und eine On-Call-Rotation. Ohne diese drei ist „Continuous Delivery" ein Knopf, den niemand zu drücken wagt, und die Pipeline ist Dekoration auf einem ansonsten gesunden SDLC.

Vibe Coding heißt: einem KI-Coding-Tool beschreiben, was man will, und ausliefern, was es zurückgibt, ohne den Code Zeile für Zeile zu lesen. Der Begriff wurde Anfang 2025 populär, der Workflow ist älter als der Name: prompten, laufen lassen, sehen dass es funktioniert, wieder prompten. Tools wie Lovable, Cursor, Claude Code, Replit, Bolt und v0 machen es möglich, dass ein Nicht-Engineer an einem Nachmittag von der Idee zur klickbaren App kommt. Das ist echt und für Prototypen, interne Tools und das Validieren einer Idee genuin nützlich.

Der Ärger beginnt in dem Moment, in dem eine vibe-coded App auf einen echten User, echtes Geld oder echte Daten trifft. Ein LLM optimiert auf Code, der den Prompt erfüllt und im Demo läuft. Es optimiert nicht auf die Dinge, nach denen im Prompt niemand gefragt hat: Autorisierungsprüfungen, Input-Validierung, Secrets-Management, Rate Limiting, Error Handling, die Regressions-Suite. Genau das trennt ein Demo von produktionsreifer Software, und genau das lässt das Modell weg, sofern man nicht weiß, danach zu fragen, was ein Nicht-Engineer per Definition nicht tut.

Beispiel. Ein Founder vibe-coded an einem Wochenende ein SaaS-Dashboard. Es hat einen Login, eine Datenbank, ein sauberes UI und demot wunderbar. Was es nicht hat, ist eine serverseitige Prüfung, dass User A nicht die Datensätze von User B lesen kann. Der Login funktioniert, also fühlt es sich sicher an. Aber jeder eingeloggte User kann eine ID in der URL ändern und die Daten jedes anderen Kunden lesen. Das Modell wurde nie gebeten, mandantenweise Autorisierung zu erzwingen, also tat es das nicht, und nichts im Demo machte die Lücke sichtbar. Das ist der mit Abstand häufigste schwere Defekt in vibe-coded Software, und er bleibt unsichtbar, bis jemand, oder eine Behörde, ihn findet.

Der ehrliche Trade-off: Vibe Coding ist tatsächlich schneller zum lauffähigen Demo, und etwas anderes zu behaupten wäre unehrlich. Der Preis ist, dass diese Geschwindigkeit aus dem Auslassen genau der Engineering-Teile kommt, die keinen sichtbaren Payoff haben, bis sie failen. Für einen Wegwerf-Prototyp ist das ein guter Deal, für alles mit Kundendaten ein schlechter. Der Fehler ist nicht, die Tools zu benutzen. Der Fehler ist, das Demo für das Produkt zu halten und es auszuliefern. KI-generierter Code ist nicht per se schlechter als handgeschriebener, aber er sammelt Technical Debt lautlos an und überspringt jedes Mal dieselbe Sicherheitsarbeit.

Wavects Position ist simpel: Prototyp vibe-coden, dann einen strukturierten Production-Readiness-Durchlauf machen, bevor echte User kommen. Dieser Durchlauf ist kein Vibe. Es ist dieselbe Disziplin, die wir auf jeden Code anwenden: TDD auf der Logik, die zählt, Autorisierung auf jedem Endpoint, Secrets raus aus dem Client und eine CI/CD-Pipeline, die die Checks bei jeder Änderung laufen lässt. Wir machen das unter Software Quality Assurance. Die Tools sind gut. Sie wissen nur nicht, was sie weggelassen haben, und du auch nicht, bis es jemand liest.

Wann das im Softwareprojekt zählt. In dem Moment, in dem ein vibe-coded Prototyp aufhört, Wegwerfware zu sein, und Richtung echte Nutzer, echtes Geld oder echte Daten geht. Genau dann werden die vom Modell ausgelassenen Teile zu den Teilen, die dich breachen.

Was Founder meistens falsch machen. Sie verwechseln die Demo mit dem Produkt und shippen sie. Der Happy Path läuft, also fühlt es sich sicher an, aber nichts im Prompt hat nach Autorisierung, Validierung oder Secrets-Management gefragt, also ist nichts davon da.

Wie Wavect damit umgeht. Prototyp vibe-coden, dann vor dem Launch einen strukturierten Production-Readiness-Durchlauf: Auth auf jedem Endpoint, Secrets raus aus dem Client, eine Regressions-Suite, ein CI/CD-Gate. Der Leitfaden vom vibe-coded Prototyp zur Production zeigt die Härtung Schritt für Schritt.

Vibe-coded Software ist das Ergebnis von Vibe Coding: eine überwiegend von KI-Tools gebaute Anwendung, deren sicherheitsrelevante Teile kein Mensch gelesen hat. Sie definiert sich nicht dadurch, KI-generiert zu sein. Sie definiert sich durch das Fehlen eines menschlichen Reviews auf den Pfaden, wo ein Fehler echtes Geld, echte Daten oder einen echten Breach kostet. Viel KI-generierter Code ist reviewed, gehärtet und vollkommen sicher. Vibe-coded Software ist die Teilmenge, bei der das nicht passiert ist.

Das prägende Merkmal: Sie demot sauber und bricht vorhersehbar. Sauber, weil das Modell sehr gut darin ist, den Happy Path funktionieren zu lassen, den Pfad, den man im Demo abläuft. Vorhersehbar, weil die Fehler jedes Mal an derselben Handvoll Stellen clustern: Autorisierung, die prüft ob du eingeloggt bist, aber nicht ob du diesen Datensatz sehen darfst, Input dem vertraut statt der validiert wird, hartcodierte oder an den Browser ausgelieferte Secrets, kein Rate Limiting, kein Error Handling jenseits eines generischen Catch. Wer ein vibe-coded App auditiert hat, kann die Findings des nächsten erraten, bevor er es öffnet.

Beispiel, das kanonische. Eine Buchungs-App hat einen sauberen Login. Einmal drin holt die App deine Buchungen von /api/bookings/1234. Ändere 1234 auf 1235 und du siehst die Buchung von jemand anderem, dessen Name, dessen Adresse, dessen Zahlungsreferenz. Der Login fühlte sich sicher an, also prüfte niemand. Der Server hat nie verifiziert, dass der eingeloggte User die Buchung 1235 besitzt. Das nennt man einen Broken-Object-Level-Authorization-Bug, und er ist der mit Abstand häufigste schwere Defekt in vibe-coded Software, weil das Demo nie den Fall durchspielt, dass ein User nach den Daten eines anderen greift.

Der ehrliche Trade-off: Vibe-coded Software ist tatsächlich billiger und schneller zu produzieren, und für einen Prototyp ist das genau richtig. Der Preis ist, dass die Ersparnis vorgezogen ist und die Rechnung später kommt, als Breach, als DSGVO-Vorfall oder als Rewrite. Das zu benennen ist kein Anti-KI-Snobismus. Der Code kann vollkommen gut sein, sobald die fehlenden 10 % ergänzt sind. Der Fehler ist, die 90 % auszuliefern und anzunehmen, das Demo habe die übrigen 10 % bewiesen.

Wavect auditiert vibe-coded Software auf genau dieses Profil unter Software Quality Assurance. Wir lesen zuerst die Autorisierungspfade, weil dort der schlimmste und häufigste Bug lebt, dann Input-Validierung, Secrets und Error Handling, dann ergänzen wir die Regressions-Suite und das CI/CD-Gate, das die nächste Änderung daran hindert, das Loch wieder aufzureißen. Es ist kein Rewrite. Es ist, die von den Tools hinterlassene Technical Debt sichtbar zu machen und dann den Teil abzuzahlen, der dir schaden kann.

Wann das im Softwareprojekt zählt. Wenn du eine sauber demoende App hast und niemand die Autorisierungspfade gelesen hat. Das definierende Risiko ist nicht schlechter Code, sondern das Fehlen einer menschlichen Prüfung dort, wo ein Fehler Geld, Daten oder einen Breach kostet.

Was Founder meistens falsch machen. Sie shippen die 90 Prozent, die die Demo bewiesen hat, und nehmen an, die Demo habe auch die anderen 10 Prozent bewiesen. Die fehlenden 10 Prozent, Auth, Validierung, Secrets, sind genau der Teil, den die Demo nie ausführt.

Wie Wavect damit umgeht. Wir auditieren auf das vorhersehbare Fehlerprofil, Autorisierung zuerst, weil dort der schlimmste Bug lebt, und ergänzen dann die Regressions-Suite und das CI/CD-Gate, das das Loch am Wiederaufreißen hindert. Der Leitfaden vom vibe-coded Prototyp zur Production zeigt, was übernommen und was neu gebaut wird.

KI-generierter Code ist Code, den ein LLM-Coding-Tool produziert (Copilot, Cursor, Claude Code, Lovable und der Rest) statt ihn von Hand zu tippen. Wichtig festzuhalten: Er ist nicht per se schlechter als menschlicher Code. Auf dem Happy Path ist er oft sauberer, idiomatischer und besser kommentiert als das, was ein gehetzter Engineer um 18 Uhr am Freitag schreiben würde. Allen KI-generierten Code als Müll zu behandeln ist genauso falsch wie ihn allen als produktionsreif zu behandeln.

Die eigentlich relevante Eigenschaft: KI-generierter Code failt jedes Mal gleich. Ein LLM hat keinen schlechten Tag, keine Deadline und keinen Groll. Es hat eine Trainingsverteilung und einen Prompt. Also sind die Lücken systematisch, nicht zufällig: Es lässt Autorisierungsprüfungen weg, die der Prompt nicht erwähnte, es vertraut Input dem der Prompt nicht als feindselig markierte, es lässt Error Handling dünn, weil der Prompt den Erfolgsfall beschrieb. Systematische Lücken sind gute Nachricht, denn eine systematische Lücke lässt sich mit einer strukturierten Checkliste schließen, statt zu hoffen dass ein Reviewer sie zufällig bemerkt.

Beispiel für den Unterschied zu einem menschlichen Bug. Ein müder Engineer vergisst vielleicht zufällig die Validierung an einem von zwanzig Endpoints, und ein Reviewer überliest sie. Ein LLM, das zwanzig Endpoints bauen soll, behandelt Validierung tendenziell auf allen zwanzig gleich, wenn es also falsch ist, ist es konsistent falsch, und ein Reviewer der das Muster kennt fängt alle zwanzig auf einmal. Die Arbeit ist nicht „finde den zufälligen Fehler". Die Arbeit ist „bestätige die systematische Entscheidung des Modells und überstimme sie, wo Produktion mehr braucht". Das ist ein schnelleres, verlässlicheres Review als das Jagen menschlicher Einzelausrutscher.

Der ehrliche Trade-off: KI-generierter Code verschiebt Aufwand vom Schreiben zum Reviewen, und das spart nur Zeit, wenn das Review tatsächlich passiert. Überspring das Review und du hast vibe-coded Software mit schönerer Commit-History. Die Tools machen das Schreiben fast gratis, was Teams verleitet, genau den einen Schritt zu überspringen, der nie der Engpass war, den TDD- und Security-Durchlauf, der die systematischen Lücken fängt. Die Ersparnis ist nur real, wenn du einen Teil davon in das Review steckst, von dem du denkst du brauchst es nicht mehr.

Wavect behandelt KI-generierten Code als ersten Entwurf, der vor dem Ausliefern einen bekannten, wiederholbaren Production-Readiness-Durchlauf braucht, unter Software Quality Assurance. Weil die Lücken vorhersehbar sind, ist der Durchlauf schnell: Autorisierung auf jedem Endpoint, Validierung auf jedem Input, Secrets raus aus dem Client, Error Handling, dann eine Regressions-Suite und ein CI/CD-Gate, damit der nächste Prompt nicht lautlos ein Loch wieder aufreißt. So gemacht ist KI-generierter Code ein echter Produktivitätsgewinn statt eines stillen Bergs Technical Debt.

Wann das im Softwareprojekt zählt. Immer wenn ein LLM-Tool einen relevanten Teil des Codes geschrieben hat, der echte Nutzer sehen wird. Er ist nicht von Natur aus schlechter als handgeschriebener Code, aber er versagt jedes Mal gleich, also sind die Lücken systematisch, nicht zufällig.

Was Founder meistens falsch machen. Sie nehmen an, das Tool habe das Schreiben fast gratis gemacht, also überspringen sie das Review, den einen Schritt, der nie der Flaschenhals war. Überspringt man es, hat man vibe-coded Software mit einer schöneren Commit-Historie.

Wie Wavect damit umgeht. Wir behandeln KI-generierten Code als ersten Entwurf, der einen bekannten, wiederholbaren Production-Readiness-Durchlauf bekommt, und weil die Lücken vorhersehbar sind, ist der Durchlauf schnell. Der Leitfaden vom vibe-coded Prototyp zur Production beschreibt diese Härtung in der Praxis.

Produktionsreif ist der Unterschied zwischen Software, die funktioniert wenn du sie demost, und Software, die funktioniert wenn du schläfst und ein Fremder sie falsch benutzt. Es ist kein Gefühl und kein Meilenstein, den du ausrufst. Es ist eine konkrete Checkliste, und die Lücke zwischen Demo und produktionsreif ist exakt die Liste der Dinge, die keinen sichtbaren Payoff haben, bis zu dem Moment, in dem sie failen.

Die Checkliste, klar gesagt: Autorisierung auf jedem Endpoint, nicht nur Authentifizierung am Login; Input-Validierung auf allem, was eine Trust-Boundary überschreitet; keine Secrets im Client-Bundle oder im Repo; Error Handling, das fail-safe ist statt einen Stacktrace zu leaken; eine Regressions-Suite, die bei jeder Änderung läuft, damit der nächste Fix keinen alten Bug wieder aufreißt; Observability, damit du es von einem Dashboard erfährst, nicht von einem wütenden Kunden; und ein Rollback-Pfad in Minuten. Fehlt eines davon, hast du ein Demo im Produktions-Kostüm.

Beispiel. Zwei Versionen derselben Buchungs-App sehen im Demo identisch aus. Version A gibt eine Buchung per ID zurück, nachdem sie nur geprüft hat ob du eingeloggt bist. Version B prüft, dass der eingeloggte User diese Buchung tatsächlich besitzt, validiert das ID-Format, loggt den Zugriff und alertet wenn ein Account anfängt IDs durchzuzählen. Gleiche Screens, gleicher Happy Path, gleiches Demo. Version A ist ein Breach, der auf jemand Neugierigen wartet, Version B ist produktionsreif. Das user-sichtbare Produkt ist identisch, was genau der Grund ist, warum „es funktioniert im Demo" nichts über Produktionsreife aussagt.

Der ehrliche Trade-off: Produktionsreif zu werden kostet echte Zeit, und das meiste davon kauft nichts, was ein Kunde je sehen oder dir danken wird. Das ist genuin frustrierend, wenn ein Demo schon fertig aussieht, und der einzige Grund, warum Teams ausliefern bevor sie sollten. Der Deal ist für alles mit Userdaten nicht optional, aber es ist ehrlich zuzugeben, dass die Rechnung sich wie reiner Overhead anfühlt, bis der 3-Uhr-Alert oder der DSGVO-Brief sie zum billigsten Geld macht, das du je ausgegeben hast. Für einen echten Wegwerf-Prototyp ist das Überspringen die richtige Entscheidung.

Wavects Production-Readiness-Durchlauf ist die Brücke von einem vibe-coded oder KI-generierten Prototyp zu etwas, für das du Geld verlangen kannst, unter Software Quality Assurance. Wir arbeiten die Checkliste in der Reihenfolge des Blast-Radius ab: Autorisierung zuerst, weil dort die schlimmsten Bugs leben, dann Validierung, Secrets, Error Handling, dann die TDD-Regressions-Suite und das CI/CD-Gate, das sie grün hält. Das Ziel ist nicht Perfektion. Das Ziel ist, dass niemand um 3 Uhr nachts wegen etwas geweckt wird, das du vor dem Ausliefern hättest lesen können.

Wann das im Softwareprojekt zählt. Kurz bevor echte Nutzer kommen. Production-Ready ist die konkrete Linie zwischen Software, die in einer Demo läuft, und Software, die läuft, während du schläfst und ein Fremder sie falsch bedient.

Was Founder meistens falsch machen. Sie behandeln es als Gefühl oder als Meilenstein zum Ausrufen statt als Checkliste zum Abarbeiten. Der Großteil der Arbeit kauft nichts, das ein Kunde je sieht, weswegen Teams shippen, bevor sie sollten, bis die 3-Uhr-Nachts-Eskalation sie zum billigsten ausgegebenen Geld macht.

Wie Wavect damit umgeht. Wir arbeiten die Checkliste in der Reihenfolge des Blast-Radius ab, Autorisierung zuerst, dann Validierung, Secrets, Error Handling, dann die Regressions-Suite und das CI/CD-Gate. Die QA-Checkliste vor dem Launch und der Leitfaden vibe-coded Prototyp zur Production decken den vollen Durchlauf ab.

Scrum hat drei Rollen, drei Artefakte und eine Handvoll Events. Der Product Owner entscheidet, was gebaut wird und in welcher Reihenfolge. Der Scrum Master räumt Blockaden aus dem Weg und schützt den Prozess. Die Entwickler bauen es. Die Artefakte sind das Product Backlog (alles, was gebaut werden könnte), das Sprint Backlog (worauf sich dieser Sprint festlegt) und das Increment (was tatsächlich ausgeliefert wird). Die Events sind Sprint Planning, der Daily Standup, das Sprint Review und die Retrospektive.

Wo Scrum wirklich hilft: bei Teams, die mit Fokus und Sichtbarkeit kämpfen. Der feste Sprint erzwingt eine echte Festlegung, das Review erzwingt eine echte Demo, und die Retro zwingt das Team, den eigenen Prozess anzuschauen statt ihn zu ignorieren. Für ein Team, das noch nie in einem Takt geliefert hat, ist Scrum ein nützliches Gerüst.

Wo es zum Theater wird: wenn die Events überleben, aber die Substanz stirbt. Ein Standup, der ein Statusbericht an den Manager ist. Ein Review ohne lauffähige Software zum Zeigen. Eine Retro, die alle zwei Wochen dieselben drei Maßnahmen produziert und keine davon umsetzt. Viele Scrum-Teams führen die Zeremonien durch und holen keinen Wert daraus. Wenn ihr die Meetings macht, aber kein lauffähiges Increment demonstrieren könnt, habt ihr kein Scrum, sondern eine Meeting-Gewohnheit.

Praxisbeispiel für die Overhead-Falle: Ein fünfköpfiges Team führt Scrum nach Lehrbuch ein und landet bei Sprint Planning, einem Daily Standup, einer Backlog-Refinement-Session, einem Sprint Review und einer Retro alle zwei Wochen. Bei dieser Teamgröße kann diese Zeremonienlast gut den größeren Teil eines Tages pro Woche und Person fressen, und die Planungspräzision, die sie erkauft, ist verschwendet, weil ein fünfköpfiges Team ohnehin weiß, was alle tun. Das Framework wurde entworfen, um Teams zu koordinieren, die diese Sichtbarkeit verloren hatten; alles davon einem Team aufzuzwingen, das sie nie verloren hat, ist reine Steuer. Die Lösung ist nicht, die Feedback-Schleifen aufzugeben (behaltet die Demo und die Retro), sondern die Koordinationszeremonien zu streichen, die ein Problem lösen, das ihr nicht habt.

Wavects ehrliche Sicht: Scrum ist ein gutes Einstiegs-Framework und eine schlechte Religion. Behaltet die Teile, die Feedback erzeugen, und lasst die Teile weg, die Overhead erzeugen. Die meisten reifen Teams driften zu etwas Leichterem, oft näher an Kanban, sobald die Disziplin verinnerlicht ist.

Kanban hat zwei Kernideen: die Arbeit sichtbar machen und die laufende Arbeit begrenzen. Man stellt jedes Element auf ein Board mit Spalten für jede Phase (zu tun, in Arbeit, Review, fertig) und deckelt, wie viele Elemente gleichzeitig in jeder aktiven Spalte liegen dürfen. Ist eine Spalte voll, beginnt niemand neue Arbeit, bis etwas herauswandert. Dieser Deckel ist der ganze Punkt: Er zwingt das Team, Dinge fertigzustellen, bevor es mehr anfängt.

Der Kontrast zu Scrum ist der Takt. Scrum bündelt Arbeit in feste Sprints und plant an jeder Grenze neu. Kanban hat keine Sprints. Arbeit wird kontinuierlich gezogen, sobald Kapazität frei wird, und Prioritäten lassen sich jederzeit ändern, ohne das Ende eines Sprints abzuwarten. Es gibt keine Commitment-Zeremonie, kein Sprint Review, keine künstliche Zwei-Wochen-Box.

Wählt Kanban, wenn Arbeit unvorhersehbar und unterbrechungsgetrieben eintrifft (Support, Operations, Plattform-Teams) oder wenn ein Team reif genug ist, dass das Sprint-Gerüst zu reinem Overhead geworden ist. Wählt Scrum, wenn ein Team den Rhythmus und das erzwungene Review braucht, um Lieferdisziplin aufzubauen, oder wenn Stakeholder einen vorhersehbaren Demo-Takt zum Planen brauchen.

Praxisbeispiel, was ein WIP-Limit tatsächlich mit einem Team macht: Eine “in Arbeit”-Spalte, gedeckelt auf drei, bedeutet in einem fünfköpfigen Team, dass zwei Personen manchmal nichts Eigenes anzufangen haben. Der instinktive Reflex ist, das sei Verschwendung, untätige Entwickler. Es ist das Gegenteil. Diese zwei sind jetzt gezwungen, die drei laufenden Dinge mit fertigzustellen, die Arbeit eines Kollegen zu reviewen oder am Blocker zu pairen, statt eine vierte Aufgabe zu öffnen und das Team dünner zu verteilen. Das Unbehagen einer vollen Spalte ist der Mechanismus bei der Arbeit: Er verwandelt “alle beschäftigt, nichts wird ausgeliefert” in “weniger gleichzeitig, Dinge werden tatsächlich fertig”. Teams, die diese kurze Untätigkeit nicht aushalten, heben das Limit still an, bis es nichts mehr begrenzt, und wundern sich dann, warum der Durchsatz nicht stieg.

Die ehrliche Version: Bei den WIP-Limits liegt der Wert, und genau dieser Teil wird von Teams gerne stillschweigend ignoriert. Ein Kanban-Board ohne WIP-Limit ist nur eine To-do-Liste mit zusätzlichen Spalten. Wenn das Team fünf Dinge anfängt und keines fertigstellt, ist das Limit die Lösung, nicht ein größeres Board.

Technische Schuld ist eine Metapher, und eine gute. Wenn ihr eine Abkürzung nehmt, um schneller zu liefern (ein schneller Hack statt des sauberen Designs, ein hartkodierter Wert statt des Konfigurationssystems), borgt ihr euch jetzt Zeit und zahlt sie später als Zinsen zurück: Jede künftige Änderung in diesem Bereich ist langsamer, riskanter und nerviger. Wie eine Finanzschuld ist sie nicht automatisch schlecht. Sie ist ein Werkzeug.

Schulden bewusst aufzunehmen ist oft die richtige Entscheidung. Vor dem Product-Market-Fit schlägt Tempo Eleganz, denn das meiste, was ihr baut, wird ohnehin weggeworfen. Eine makellose Architektur für ein Produkt zu bauen, das es in sechs Monaten vielleicht nicht mehr gibt, ist eine eigene Art von Verschwendung. Der richtige Zug ist häufig, die Abkürzung zu nehmen, zu liefern, zu lernen und die Schuld abzubauen, sobald ihr wisst, dass die Sache es wert ist.

Die Gefahr ist nicht die Schuld. Die Gefahr ist die unsichtbare Schuld. Bewusste, dokumentierte Schuld (“wir haben das hartkodiert, hier ist das Ticket, es vor dem Skalieren zu beheben”) ist eine gemanagte Verbindlichkeit. Undokumentierte Schuld, die niemand zu nehmen beschlossen hat, die einfach durch Hektik und Personalwechsel angewachsen ist, ist der Wildwuchs, der eine Codebasis langsam erwürgt. Das Tempo sinkt, niemand kann sagen warum, und jede Schätzung verdoppelt sich. Wenn es in den Metriken sichtbar wird, häufen sich die Zinszahlungen schon seit einem Jahr.

Wavects Haltung: Schuld ist ein bewusster Trade-off, kein moralisches Versagen. Wir nehmen gerne Schulden auf, um ein Zeitfenster zu treffen, und wir schreiben genau auf, was wir genommen haben und was die Rückzahlung kostet. Das Gespräch, das wir nicht auslassen, ist das, in dem jemand Zinsen zahlt und niemand den Kredit benannt hat. Seht euch unsere Full-Stack-Entwicklungsarbeit an, wie wir diesen Trade-off explizit halten.

Wann das im Softwareprojekt zählt. Ständig, aber am härtesten kurz vor dem Launch und beim Skalieren, wenn angehäufte Abkürzungen sich in langsamere Auslieferung und verdoppelte Schätzungen verwandeln, die niemand erklären kann.

Was Founder meistens falsch machen. Sie behandeln jede Schuld als schlecht und geraten in Panik, oder ignorieren sie, bis sie unsichtbar ist. Die Gefahr ist nie bewusste, dokumentierte Schuld; es ist die Cruft, die durch Eile und Fluktuation entstand, die niemand gewählt hat und niemand sehen kann.

Wie Wavect damit umgeht. Wir nehmen Schulden bewusst auf, um ein Zeitfenster zu treffen, und schreiben genau auf, was wir genommen haben und was die Rückzahlung kostet. Die QA-Checkliste vor dem Launch ist der Ort, an dem wir die Schuld aufdecken, die sonst still mitshippen würde.

DevOps begann als Reaktion auf eine bestimmte Dysfunktion: Entwickler warfen Code über eine Mauer zu einem separaten Operations-Team, Ops bekam die Schuld, wenn etwas kaputtging, und die Feedbackschleife zwischen Schreiben und Betreiben von Software war zerbrochen. DevOps schließt diese Schleife. Das Team, das die Software baut, liefert sie auch aus und betreibt sie, und der Schmerz des Betriebs fließt direkt zurück zu den Leuten, die ihn beheben können.

In der Praxis wird diese Kultur durch Automatisierung ermöglicht: CI/CD, damit Änderungen sicher und oft in die Produktion fließen, Infrastructure as Code, damit Umgebungen reproduzierbar sind statt handgebaute Unikate, und Observability (Logs, Metriken, Traces, Alerts), damit das Team sieht, was die Produktion tatsächlich tut. Keines dieser Werkzeuge ist für sich genommen DevOps. Sie sind das, was die Kultur überlebensfähig macht.

Der Jobtitel “DevOps Engineer” ist meist eine Fehlbezeichnung, und eine aufschlussreiche. DevOps ist keine Rolle, die man zwischen Dev und Ops setzt, das baut nur die Mauer mit neuem Namen wieder auf. Was die meisten “DevOps Engineer”-Stellen eigentlich wollen, ist ein Plattform- oder Infrastruktur-Engineer, der die Automatisierung baut, die andere Entwickler nutzen. Nützliche Person, falsches Etikett. Wenn eure Organisation ein DevOps-Team hat, das Deploys übernimmt, damit Entwickler es nicht müssen, habt ihr Ops mit einem Rebranding, kein DevOps.

Wavects Sicht: DevOps ist eine Arbeitsweise, keine Abteilung. Wir bauen die Automatisierung, die ein kleines Team befähigt, seine Software durchgängig zu verantworten, und behandeln “you build it, you run it” als Standard. Seht euch unsere Full-Stack-Entwicklungsarbeit an, wie das in der Praxis aussieht.

Waterfall führt ein Projekt als geordnete Folge von Phasen durch: alle Anforderungen sammeln, dann das ganze System designen, dann bauen, dann testen, dann ausliefern. Jede Phase produziert ein abgenommenes Dokument und wird abgeschlossen, bevor die nächste beginnt. Der Reiz ist offensichtlich: Ihr kennt Plan, Kosten und Termin im Voraus, und alle stimmen zu, bevor eine Zeile Code geschrieben ist.

Für manche Arbeit passt es weiterhin legitim. Wenn der Umfang wirklich fest und gut verstanden ist, wenn ein Regulator vorab Dokumentation und Nachvollziehbarkeit verlangt, oder wenn ihr Hardware baut, bei der ihr nach dem Schnitt des Metalls nicht billig iterieren könnt, sind sequenzielle Phasen das ehrliche Modell. So ein Projekt als “agil” auszugeben, versteckt nur den Plan, statt ihn zu entfernen.

Der Vertragsaspekt ist der Punkt, an dem Waterfall und Agile am konkretesten kollidieren. Ein Fixpreis-Werkvertrag braucht nach österreichischem und deutschem Recht ein definiertes Werk, an das der Auftragnehmer gebunden ist, was naturgemäß zu einem waterfall-förmigen, vollständig spezifizierten Umfang drängt. Echt iterative Arbeit, bei der ihr erwartet, dass sich die Anforderungen mit dem Lernen ändern, passt besser zu einem Dienstvertrag oder einem Retainer. Founder geraten in Schwierigkeiten, wenn sie die Rechtssicherheit eines Fixpreises und die Flexibilität von Agile gleichzeitig wollen: Das zieht in entgegengesetzte Richtungen. Die ehrliche Auflösung ist meist eine Fixpreis-Discovery, um genug Umfang festzunageln, um darauf einen Preis zu fixieren, und dann der Build mit so viel Durchlässigkeit der Grenzen, wie die verbleibende Unsicherheit tatsächlich rechtfertigt.

Bei Produktdiscovery scheitert es schwer. Die fatale Annahme ist, dass ihr das richtige Produkt im Voraus spezifizieren könnt, bevor irgendein Nutzer es berührt hat. Das könnt ihr fast nie. Wenn die Bauphase endet, sind die Monate zuvor gesammelten Anforderungen teilweise falsch, und Waterfall hat keinen billigen Weg, das vor der Testphase herauszufinden, in der jede Änderung teuer ist. Ihr bekommt ein Produkt, das der Spezifikation entspricht und am Bedarf vorbeigeht.

Die ehrliche Abgrenzung zu Agile: Waterfall lädt alle Entscheidungen nach vorn und wettet, dass sie richtig sind. Agile verteilt Entscheidungen über die Arbeit und wettet, dass frühes Feedback die falschen abfängt. Bei allem, wo ihr noch nicht genau wisst, was ihr bauen sollt, begünstigt diese Wette Agile. Bei allem, wo die Antwort wirklich bekannt und fest ist, ist die Vorhersehbarkeit von Waterfall ein Vorteil, kein Mangel.

Eine User Story erfasst ein Stück Wert aus der Perspektive der Person, die es will, meist im Format “Als [Rolle] möchte ich [Ziel], damit [Nutzen]”. Das Format ist keine Bürokratie um ihrer selbst willen. Das “Als” zwingt euch, zu benennen, wer das tatsächlich will, und das “damit” zwingt euch, das Warum zu nennen, also den Teil, den Teams überspringen und dann das Falsche bauen. Eine Story ist ein Platzhalter für ein Gespräch, kein Vertrag.

Gute Stories erfüllen meist die INVEST-Kriterien: Independent (eigenständig baubar), Negotiable (die Details bleiben offen, bis ihr sie besprecht), Valuable (liefert etwas, das einem Nutzer oder Käufer wichtig ist), Estimable (das Team kann sie schätzen), Small (passt in eine Iteration) und Testable (man kann erkennen, wann sie fertig ist). An den letzten beiden scheitern die meisten Stories: zu groß zum Fertigstellen oder so vage geschrieben, dass niemand sagen kann, was “fertig” bedeutet.

Akzeptanzkriterien sind, wie eine Story testbar wird. Sie sind die konkreten Bedingungen, die gelten müssen, damit die Story angenommen wird, geschrieben bevor die Arbeit beginnt. “Als Nutzer möchte ich mein Passwort zurücksetzen” ist eine Absicht. Die Akzeptanzkriterien (ein Reset-Link verfällt nach einer Stunde, ein ungültiges Token zeigt einen klaren Fehler, ein erfolgreiches Zurücksetzen meldet den Nutzer an) sind das, wogegen das Team tatsächlich baut und testet.

Das häufige Anti-Pattern ist die Story, die eine verkleidete Aufgabe ist. “Als Entwickler möchte ich einen Index auf der Orders-Tabelle hinzufügen” trägt das User-Story-Kostüm, aber es gibt keinen Nutzer und keinen Nutzen, nur eine technische Aufgabe mit Hut. Das zu tracken ist in Ordnung, aber es ist keine User Story, und technische Aufgaben als Stories zu verkleiden löscht still die Nutzerperspektive, zu deren Schutz das Format existiert."