Was Startup-CTOs wirklich bauen vs. was Pitch Decks versprechen
Wir bauen MVPs für Startups. Das bedeutet, wir sehen sowohl das Pitch Deck als auch den Produktionscode. Die beiden sind nie identisch. Und das ist kein Problem — so sollen Startups funktionieren.
Aber niemand spricht darüber. Gründer tragen stille Schuldgefühle über die Kluft zwischen dem, was sie Investoren präsentieren, und dem, was tatsächlich in Produktion läuft. Engineers fühlen sich wie Hochstapler, weil ihre „Plattform" eine Next.js-App mit 30 API-Routes ist.
Lasst uns das normalisieren.
Der Übersetzungsguide
„KI-gestützte Plattform"
Pitch-Deck-Version: Ausgefeilte Machine-Learning-Modelle, trainiert auf proprietären Daten, die sich durch Nutzerinteraktionen kontinuierlich verbessern und personalisierte Erlebnisse im großen Maßstab liefern.
Was tatsächlich läuft:
const response = await openai.chat.completions.create({
model: "gpt-4o-mini",
messages: [
{ role: "system", content: SYSTEM_PROMPT },
{ role: "user", content: userInput },
],
temperature: 0.3,
});
return response.choices[0].message.content;Ein OpenAI-API-Call mit einem gut geschriebenen System Prompt. Entwicklungszeit: 2 Stunden. Monatliche Kosten: 30 €.
Warum das okay ist: Der Wert liegt nicht im Modell — er liegt darin, zu wissen, was man fragt und wie man das Ergebnis präsentiert. Der System Prompt hat 3 Wochen User-Testing gebraucht. Dort steckt die eigentliche Produktintelligenz.
„Skalierbare Microservice-Architektur"
Pitch-Deck-Version: Event-gesteuerte Microservice-Architektur mit unabhängiger Skalierung, Blue-Green Deployment und Auto-Scaling basierend auf Lastmustern.
Was tatsächlich läuft:
myapp/
├── app/ # Next.js Frontend + API Routes
├── prisma/ # Datenbank-Schema
├── lib/ # Business Logic
└── docker-compose.yml # Ein Container
Ein Monolith. Ein Prozess. Eine Datenbank. Deployed mit docker compose up.
Warum das okay ist: Das Pitch Deck beschreibt, wo die Architektur in Jahr 3 mit einem 15-köpfigen Team sein wird. Der Monolith ist da, wo er in Monat 6 mit einem 3-köpfigen Team sein muss.
„Proprietärer Algorithmus"
Pitch-Deck-Version: Ein ausgefeilter Matching-Algorithmus, der 47 Faktoren berücksichtigt, um optimale Empfehlungen zu liefern.
Was tatsächlich läuft:
SELECT
p.*,
(
CASE WHEN p.category = $1 THEN 30 ELSE 0 END +
CASE WHEN p.price BETWEEN $2 AND $3 THEN 25 ELSE 0 END +
CASE WHEN p.location_km <= $4 THEN 20 ELSE 0 END +
CASE WHEN p.rating >= 4.0 THEN 15 ELSE 0 END +
CASE WHEN p.verified = true THEN 10 ELSE 0 END
) AS relevance_score
FROM products p
WHERE p.active = true
ORDER BY relevance_score DESC
LIMIT 20;Eine SQL-Query mit gewichteter Bewertung. Fünf Faktoren, nicht siebenundvierzig. Die Gewichte wurden vom Gründer nach Bauchgefühl gesetzt und dann anhand des Nutzerverhaltens angepasst.
Warum das okay ist: Diese Query bedient 10.000 Nutzer. Wenn sie schlauer werden muss, kommen die Trainingsdaten für ein echtes ML-Modell von den Interaktionen dieser Nutzer mit dem „dummen" Algorithmus.
Jede Recommendation Engine bei jedem großen Unternehmen hat als SQL-Query angefangen. Netflix' frühe Empfehlungen waren redaktionelle Picks. Spotify's Discover Weekly startete als Hack-Week-Projekt. Der „proprietäre Algorithmus" in eurem Pitch Deck ist die Wahrheit von morgen, finanziert durch die SQL-Query von heute.
„Enterprise-Grade Security"
Was tatsächlich läuft:
// Auth: better-auth mit E-Mail/Passwort
// RBAC: Zwei Rollen
type UserRole = "user" | "admin";
// „Verschlüsselung": HTTPS (Caddy macht das automatisch)
// „Security Monitoring": Sentry Error AlertsHTTPS, gehashte Passwörter, zwei Rollen und Error Tracking. Kein SOC-2-Audit. Kein Penetrationstest.
Warum das okay ist: Das MVP hat 200 Nutzer und verarbeitet keine Finanzdaten direkt (das macht Stripe). Die Sicherheitsanforderungen sollten zum Bedrohungsmodell passen, nicht zu dem einer Bank.
„Cross-Platform Mobile Application"
Was tatsächlich läuft:
{
"name": "MyApp",
"display": "standalone",
"start_url": "/"
}Eine responsive Next.js-App, die auf Mobilgeräten gut aussieht. Kein App Store. Kein nativer Code.
Warum das okay ist: 90 % der MVP-Nutzer werden nie eine native App installieren. Eine gute mobile Web-Experience validiert das Produkt.
Das Impostor-Syndrom des Gründers
Wenn ihr diese Beispiele lest und denkt „oh nein, das ist exakt mein Produkt" — gut. Ihr seid in bester Gesellschaft.
Stripe startete als 7 Zeilen JavaScript. Das MVP von Dropbox war ein Demo-Video. Airbnbs erste „Plattform" war eine WordPress-Seite mit PayPal-Buttons.
Das Pitch Deck verkauft die Vision. Der Code beweist das Geschäftsmodell. Die sollen unterschiedlich sein.
Gute Investoren wissen, dass das Pitch Deck aspirativ ist. Sie investieren nicht in euren aktuellen Code — sie investieren in eure Fähigkeit, die Vision umzusetzen.
Wann die Kluft zum Problem wird
Die Kluft ist gesund, bis sie es nicht mehr ist. Achtet auf diese Signale:
- Ihr versprecht Features, die mit eurer aktuellen Architektur physisch nicht baubar sind.
- Ihr versteckt technische Limitierungen vor Kunden. Das wird im großen Maßstab zum Betrug.
- Ihr sagt Engineers, sie sollen die Pitch-Deck-Version bauen. Ein MVP für die Investorenpräsentation over-engineeren ist der schnellste Weg, euer Marktfenster zu verpassen.
Das Fazit
Der Code eures Startups ist einfacher, als euer Pitch Deck vermuten lässt. Das ist kein Geständnis — das ist Strategie.
Einfacher Code shippt schneller. Einfacher Code bricht seltener. Einfacher Code ist leichter zu ändern, wenn der Markt euch zum Pivot zwingt.
Baut die einfache Version. Validiert das Geschäftsmodell. Dann verdient euch das Recht, die komplexe Version zu bauen.
Das Pitch Deck verkauft die Zukunft. Der Code beweist die Gegenwart. Beide machen ihren Job.
