Lerne, wie man eine Validierungswebsite baut, die Nachfrage, Messaging und Preise testet—mit Wartelisten, Smoke Tests und Analytics—bevor du ein SaaS entwickelst.
„Pre‑SaaS‑Validierung“ bedeutet, eine einfache Website zu nutzen, um Belege dafür zu sammeln, dass deine Idee es wert ist, gebaut zu werden—bevor du Monate in die Produktentwicklung investierst. Statt Funktionen zu liefern, testest du, ob eine bestimmte Gruppe von Menschen genug Interesse hat, um eine bedeutsame Handlung vorzunehmen.
Eine Validierungsseite sollte dir helfen, klare Go/No‑Go‑Entscheidungen in vier Bereichen zu treffen:
Gute Validierungsdaten basieren auf Verhalten: E‑Mail‑Anmeldungen, Demo‑Anfragen, „Benachrichtige mich“‑Klicks, ausgefüllte Umfragen oder Antworten auf eine Folge‑Nachricht. Seitenaufrufe und Verweildauer liefern Kontext, beantworten aber selten die harten Fragen.
Validierung reduziert Risiko—sie garantiert keinen erfolgreichen SaaS. Eine Landingpage kann keine Retention, langfristige Zahlungsbereitschaft oder die Wettbewerbsfähigkeit deines Produkts beweisen, sobald Konkurrenz reagiert. Sie kann jedoch verhindern, dass du etwas baust, das niemand will.
Wenn du Software baust, schaffst du Funktionalität. Wenn du Beweise sammelst, testest du Annahmen.
Eine Pre‑SaaS‑Validierungswebsite ist ein strukturiertes Experiment: ein klares Problem, eine spezifische Zielgruppe, ein prägnantes Wertversprechen und ein Aufruf zur Handlung. Schwache Ergebnisse sind kein Scheitern—sie sind ein schnelles, kostengünstiges Signal, die Idee zu überarbeiten, die Zielgruppe einzugrenzen, die Botschaft anzupassen oder die Preisstrategie zu überdenken, bevor echter Code geschrieben wird.
Eine Validierungswebsite funktioniert nur, wenn sie um eine spezifische These gebaut ist. Wenn du versuchst, „alle anzusprechen“, weißt du nicht, für wen die Seite funktioniert hat—oder warum.
Wähle eine primäre Persona, die du in einem Satz beschreiben kannst (Rolle + Kontext). Beispiel: „Operations‑Manager bei Logistikfirmen mit 50–200 Mitarbeitenden, die Lieferungen mit Tabellen koordinieren.“
Definiere dann eine Job‑to‑be‑Done, die klar schmerzhaft und häufig ist. Nicht „produktiver sein“, sondern „verspätete Lieferungen durch kurzfristige Routenänderungen reduzieren“. Das hält deinen Text fokussiert und die Ergebnisse interpretierbar.
Deine Hypothese sollte wie eine testbare Behauptung lauten:
Beispiel: „Ops‑Manager in mittelgroßen Logistikfirmen treten einer Warteliste für ein Tool bei, das Routenänderungs‑Benachrichtigungen automatisiert, weil Kundenstrafen für verspätete Lieferungen gestiegen sind."
Liste die riskantesten Annahmen hinter deiner Idee, wie:
Lege fest, welche Ergebnisse dich weitermachen oder stoppen lassen. Zum Beispiel: „Mindestens 20 qualifizierte Anmeldungen in zwei Wochen aus einem Kanal, und 30 % von ihnen stimmen einem 15‑minütigen Gespräch zu.“ Das Vorab‑Festlegen verhindert, dass du schwache Signale als Erfolg deutest.
Eine Pre‑SaaS‑Validierungsseite soll nicht „fertig aussehen“. Sie soll eine Frage beantworten: Werden die richtigen Personen den nächsten Schritt tun, wenn sie dieses Angebot sehen? Jedes Element sollte ein klares Experiment unterstützen—keinen Feature‑Katalog.
Halte die Seite kompakt und vorhersehbar, damit Besucher nicht verloren gehen und deine Ergebnisse nicht verwässert werden.
Wenn du zusätzliche Abschnitte einfügst, sollten sie Einwände beantworten (Zeit, Risiko, Wechselaufwand, Datenschutz) statt in eine komplette Produktseite auszuufern.
Wähle einen einzelnen Haupt‑Call‑to‑Action, damit deine Daten sauber bleiben:
Verwende sekundäre Links sparsam (z. B. „So funktioniert’s“) und lass sie nicht mit dem Haupt‑CTA konkurrieren.
Feature‑Listen ziehen oft „nett‑gemeintes“ Interesse an, aber keine echte Verpflichtung. Beschreibe stattdessen das Ergebnis mit einem spezifischen Szenario, das dein Nutzer erkennt:
„Automatisch Ausgaben kategorisieren“ wird zu: „Lade einen Kartenumsatz hoch und erhalte vor deinem nächsten Rechnungslauf einen kundentauglichen Ausgabenbericht—pro Projekt getaggt."
Schreibe so, wie dein Zielkunde in E‑Mails, Tickets oder Stellenanzeigen spricht. Ersetze internes Jargon durch sichtbare Ergebnisse, eingesparte Zeit, vermiedene Fehler und Momente der Erleichterung. Ziel ist nicht beeindrucken, sondern sofort verstanden zu werden und leicht Ja sagen zu können.
Wenn deine Validierungswebsite ein Test ist, ist dein Messaging das Messinstrument. Ziel ist nicht, beeindruckend zu klingen, sondern Besucher dazu zu bringen, sich schnell zu selbst‑selektieren, damit du Conversion‑Raten verschiedener Versprechen vergleichen kannst.
Eine praktische Struktur ist:
Ergebnis + Zielgruppe + Zeit‑/Aufwandersparnis
Beispiele:
Dieses Format ist messbar, weil es eine klare Erwartung setzt. Wenn das Versprechen ankommt, siehst du mehr Klicks zum CTA und mehr Anmeldungen.
Dein Subheadline sollte zwei Dinge klären:
Welchen Schmerz du adressierst (in den Worten des Nutzers)
Wie du ihn löst (auf hohem Niveau, nicht Features)
Beispiel:
„Verliere keine Leads mehr an langsame Antworten. Wir routen eingehende Anfragen an den richtigen Kollegen und senden automatische Follow‑ups, bis der Prospect bucht.“
Vermeide vage Behauptungen wie „All‑in‑one“ oder „beste Lösung“. Sie sind schwer testbar und helfen dem Besucher nicht bei der Entscheidung.
Benefit‑Bullets funktionieren am besten, wenn sie spezifisch genug sind, um später geprüft zu werden. Selbst wenn du noch nichts lieferst, testest du damit, welche Ergebnisse die Leute wollen.
Wenn du keine echten Zahlen hast, nutze Richtungsaussagen („reduzieren“, „Zeit sparen“, „weniger“) und teste, welche Formulierung konvertiert.
Ein kurzer, konsistenter Ablauf nimmt Reibung und lässt dein Angebot real wirken:
Wenn du Messaging änderst, halte den Rest der Seite stabil, damit dein Conversion‑Tracking die Copy und nicht ein Redesign misst.
Dein CTA ist das Messinstrument einer Validierungsseite. Fordert er zu wenig, sammelst du vage Interesse. Fordert er zu viel, filterst du potenziell gute Kunden heraus. Die richtige CTA hängt davon ab, was du gerade lernen willst.
Passe das Angebot an dein Stadium an und baue die Seite darum auf:
Mischformen („Tritt der Warteliste bei oder buche eine Demo oder zahle jetzt“) verwässern das Signal und machen Conversion‑Raten schwerer interpretierbar.
Eine einfache Regel: Je sicherer du dir über Zielgruppe und Problem bist, desto mehr Reibung kannst du hinzufügen, um die Lead‑Qualität zu verbessern.
Wenn du ein Formular nutzt, füge eine Frage hinzu, die Segmentierung erlaubt (z. B. „Was willst du damit erreichen?“). Das macht Folgeinterviews deutlich wertvoller.
Anreize helfen, sollten aber spezifisch und sicher sein.
Biete frühen Zugang oder einen Zeit‑/Mengenvorteil ohne garantierte Features oder feste Termine. Setze Erwartungen transparent: Was Anmeldungen bekommen (Updates, Einladung zu Pilot, kurzes Interview) und einen realistischen Zeitrahmen (z. B. „Piloten in 4–6 Wochen anstreben").
Diese Klarheit erhöht Vertrauen und reduziert „Junk‑Signups“, die deine Zahlen aufblasen, aber später nicht konvertieren.
Preis ist kein nachträglicher Gedanke. Er ist Teil des Versprechens und beeinflusst stark, wer sich anmeldet. Eine Pre‑SaaS‑Validierungsseite kann Zahlungsbereitschaft testen, ohne Geld zu sammeln oder jemanden zu täuschen.
Erstelle 2–3 Plananker (z. B. Starter / Pro / Team), selbst wenn Details noch nicht final sind. Ziel ist zu lernen, welche Bandbreite und Packaging akzeptabel wirkt.
Halte jeden Plan einfach: kurze Beschreibung, ein Hauptnutzen und ein klarer Monats‑Preis. Vermeide falsche Rabatte oder künstlichen Zeitdruck.
Nutze einen hoch‑intent CTA wie „Trial starten“—behaupte aber nicht, das Produkt existiere.
Wenn jemand klickt, leite ihn auf eine Seite, die die Wahrheit sagt:
So bewahrst du das Signal (sie wollten kaufen), bleibst aber transparent.
Teste nicht nur die Zahl—teste die Struktur. Probiere Varianten in verschiedenen Traffic‑Runs:
Verfolge Engagement im Pricing‑Bereich und Klickrate pro Plan. Miss auch, wo Leute abbrechen:
Wenn Pro die meisten Klicks bekommt, aber wenige Wartelisten‑Anmeldungen, sind Preis oder Positionierung zu hoch oder der Wert noch nicht klar.
Wenn du noch kein Produkt hast, ist Vertrauen die Währung, um Besucher zur Handlung zu bewegen. Der schnellste Weg, Vertrauen zu verlieren, ist Versprechen, die du nicht beweisen kannst („Churn um 40 % senken") oder Kunden vorzutäuschen, die du nicht hast. Deine Validierungsseite sollte ehrlich, konkret und niedrig‑risikant wirken.
Du kannst Glaubwürdigkeit ohne Logos oder Fallstudien herstellen, indem du zeigst, warum du oder dein Team glaubhaft ist, das Problem zu lösen.
Teile kurz:
Sei konkret. „10 Jahre in Finance Ops" ist stärker als „leidenschaftlich bei Produktivität".
Füge Testimonials nur ein, wenn sie real und attribuierbar sind. Wenn du noch keine hast, ersetze „Testimonials“ durch Vorschauen auf das, was Nutzer erhalten.
Beispiele:
Kennzeichne diese klar als Beispiele oder Vorschauen.
Besucher haben Bedenken wegen Spam, verschwendeter Zeit oder Bindung.
Füge einfache, wahre Zusicherungen hinzu:
Eine kurze FAQ‑Sektion schafft mehr Vertrauen als ein weiterer Werbetext. Behandle typische Fragen wie:
Ziel ist nicht groß zu wirken, sondern verlässlich.
Wenn deine Validierungsseite dir nicht sagt, wer interessiert ist und was sie getan haben, rätst du nur. Analytics für Pre‑SaaS‑Validierung sollten Verhalten messen, das Intent abbildet—nicht Vanity‑Zahlen.
Beginne einfach und stelle sicher, dass jeder wichtige Schritt messbar ist. Mindestens tracken:
Wenn du mehrere CTAs hast (z. B. „Warteliste“ vs „Demo anfragen“), tracke sie getrennt, damit du sie vergleichen kannst.
Rohdaten helfen nicht bei Entscheidungen. Nutze ein kleines Set von Raten, die beschreiben, wo Interesse verloren geht:
Für Signup‑Qualität erfasse ein leichtes Qualifikationsfeld im Formular (z. B. Rolle, Unternehmensgröße oder „Was willst du erreichen?“). Prüfe Antworten wöchentlich.
Füge UTM‑Parameter zu jedem Kampagnenlink hinzu, damit du Ergebnisse zwischen Quellen und Botschaften vergleichen kannst (z. B. unterschiedliche Anzeigentexte oder Community‑Posts). Eine einfache Konvention (utm_source, utm_campaign, utm_content) reicht—wenn du konsistent bleibst.
Du brauchst kein komplexes BI‑Tool. Ein Spreadsheet oder einfaches Dashboard sollte wöchentlichen Traffic nach UTM, Event‑Counts und die wichtigen Conversion‑Raten zeigen. Ziel ist, markante Verschiebungen zu erkennen und zu entscheiden, was als Nächstes getestet wird—ohne dich in Daten zu verlieren.
Traffic ist nur nützlich, wenn er deiner Zukunftskundschaft ähnelt. Tausend zufällige Besucher liefern irreführende Conversion‑Raten; fünfzig passende Besucher können dir sagen, was gebaut werden muss.
Wähle Kanäle, in denen dein Zielnutzer bereits aktiv ist und wo Intent sichtbar ist:
Begrenze dich auf wenige Kanäle, damit du Variablen isolieren und Ergebnisse sauber vergleichen kannst.
Schreibe 2–4 Varianten deiner Anzeige oder deines Posts, jeweils mit einem anderen Wertversprechen. Halte sonst alles gleich: gleiche Landingpage, gleicher CTA, gleiche Zielgruppe (wenn möglich). So ist das „Warum“ hinter der Performance leichter zu interpretieren.
Beispiel‑Winkel zum Testen:
Starte mit einem Budget, dessen Verlust du verkraften kannst. Ziel sind richtungsweisende Signale (welche Problem‑Fokussierung qualifizierte Klicks bringt), nicht ein perfektes CAC‑Modell.
Messe Qualität, nicht nur Klicks: Scroll‑Tiefe, CTA‑Abschlüsse und Folgeaktionen wie Antworten auf Bestätigungs‑E‑Mails.
Lege ein einfaches Sheet oder Doc an, das festhält:
Der beste Mix liefert die stärkste Intention, nicht den billigsten Klick.
Eine Anmeldung ist nicht das Ende der Validierung—sie ist die Erlaubnis zu lernen. Ziel ist, „interessiert" in „konkret" zu verwandeln: Wer sind sie, was wollen sie tun, was haben sie schon versucht und was würde sie zum Wechsel bewegen?
Im Anmeldeformular eine kurze Frage einzubauen verwandelt anonyme Nachfrage in verwertbaren Kontext. Halte es Multiple‑Choice oder ein kurzes Textfeld, damit Abschlussraten nicht einbrechen.
Beispiele, die gut funktionieren:
Diese eine Frage macht dein Follow‑up deutlich besser—du kannst nach deren Realität fragen statt nur deine Idee zu pitchen.
Füge eine optionale Checkbox hinzu: „Bin offen für ein 15‑minütiges Gespräch, um zu teilen, wie ich das heute mache.“ Die Checkbox ist ein starkes Motivationssignal und fokussiert dein Outreach auf qualifizierte Leads.
Priorisiere Interviews mit Leuten, die:
Sende unmittelbar nach der Anmeldung eine automatisierte E‑Mail, die eine oder zwei klärende Fragen stellt. Halte sie antwortfreundlich (kein langer Fragebogen).
Beispiele:
Dann folge manuell mit einer kurzen, konkreten Einladung: „Hättest du 15 Minuten, damit ich verstehe, wie du X heute machst?"
Packe nicht alle Anmeldungen in einen Topf. Segmentiere nach Persona (Rolle), Problem und Workaround und überprüfe Conversion und Antworten pro Segment. Häufig ist das beste Segment kleiner—aber viel konsistenter.
Ein einfacher nächster Schritt: Lege 3–5 Persona‑Tags in deinem Sheet/CRM an und halte Interview‑Notizen nach Tag gruppiert. So werden Muster sichtbar und du vermeidest, für „alle“ zu bauen.
Validierungsseiten können sich ewig lebendig anfühlen—neue Ideen, Copy, kleine Änderungen. Am schnellsten lernst du, wenn du Iteration wie ein Labor behandelst: kontrollierte Änderungen, klare Zeitfenster und vorab definierte Regeln, was als Erfolg zählt.
Ändere nur eine Sache auf einmal, damit du weißt, was das Ergebnis verursacht hat. Wenn du Headline und CTA änderst, erzeugst du Lärm statt Einsicht.
Gute Ein‑Variablen‑Tests sind z. B.:
Halte den Rest identisch und „peek“ nicht während des Tests.
Lege vorab fest, wie lange ein Test läuft und wie viele Besucher du brauchst, bevor du entscheidest.
Eine praktische Regel für frühe Validierung:
Wenn du das Mindesttraffic nicht erreichst, ist das ebenfalls ein Signal: Dein Kanal ist vielleicht nicht geeignet oder das Targeting stimmt nicht.
Protokolliere: Was sich geändert hat, Warum, Daten, Traffic‑Quelle und Ergebnisse (Conversion‑Rate, E‑Mail‑Qualität, Interviewakzeptanz). Das verhindert zirkuläre Tests und hilft, Entscheidungen gegenüber Team oder Investoren zu erklären.
Beende das Seiten‑Tuning und gehe zum Pilot‑Build über, wenn du konsistente Signale siehst, z. B.:
Ab diesem Punkt schlagen A/B‑Tests für Button‑Farben nicht mehr das Bauen der kleinsten echten Workflow‑Lösung.
Deine Validierungsseite hat ihre Aufgabe erfüllt, wenn sie Unsicherheit reduziert hat: Du weißt jetzt wer es will, was sie erwarten und wie stark ihr Interesse ist (gemessen an Anmeldungen, Antworten und Zahlungsbereitschaft). Die Build‑Phase sollte eine direkte Fortsetzung dieser Signale sein—kein frisches Brainstorming.
Wähle den leichtesten Weg, der das versprochene Ergebnis liefern kann:
Nutze dein stärkstes Demand‑Segment als Scope‑Filter. Baue die erste Version um:
Wenn Preis‑Tests Sensitivität zeigten, halte das MVP flexibel (Tiers können später kommen). Wenn Nutzer mit hoher Intention auf Pricing geklickt haben, sollte dein erstes Angebot zu dem passen, was sie auf /pricing erwartet haben.
Frühes Onboarding sollte Wert schnell bestätigen und eine Feedback‑Schleife schaffen:
Sobald Validierungs‑Signale stark sind, wird die Umsetzung oft zum Engpass: eine bewährte Workflow‑Lösung schnell in eine echte App verwandeln, während Iteration eng bleibt.
Eine Vibe‑Coding‑Plattform wie Koder.ai kann helfen, weil du vom Spec (oder sogar deinem Landing‑Page‑Versprechen + Interview‑Notizen) per Chat zu einer funktionierenden Web‑ oder Mobile‑App kommen kannst—und dann schnell mit Features wie Planning Mode, Snapshots & Rollback und Source Code Export iterieren kannst. Das ist besonders nützlich, wenn du Discovery in Produktscope überführst und schnell ein schmales MVP (häufig React Frontend, Go‑Backend mit PostgreSQL, Flutter für Mobile) liefern willst, ohne deinen kompletten Prozess neu aufzubauen.
Dokumentiere deine Entscheidungsregel („Wir bauen X, weil Y Nutzer es angefordert haben und Z% versuchten zu zahlen") und setze einen Checkpoint in 2–4 Wochen. Für eine praktische To‑Do‑Liste, was als Nächstes zu tun ist, siehe /blog/your-next-step.
Eine Pre‑SaaS‑Validierungswebsite ist eine einfache Landingpage, die darauf ausgelegt ist zu testen, ob eine bestimmte Zielgruppe eine bedeutungsvolle Aktion ausführt (z. B. Wartelisten-Anmeldung, Demo-Anfrage, Vorbestellung), bevor du das Produkt baust.
Es geht weniger darum, „seriös auszusehen“, als darum, Beweise zu sammeln, um eine Entscheidungsgrundlage für Go/No‑Go zu haben.
Priorisiere Verhaltensmetriken, die Intention anzeigen:
Verwende Seitenaufrufe und Verweildauer nur als Kontext, nicht als Entscheidungskriterium.
Weil du die Ergebnisse sonst nicht interpretieren kannst: Wenn du nicht weißt, für wen die Seite funktioniert hat, weißt du auch nicht, ob du das Produkt für die richtigen Leute bauen würdest.
Wähle eine Persona und eine schmerzhafte Aufgabe, damit Messaging, Targeting und Conversion‑Interpretation aussagekräftig werden.
Eine brauchbare Hypothese ist testbar und enthält:
So wird die Landingpage zu einem kontrollierten Experiment, nicht zu einer generischen Präsentation.
Definiere Pass/Fail‑Kriterien, bevor du veröffentlichst, z. B.:
Ohne Entscheidungsregeln neigst du dazu, schwache Signale als Erfolg zu interpretieren.
Nutze eine klare Einseiter‑Struktur mit:
Füge nur Abschnitte hinzu, die Einwände beantworten (Wechselkosten, Datenschutz, Zeit‑bis‑Wert), nicht um eine ausführliche Feature‑Seite zu bauen.
Wähle den CTA, der zu dem passt, was du lernen willst:
Vermeide mehrere primäre CTAs gleichzeitig, sonst verwässerst du das Signal und verwischst Conversion‑Daten.
Führe einen ethischen Smoke Test durch:
So testest du Kaufabsicht, ohne vorzutäuschen, das Produkt existiere bereits.
Nutze verifizierbare „Proof Substitutes“, wie:
Vermeide gefälschte Testimonials, erfundene Logos oder unerfüllbare Ergebnisversprechen.
Betrachte Anmeldungen als Startpunkt der Customer Discovery:
Ziel: Workflows, Wechselbarrieren und „Must‑have“‑Bedingungen verstehen.
