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.

Bei Wavect ist ein CTPO meist fractional. 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.

Das Risiko: eine Person wird zum Single Point of Failure. Die Mitigation: 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."

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 älteste Engineer. Er ist der Operator, der entscheidet, welche Feuer gelöscht und welche bewusst stehengelassen werden.

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

Häufigster Fehler: einen Scale-up-CTO einstellen, wenn die Firma einen Founding braucht. CV beeindruckt, Runway verdampft in sechs Monaten. Profil und Stage müssen zusammenpassen.

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.

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.

Vor PMF ist ein dedizierter CPO meist Overkill. Die Rolle wird vom Founder oder vom CTPO absorbiert, bis das Engineering-Team so groß ist, dass jemand Vollzeit über das nächste Was-bauen-wir nachdenken muss.

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. 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 endendes Zwei-Wochen-Pilot ist ein besseres Ergebnis als ein sechsmonatiger Vertrag, der sich dahinschleppt.

Wir sind nicht für jeden. Wer einen Körper für Tickets braucht, soll einen Contractor nehmen. Wer jemanden braucht, der die Roadmap hinterfragt, sonntags um 23 Uhr eine harte Architekturentscheidung mitträgt und einem sagt, wenn das Lieblings-Feature das falsche ist, will dieses Engagement-Modell.

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: er trifft Architekturentscheidungen, führt den Hiring-Loop für Senior Engineers, sitzt in Beiratssitzungen, schreibt die technischen Teile der Investor-Decks.

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 Werkvertrag macht die Grenze explizit.

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

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 nicht teilen will, erzeugt ein Fractional CPO Reibung."

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.

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. Beide Rollen zu vermischen ist der häufigste Fehler in Series-A-Startups."

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.

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

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. Ein Time-&-Material-Vertrag im selben Rechtsrahmen ist ein Dienstvertrag, der nur Aufwand schuldet. Wavects Fixed-Price-Engagements sind Werkverträge.

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. Das ist nicht juristisch verschnörkelt; das ist die einzige Art, wie beide Seiten sich darauf einigen können, was „fertig" heißt, ohne sechs Monate später zu streiten."

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.

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 Werkvertrag ohne juristische Verbindlichkeit ist.

Wavect nutzt T&M für explorative Engagements, in denen der Scope tatsächlich noch nicht definierbar ist. Wir nutzen es nicht als Default. Wer T&M für Arbeit verkauft, die einen klaren Output hat, 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. „Fixed Price" als mündliche Zusage über einem Time-&-Material-Vertrag ist kein Fixpreis; das ist ein Marketingsatz.

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.

Wavects Fixpreis-Garantie bedeutet: unterzeichneter Werkvertrag, rechtlich an Lieferung gebunden. Sie bedeutet nicht Rückerstattung bei Fristüberschreitung."

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 Werkvertrag mithalten könnte. Produktteams nutzen Retainer für Designpartner, Engineering-Teams für fractional Senior-Rollen, und fast jede juristische Beratung ist ein Retainer.

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. Liegt die Auslastung unter 60 %, ist der Retainer die falsche Form und ein per-Engagement-Werkvertrag passt besser."

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 lässt sich ein echter Fixpreis ableiten.

Wavect betreibt Discovery als 2- bis 3-wöchiges Fixpreis-Engagement zu 3.500 EUR. Bei Folgeauftrag wird die Discovery-Gebühr von der ersten Build-Rechnung abgezogen. Andernfalls behältst du alle vier Artefakte und kannst sie zu einem anderen Anbieter mitnehmen.

Der Grund, Discovery zu bepreisen: Kostenlose Scoping-Arbeit ist entweder unehrlich (der Anbieter holt sich die Kosten im Build wieder) oder qualitativ schlecht (der Anbieter macht sie schnell, weil sie unbezahlt ist). Bepreisen behebt das Incentive."

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.

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

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 darüber ab. Wavect baut in diesem Feld über EVM (Ethereum und kompatible Chains), Solana, Cosmos, Polkadot, Near, Ton und ICP.

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; permissionless Composability), sind wertvoll. Der Rest sind VC-finanzierte Ablenkungen. 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 fertige Circuits für gängige Beweise (Identität, Saldo, Wahlberechtigung) an, sodass kein Kryptograph im Haus nötig ist.

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

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

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

Wavects Haltung: zuerst fragen, ob KI hier das richtige Werkzeug ist, dann fragen, ob ein Agent die richtige Form von KI ist. Die meisten Workflows, die als „agentisch" gepitcht werden, sind besser als deterministische Pipeline mit einem LLM-Call in der Mitte aufgehoben."

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.

Praktisch heißt das Hebel. Interne Tools, Datenbanken und APIs, in einen MCP-Server verpackt, werden für jenes LLM nutzbar, mit dem das Team in diesem Quartal arbeitet, ohne Umbau beim Wechsel. Trade-off: MCP ist jung. Tooling, Sicherheitsmodelle und Audit-Patterns reifen noch. Wir bauen MCP-Server regelmäßig und haben sie in Produktion ausgeliefert; jedes Mal schreiben wir trotzdem ein Security-Review, weil der Standard sich bewegt."

RAG ist die Architektur, die einem LLM erlaubt, Fragen zu Daten zu beantworten, auf denen es nie trainiert wurde. Mechanik: Frage des Nutzers nehmen, die relevantesten Chunks aus deinem Korpus per Vector-Search, Keyword-Search oder Hybrid abrufen, in den Prompt packen, Modell antworten lassen.

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.

Unsexy Wahrheit zu RAG: 80 % der Arbeit ist gutes Retrieval (Chunking, Embeddings, Reranking, Hybrid Search), 20 % das Modell selbst. 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.

Wavect schreibt Smart Contracts in Solidity (EVM-Chains) und Rust (Solana, Near, ICP). Für jeden Contract, der nicht-triviale Werte hält, empfehlen wir ein Drittanbieter-Audit vor Mainnet-Deployment. Wir haben auditierte Contracts in Produktion ausgeliefert; das Audit kostet meist 1 bis 2 Wochen des Build-Budgets."

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 jenes EVM-Chain deployen, das 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.

Achtung: EVM-kompatibel ist nicht dasselbe wie Ethereum-äquivalent. Subtile Unterschiede in Gas-Pricing, Precompiles und Konsensverhalten erwischen Teams, die ohne Re-Testing pro Chain deployen."

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.

Wavect liefert sowohl in Solana als auch in EVM. 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. 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.

LoRaWAN ist die richtige Wahl, wenn man viele Sensoren über große Fläche mit mehrjähriger Batterielaufzeit braucht. Falsch, wenn hohe Bandbreite, niedrige Latenz oder per-Device-Mobilfunk-Verträge nötig sind (5G NB-IoT passt besser auf die letzten beiden)."

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.

Die nützlichste Frage an ein Team, das sagt „wir machen Agile": Wann hat sich der Plan zuletzt aufgrund der letzten Wochen-Auslieferung geändert? Antwort: nie? Dann macht das Team Wasserfall in Zwei-Wochen-Häppchen.

Wavect ist agile im ursprünglichen Sinn: kurze Zyklen, häufige Demos, Bereitschaft, falsch erkannte Arbeit wegzuwerfen. Wir sind skeptisch gegenüber der Zertifikatsindustrie-Version von Agile, bei der Meeting-Kadenz zum Selbstzweck 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.

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.

Wavect nutzt TDD, wo es sich rechnet: Integrationstests für alles Geldbezogene, Contract-Tests für Customer-Facing-Sachen, Unit-Tests für nicht-triviale Logik. Wir testen keine Getter und Setter. Coverage als Ziel ist eine Metric, die gegamed wird."

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.

Praktisch liegt der Wert am höchsten auf Integration und Akzeptanztest-Ebene, wo die Sprachbarriere zwischen Engineering und Produkt tatsächlich Bugs erzeugt. Auf Unit-Test-Ebene addiert BDD mehr Zeremonie, als es spart."

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.

Häufigster Fehler: das MVP bauen, das man sich vor sechs Monaten vorgestellt hat, statt jenes MVP, das die diese-Woche-unsicherste Annahme testet. Jede Woche ändert sich, welche Annahme zu testen wäre. Die meisten MVPs sind veraltet, bevor sie shippen.

Wavects Discovery-Phase existiert auch, um das zu beheben. Vor dem MVP-Scope benennen wir die Hypothese, die das MVP testen soll. Lautet die Hypothese „Nutzer wollen Feature X", ist das MVP nicht ein poliertes Feature X, sondern der billigste Weg, das herauszufinden."

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 Nutzer, Presse und Cap Table dich gleichzeitig ziehen 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 wandeln sich die Fragen zu operativen: Team skalieren, Stack härten, Burn kontrollieren.

Warum das für Engineering-Entscheidungen zählt: Ein Pre-PMF-Team, das für Skalierung überbaut, verbrennt Runway. Ein Post-PMF-Team, das unterbaut, wird vom eigenen Erfolg gefressen. Wavect engagiert sich entlang dieser Linie unterschiedlich. Vor PMF: günstigste lauffähige Version, die Lernen erlaubt. Nach PMF: härten, dokumentieren, wieder schlafen können."

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

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

Wavects bevorzugte Form: Discovery vorne, Design und Build kurz verschränkt, automatisierter Test und Deploy 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 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.

Wavect liefert jedes Projekt mit CI von Tag eins. CD-Konfiguration hängt davon ab, ob Projekt Testabdeckung und operative Disziplin hat, um sicher zu sein. Wir sagen dir, welche Variante zutrifft."

Continuous Delivery ist die verantwortliche Cousine von Continuous Deployment. Jede Änderung durchläuft dieselbe automatisierte Build-, Test- und Release-Vorbereitungs-Pipeline. 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 nichts mehr signalisiert."