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, ausgeliefert über unser Fractional-Co-Founder-Modell. Ein Operator joint Cap Table oder Vertrag, 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 Koordinations-Tax. 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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."