Tech-Due-Diligence für Nicht-Techniker: Fragen an deinen Co-Founder

Du bist Feuer und Flamme für deine Startup-Idee, kennst deinen Markt, kannst pitchen – aber wenn dein potenzieller Tech-Co-Founder über Architektur, Frameworks und Skalierung spricht, hörst du innerlich nur: „…Bzzz… Kubernetes… irgendwas mit Microservices…“.

Genau hier scheitern viele frühe Teams: Der Business-Gründer vertraut blind auf den Techie – oder blockt alles ab, weil er es nicht versteht. Beides ist gefährlich. Du musst nicht programmieren können, aber du solltest die technischen Entscheidungen deines Co-Founders verstehen, challengen und mittragen können.

In diesem Artikel bekommst du einen praxisnahen Leitfaden für deine eigene kleine Tech-Due-Diligence als Nicht-Techniker – speziell für frühe DACH-Startups und Gründerduos. Du lernst:

• welche Fragen du zu Architektur & Roadmap stellen solltest,
• wie du ohne Code-Kenntnisse Skalierbarkeit & Wartbarkeit einschätzen kannst,
• woran du erkennst, ob jemand verantwortungsvoll mit Tech-Schulden umgeht,
• wie ihr gemeinsam Build-vs-Buy-Entscheidungen trefft,
• und welche Red Flags du im Gespräch mit einem potenziellen Co-Founder ernst nehmen solltest.

Warum du als Nicht-Tech-Gründer Tech-Due-Diligence machen musst

Viele Nicht-Tech-Gründer glauben: „Dafür habe ich ja einen Tech-Co-Founder.“ Das ist ungefähr so, als würdest du sagen: „Finanzen? Dafür hab ich doch den Steuerberater.“ – und dann überrascht sein, wenn dir nach drei Jahren das Geld oder die Liquidität ausgeht.

Technologie ist in einem Startup kein Nebenkriegsschauplatz, sondern Teil deines Kernprodukts, deiner Unit Economics und deines Risiko-Profils. Investoren fragen immer: „Wie robust ist euer Tech-Setup? Wie abhängig seid ihr von einer Person? Wie schnell könnt ihr iterieren?“

Du brauchst keine Fachbegriffe. Du brauchst klare Modelle im Kopf und ein paar gute Fragen. Wenn du die Antworten in deinen eigenen Worten wiedergeben kannst, ist das ein gutes Zeichen. Wenn nicht, habt ihr ein Problem – entweder in der Erklärung oder in der Entscheidung.

Grundlagen klären: Was ihr überhaupt baut

Bevor du in Details zu Tech-Stack & Architektur gehst, musst du das Spielfeld klären. Stelle deinem (potenziellen) Tech-Co-Founder Fragen, die dich vom Buzzword-Nebel zur Klarheit bringen.

1. Produkt-Typ & Komplexität

Frage:

• „Was sind die drei wichtigsten Dinge, die unsere Software in den ersten 12 Monaten können muss?“

Du willst eine Antwort, die in Funktionen und Use Cases denkt, nicht in Technologien. Zum Beispiel:

• „User können ein Profil anlegen und bearbeiten.“
• „Es gibt ein Matching basierend auf X, Y, Z.“
• „User erhalten wöchentliche Empfehlungen per E-Mail.“

Wenn jemand direkt mit Tech-Details startet („Wir nehmen React Native mit Firebase…“), hake nach:

• „Okay, verstanden. Was davon ist für den Nutzer konkret sichtbar und relevant?“

2. Architektur in einfachen Bildern

Eine gute Tech-Person kann Komplexes einfach erklären. Bitte sie, eure geplante Architektur als Skizze oder Metapher zu erklären:

• „Kannst du unsere Architektur so erklären, als würdest du sie einem Investor ohne Tech-Background erklären?“

Achte auf Antworten, die auf einer groben Ebene bleiben:

• „Wir haben ein Frontend (App/Web), ein Backend (Server, der Logik macht) und eine Datenbank. Die App spricht mit dem Backend, das kümmert sich um Sicherheit und Daten.“
• „Später können wir das Backend in mehrere Services aufteilen, wenn der Traffic steigt – aber am Anfang starten wir bewusst einfach.“

Wenn du nach 10 Minuten Gespräch noch keinen high-level Überblick hast, stimmt etwas nicht – entweder in der Kommunikation oder im Denken.

Fragen zur Skalierbarkeit: Wächst das Ding mit, wenn ihr Erfolg habt?

Skalierbarkeit bedeutet nicht „Wir können theoretisch 100 Millionen User bedienen“. Für frühe DACH-Startups heißt es vor allem: „Können wir ohne Komplett-Neubau wachsen?“

3. Kurzfristige vs. langfristige Skalierung

Stelle Fragen, die zwischen den nächsten 12–24 Monaten und der fernen Zukunft unterscheiden:

• „Für welche Größenordnung planen wir realistisch in den nächsten 18 Monaten? (User, Datenvolumen, Transaktionen)“
• „Was wäre das erste, was bei starkem Wachstum zum Engpass wird?“
• „Wie aufwendig wäre es, diesen Engpass zu beseitigen – Tage, Wochen, Monate?“

Du suchst nach konkreten Szenarien, keine Phrasen. Gute Antworten klingen z.B. so:

„Wir planen zunächst mit 5–10k aktiven Usern. Der erste Flaschenhals wäre unsere Datenbank-Struktur beim Matching. Das könnte ich mit ein paar Tagen Arbeit optimieren oder auf einen größeren Managed-Service migrieren, ohne alles neu zu bauen.“

4. Kosten der Skalierung

Skalierbarkeit ist auch eine Kostenfrage. Frage:

• „Wie entwickeln sich unsere Infrastruktur-Kosten, wenn wir von 1.000 auf 10.000 und auf 100.000 aktive User wachsen?“

Du brauchst keine exakten Zahlen, aber eine grobe Kostenlogik (z.B. „exponentiell teuer“ vs. „relativ linear“). Red Flag: Keine Vorstellung von Kosten, kein Monitoring geplant, vages „Wird schon irgendwie“.

Security & Daten: Wie verantwortungsvoll wird mit Risiko umgegangen?

Gerade im DACH-Raum sind Datenschutz, Compliance und Security schnell geschäftskritisch. Du musst das nicht im Detail beherrschen, aber du solltest sehen, dass dein Co-Founder risikobewusst ist.

5. Datenarten & Sensitivität

Klärt erst, welche Daten ihr verarbeitet:

• „Welche Arten von Daten speichern wir? (z.B. E-Mail, Zahlungsdaten, Gesundheitsdaten, Standort)“
• „Welche davon wären kritisch, wenn sie öffentlich werden?“

Je sensibler die Daten, desto wichtiger sind Themen wie Verschlüsselung, Zugriffskontrolle und Backups.

6. Konkrete Security-Maßnahmen in Phase 1

Frage nicht abstrakt nach „Security“, sondern ganz konkret:

• „Welche 3–5 konkreten Sicherheitsmaßnahmen setzen wir ab Tag 1 um?“
• „Wie stellen wir sicher, dass nicht jeder alles in der Datenbank sehen oder ändern kann?“
• „Wie gehen wir mit Passwörtern und Logins um?“

Ziel ist kein Enterprise-Level-Security-Monster, sondern sinnvoller Basisschutz:

• Passwörter gehasht & gesalzen, niemals im Klartext
• HTTPS überall, keine sensiblen Daten unverschlüsselt übertragen
• Minimalprinzip bei Rechten: nicht jede Komponente kann alles
• Regelmäßige Backups, idealerweise automatisiert

Red Flag: „Security machen wir, wenn wir größer sind“ – das ist wie „Bremsen kümmern wir uns, wenn das Auto schneller fährt“.

Umgang mit Tech-Schulden: Bewusstes Schuldenmachen vs. Chaos

Tech-Schulden sind wie finanzielle Schulden: Manchmal sinnvoll, manchmal toxisch. Schnell etwas „dirty“ zu bauen, um zu testen, kann klug sein – solange ihr wisst, wo die Schulden liegen und wann ihr sie zurückzahlt.

7. Schulden-Bewusstsein

Gute Tech-Leute wissen genau, wo sie Abkürzungen nehmen. Frage:

• „Wo planen wir bewusst Abkürzungen zu nehmen, um schneller zu testen?“
• „Wie machen wir diese Tech-Schulden sichtbar – z.B. in Tickets oder Dokumentation?“

Du willst hören, dass es bewusste Entscheidungen sind, keine Zufallsprodukte. Beispiele:

• „Wir bauen das Admin-Panel erstmal sehr rudimentär, alles andere wäre Overkill.“
• „Wir nutzen anfangs eine einfache NoSQL-Struktur, wissen aber, dass wir später migrieren müssen.“

8. Rückzahl-Plan

Frage direkt nach dem Plan:

• „Unter welchen Bedingungen würden wir welche Tech-Schulden zurückzahlen?“
• „Gibt es eine Daumenregel, wie viel Zeit wir pro Sprint für Refactoring/Qualität reservieren?“

Gute Praxis: 10–20 % der Entwicklungszeit sind für Refactoring, Tests, Aufräumen reserviert, gerade in frühen Phasen. Wenn dein Co-Founder jede Art von Qualitätssicherung als „Luxus“ abtut, ist das ein Risiko für eure Zukunftsfähigkeit.

Build vs. Buy: Was baut ihr selbst – und was nicht?

Einer der wichtigsten Hebel für frühe Startups: nicht alles selbst bauen. Genug Gründerduos haben Monate mit Login-Systemen, Payment und Chat verbracht, statt das eigentliche Problem zu lösen.

9. Kern vs. Nicht-Kern

Definiert gemeinsam, was euer Kern ist:

• „Welche 1–2 Dinge sind so zentral für unser Produkt, dass wir sie langfristig selbst beherrschen wollen?“
• „Was ist Commodity (Standard-Funktion), die wir lieber zukaufen oder mit bestehenden Tools lösen?“

Typische Nicht-Kern-Bereiche, die sich oft fürs Zukaufen eignen:

• Authentifizierung & Login (z.B. Auth0, Firebase Auth)
• Zahlungsabwicklung (z.B. Stripe, Mollie)
• E-Mail-Versand (z.B. SendGrid, Mailgun)

10. Entscheidungslogik für Build vs. Buy

Frage nach einer simplen Entscheidungslogik statt Bauchgefühl:

• „Nach welchen Kriterien entscheidest du, ob wir etwas selbst bauen oder einkaufen?“

Gute Antworten beinhalten Faktoren wie:

• Time-to-Market: Wie stark verzögert Eigenbau unser Go-Live?
• Strategische Relevanz: Ist das wirklich unser Differenzierungsmerkmal?
• Kosten: Einmalige vs. laufende Kosten, inklusive Wartung.
• Lock-in: Wie schwer kommen wir im Notfall wieder weg?

Red Flag: „Ich baue alles selbst, dann sind wir unabhängiger.“ Klingt cool, ist aber oft ein Zeichen von Ego statt Business-Fokus.

Roadmap & Priorisierung: Was kommt wann – und warum?

Die beste Tech-Architektur bringt nichts, wenn ihr an den falschen Features baut. Du als Nicht-Tech-Gründer musst verstehen, wie dein Co-Founder priorisiert.

11. Feature-Reihenfolge & Lernhypothesen

Stelle Fragen, die die Verbindung zwischen Tech-Roadmap und Business-Hypothesen aufdecken:

• „Welche Hypothesen testen wir mit der ersten Version unserer App/Webseite?“
• „Welche Features zahlen direkt auf diese Hypothesen ein, welche sind nice-to-have?“

Ein reifes Tech-Profil spricht nicht nur über „Features“, sondern über Lernen:

„Mit Version 1 testen wir, ob Leute überhaupt bereit sind, sich für Matching-Zwecke ein ausführliches Profil anzulegen. Dafür brauchen wir X, Y, Z – alles andere ist später.“

12. Transparenz in der Planung

Du solltest jederzeit verstehen können, wo ihr steht und was als Nächstes kommt. Frage:

• „Wie halten wir unsere Roadmap und den Fortschritt transparent – auch für mich als Nicht-Techniker?“

Typische Antworten:

• Ein simples Kanban-Board (Notion, Linear, Jira light) mit Status & Prioritäten
• Wöchentliche Check-ins, in denen Tech-Updates in Business-Sprache übersetzt werden

Wenn dein Co-Founder alles „im Kopf“ hat und keine Transparenz schafft, ist das ein Risiko – auch für spätere Team-Erweiterungen.

Red Flags im Gespräch mit potenziellen Tech-Co-Foundern

Neben fachlichen Fragen geht es auch darum, ob ihr auf Augenhöhe zusammenarbeiten könnt. Einige Warnsignale tauchen immer wieder auf.

13. Buzzword-Bingo statt Klartext

Wenn du bei Nachfragen immer nur „Microservices“, „Blockchain“, „AI“, „Serverless“ hörst, aber keine klare Verbindung zu euren aktuellen Zielen erkennst, sei vorsichtig.

Gegenfrage deinerseits:

• „Welche konkreten Vorteile bringt uns diese Technologie in den nächsten 12 Monaten in Bezug auf Speed, Kosten oder Nutzererlebnis?“

Wenn darauf keine verständliche Antwort kommt, könnte es eher um Selbstdarstellung als um Business-Fokus gehen.

14. Null Interesse an Business-Zahlen

Ein starker Tech-Co-Founder interessiert sich für deine Welt: CAC, Churn, Conversion, Sales-Cycle. Wenn alles, was außerhalb des Codes liegt, als lästig abgetan wird, leidet langfristig die Produktqualität.

Positive Zeichen:

• Fragen nach euren Umsatz-Zielen und North-Star-Metrics
• Interesse an Nutzer-Interviews und Feedback
• Vorschläge, wie Tech-Entscheidungen Business-KPIs verbessern können

15. Kein Sicherheits- oder Dokumentationsbewusstsein

Wenn jemand stolz erklärt „Ich dokumentiere nichts, das macht mich schneller“ oder „Security ist nur was für Konzerne“, dann baust du deine Firma auf sehr dünnem Eis.

Du brauchst kein 100-seitiges Architekturpapier, aber Minimalkosten-Dokumentation:

• Kurze README: Was läuft wo?
• Basis-Setup von Monitoring/Logging
• Mindestens grobe Beschreibung der wichtigsten Systeme

So führst du das Tech-Due-Diligence-Gespräch strukturiert

Statt ein einziges, überladenes Treffen zu planen, brich das Thema in 3 kurze Sessions à 60–90 Minuten runter – idealerweise, bevor ihr euch auf eine tiefe Co-Founder-Partnerschaft einlasst.

Session 1: Produkt & Architektur

• Produkt-Fokus: Was bauen wir in den ersten 12 Monaten?
• High-Level-Architektur als Skizze
• Skalierbarkeit & erste Engpässe

Session 2: Security, Daten & Tech-Schulden

• Datenarten & Sensitivität
• Security-Basics ab Tag 1
• Wo nehmen wir bewusst Abkürzungen und wie dokumentieren wir sie?

Session 3: Roadmap, Build-vs-Buy & Arbeitsstil

• Priorisierung der nächsten 3–6 Monate
• Entscheidungslogik für Build vs. Buy
• Zusammenarbeits-Setup: Tools, Rituale, Transparenz

Ganz wichtig: Mach dir nach jeder Session Notizen in deinen eigenen Worten. Wenn du die Antworten nicht zurückerzählen kannst, frag nach, bis es klar ist. Dein Ziel ist nicht, Tech-Experte zu werden, sondern Co-Pilot – mit genug Verständnis, um gemeinsam gute Entscheidungen zu treffen.

Wie Vasper dir hilft, bessere Tech-Gespräche zu führen

Wenn du über eine Plattform wie Vasper einen Tech-Co-Founder suchst, kommen diese Gespräche früh – oft sogar vor dem ersten gemeinsamen Projekt. Nutze das als Vorteil:

• Bereite dir anhand dieses Artikels einen Fragenkatalog vor.
• Frag in den ersten Video-Calls gezielt nach Beispielen aus früheren Projekten: „Wo habt ihr Tech-Schulden bewusst aufgebaut? Wie seid ihr damit umgegangen?“
• Schlage dem Match früh kleine Mikro-Experimente vor (z.B. ein kleines Test-Feature, Mini-Prototyp), um zu sehen, wie sie planen, priorisieren und erklären.

Der eigentliche Wert guter Tech-Due-Diligence als Nicht-Techniker liegt nicht darin, jede Antwort perfekt bewerten zu können, sondern:

• Denken deines Gegenübers sichtbar zu machen,
• Kommunikation auf Augenhöhe zu testen,
• und früh zu spüren, ob ihr in dieselbe Richtung lauft.

Fazit: Du musst kein Entwickler sein – aber ein informierter Partner

Tech ist zu wichtig, um es „den Technikern“ zu überlassen. Als Nicht-Tech-Gründer trägst du Mitverantwortung für die technischen Weichenstellungen eures Startups. Du musst keine Zeile Code schreiben, aber du solltest:

• die grobe Architektur eures Produkts erklären können,
• verstehen, wo ihr bewusst Tech-Schulden macht,
• wissen, welche Security-Basics ihr ab Tag 1 ernst nehmt,
• und nachvollziehen können, wie euer Tech-Setup eure Roadmap, Kosten und Risiken beeinflusst.

Wenn du diese Fragen an deinen (potenziellen) Co-Founder stellst, geht es nicht darum, ihn zu prüfen wie in einer Prüfungssituation. Es geht darum, Vertrauen und Transparenz aufzubauen – und zu sehen, ob ihr als Duo wirklich dasselbe Unternehmen baut.