Die Ausgangssituation
Als Produkt-Manager mit technischem Hintergrund habe ich schon viele No-Code- und Low-Code-Tools gesehen kommen und gehen. Jedes versprach, die App-Entwicklung zu revolutionieren, die Eintrittsbarriere zu senken, und jeden zum Entwickler zu machen. Die meisten lieferten einen Teil ihrer Versprechen, aber alle hatten signifikante Einschränkungen. Als ich im Januar 2026 von Horizons hörte – einem Tool, das angeblich vollständige Web-Apps aus reinen Textbeschreibungen generiert – war ich daher skeptisch, aber neugierig genug, um es zu testen.
Die Ankündigung klang zu gut, um wahr zu sein: Beschreiben Sie einfach, was Sie wollen, und Horizons erstellt Frontend, Backend, Datenbank, Authentifizierung und Hosting – alles in wenigen Minuten. Kein Coding, kein Setup, keine Konfiguration. Wenn das funktionierte, würde es die Art und Weise, wie Software entwickelt wird, grundlegend verändern. Wenn es nicht funktionierte, wäre es nur ein weiteres überhype-tes Tool.
Meine Skepsis war durch Erfahrung geerdet. Ich hatte 2021 drei Monate in ein Bubble-Projekt investiert, das an der Performance-Grenze der Plattform scheiterte. Ich hatte 2022 mit Webflow ein Kundenprojekt umgesetzt, das großartig aussah, aber bei jeder Logik-Anforderung Workarounds über Drittanbieter-Tools brauchte. Und ich hatte 2024 die erste Generation der KI-App-Builder getestet, die im Kern hübsche Prototypen ohne funktionierendes Backend produzierten. Jedes dieser Tools hatte seinen legitimen Platz – aber keines hatte das Versprechen "vollständige App aus Text" eingelöst. Die Messlatte für Horizons lag also hoch und war präzise definiert.
Ich beschloss, Horizons mit einem realen Projekt zu testen – einer App, die ich für mein eigenes Business brauchte: Einen Schengen-Visum-Tracker für digitale Nomaden. Die App sollte es ermöglichen, Aufenthaltszeiten in Schengen-Ländern zu tracken, automatisch die 90/180-Tage-Regel zu berechnen, Warnungen bei Grenzüberschreitungen zu senden, und Reisedaten zu exportieren. Ein nützliches Tool für eine spezifische Nische, komplex genug, um die Fähigkeiten von Horizons zu testen, aber nicht so komplex, dass es unmöglich wäre.
Das Problem in der Tiefe
Das Problem der Web-Entwicklung ist die Kluft zwischen Idee und funktionierendem Produkt. Selbst mit modernen Frameworks und Tools erfordert die Erstellung einer vollständigen Web-App ein breites Spektrum an Fähigkeiten: Frontend-Entwicklung für die Benutzeroberfläche, Backend-Entwicklung für die Logik, Datenbank-Design für die Speicherung, DevOps für das Deployment und Hosting. Selbst erfahrene Entwickler brauchen Wochen, um eine polierte App von Grund auf neu zu erstellen.
Für Nicht-Entwickler ist diese Kluft oft unüberbrückbar. Sie haben Ideen, sehen Bedürfnisse, könnten Lösungen entwerfen – aber sie können sie nicht umsetzen. Sie müssen Entwickler finden, engagieren, managen. Das kostet Zeit und Geld. Viele gute Ideen sterben, weil die Umsetzungshürde zu hoch ist.
Ich habe das in meiner Rolle als Produkt-Manager dutzendfach beobachtet. In jedem Unternehmen, in dem ich gearbeitet habe, existierte eine informelle Liste von Tool-Ideen, die allen das Leben erleichtert hätten: ein kleines Reporting-Dashboard, ein Urlaubsplaner, ein Tracker für Kundenfeedback. Keine dieser Ideen rechtfertigte je ein Entwicklungsbudget von 20.000 Euro, also blieben sie ungebaut, und die Teams behalfen sich mit Excel-Tabellen, die irgendwann niemand mehr verstand. Dieser Friedhof der kleinen Ideen ist der eigentliche Markt für Tools wie Horizons – nicht der Ersatz großer Software-Projekte, sondern die Realisierung all dessen, was bisher unter der Wirtschaftlichkeitsschwelle lag.
Auch für Entwickler ist der Prozess oft frustrierend ineffizient. Wie viele Stunden verbringen wir mit repetitiven Aufgaben: Authentifizierungssysteme einrichten, Formularvalidierung implementieren, Datenbankverbindungen konfigurieren? All das ist notwendig, aber es ist nicht das, was unsere Arbeit interessant macht. Es ist das digitale Äquivalent von Ziegelsteine stapeln, bevor man das Haus bauen kann.
Das ökonomische Problem ist die Knappheit qualifizierter Entwickler und die steigenden Kosten für Software-Entwicklung. Ein einfacher Prototyp kann leicht Zehntausende von Euro kosten. Eine vollständige App kann Hunderttausende kosten. Diese Kosten machen es riskant, neue Ideen zu testen. Unternehmen müssen sicher sein, dass ein Produkt erfolgreich sein wird, bevor sie in die Entwicklung investieren.
Die Strategie/der Ansatz
Mein Ansatz zur Evaluation von Horizons war systematisch und realistisch. Ich wollte nicht nur wissen, ob es funktioniert, sondern wo seine Grenzen liegen, für wen es geeignet ist, und wie es in den bestehenden Ökosystem der Entwicklungstools passt.
Ich definierte vier Evaluationskriterien: Funktionalität (kann es die geforderten Features implementieren?), Qualität (wie gut ist der generierte Code und das Design?), Flexibilität (wie einfach ist es, Änderungen vorzunehmen?), und Skalierbarkeit (kann die App mit wachsender Nutzerzahl umgehen?).
Für den Test wählte ich den Schengen-Tracker aus drei Gründen: Er hat klare, objektiv testbare Anforderungen (die 90/180-Tage-Regel ist mathematisch präzise definiert). Er erfordert verschiedene Komponenten (Benutzer-Authentifizierung, Datenbank, Berechnungslogik, UI). Er ist nützlich – wenn er funktioniert, werde ich ihn tatsächlich nutzen.
Die 90/180-Tage-Regel ist dabei ein besonders guter Lackmustest, weil sie tückischer ist, als sie klingt: Es geht nicht um ein festes Kalenderfenster, sondern um ein rollierendes 180-Tage-Fenster, das für jeden einzelnen Aufenthaltstag neu berechnet werden muss. Viele handgeschriebene Implementierungen und sogar manche kommerzielle Apps machen hier Fehler. Wenn eine KI diese Logik korrekt implementiert, sagt das mehr über ihre Fähigkeiten aus als zehn generierte Landing Pages.
Ein wichtiger Aspekt war der Vergleich mit alternativen Ansätzen. Wie lange würde es dauern, diese App mit traditioneller Entwicklung zu erstellen? Mit anderen No-Code-Tools wie Bubble oder Webflow? Diese Vergleiche würden den tatsächlichen Wert von Horizons kontextualisieren.
Praktische Umsetzung
Die praktische Umsetzung begann mit dem Prompt. Ich beschrieb den Schengen-Tracker in natürlicher Sprache: "Erstelle eine Web-App namens 'Schengen Tracker' für digitale Nomaden. Die App soll es ermöglichen, Reisedaten in Schengen-Länder einzugeben (Ankunft, Abreise, Land). Sie soll automatisch berechnen, wie viele Tage im letzten 180-Tage-Zeitraum in Schengen verbracht wurden. Sie soll warnen, wenn die 90-Tage-Grenze erreicht ist. Sie soll eine Übersicht als Kalender und Liste zeigen. Daten sollen in einer Datenbank gespeichert werden. Benutzer sollen sich mit E-Mail anmelden können. Das Design soll modern und mobil-freundlich sein."
Ich drückte Enter und startete die Stoppuhr. Horizons begann sofort zu arbeiten. Zuerst analysierte es meinen Prompt und stellte Klärungsfragen: "Soll es eine E-Mail-Verifizierung geben?" "Soll es eine Export-Funktion für die Daten geben?" "Soll es Erinnerungen per E-Mail geben?" Ich antwortete auf die Fragen, und Horizons begann mit der Generierung.
Nach 1 Minute und 37 Sekunden war die App live. Ich öffnete die URL auf meinem Handy und sah eine funktionierende Anwendung. Ein Login-Bildschirm. Ein Formular zur Eingabe von Reisedaten. Ein Dashboard mit einer Liste der bisherigen Reisen. Ein Kalender-View. Die Berechnung der verbleibenden Tage funktionierte – ich gab einige Testdaten ein, und die App zeigte korrekt an, wie viele Tage ich noch im Schengen-Raum verbringen durfte.
Ich wollte es genau wissen und konstruierte gezielt schwierige Testfälle: überlappende Aufenthalte, ein Aufenthalt, der exakt am Rand des 180-Tage-Fensters beginnt, eine Reisehistorie mit 30 Einzelaufenthalten über zwei Jahre. Ich verglich die Ergebnisse mit dem offiziellen Schengen-Rechner der EU-Kommission. Von zwölf Testfällen berechnete die App elf korrekt. Der eine Fehlerfall betraf einen Aufenthalt, bei dem An- und Abreisetag identisch waren – die App zählte ihn als null Tage statt als einen. Ich meldete das Problem im Chat, Horizons korrigierte die Zähllogik, und im zweiten Durchlauf stimmten alle zwölf Fälle. Dass eine KI eine solche Randfall-Korrektur auf eine vage formulierte Fehlerbeschreibung hin sauber umsetzt, hätte ich vor einem Jahr nicht für möglich gehalten.
Der Code war beeindruckend sauber. React für das Frontend, Node.js für das Backend, PostgreSQL für die Datenbank. Das Design war modern, responsiv, mit einer ansprechenden Farbpalette. Für eine in unter zwei Minuten generierte App war das bemerkenswert.
Insgesamt investierte ich nach der Erstgenerierung noch etwa vier Stunden in Iterationen: die erwähnte Randfall-Korrektur, einen CSV-Export, eine Umstellung der Datumsdarstellung auf europäisches Format, dezentere Warnfarben und eine kleine Onboarding-Erklärung der 90/180-Regel für neue Nutzer. Jede dieser Änderungen dauerte zwischen zwei und zehn Minuten. Nur eine Anforderung scheiterte wiederholt: eine Offline-Fähigkeit der App für Reisen ohne Netzabdeckung. Hier produzierte Horizons dreimal hintereinander Lösungen, die im Test nicht funktionierten, und ich strich das Feature von der Liste.
Die Grenzen im Praxistest
Nach dem erfolgreichen Grundtest wollte ich wissen, wo genau die Belastungsgrenzen liegen, und unterzog die App drei weiteren Prüfungen.
Erstens ein Lasttest. Ich simulierte mit einem Standard-Werkzeug 200 gleichzeitige Nutzer über zehn Minuten. Die App blieb funktional, aber die Antwortzeiten stiegen von durchschnittlich 180 Millisekunden auf über 2,3 Sekunden. Für meine Nische – ein paar hundert Nomaden, die gelegentlich Reisedaten eintragen – völlig irrelevant. Für ein Produkt mit echtem Wachstumsanspruch ein klares Signal, dass die generierte Architektur nicht mitwächst: keine Datenbankindizes auf den abgefragten Spalten, kein Caching, keine Pagination bei langen Reiselisten.
Zweitens ein Sicherheits-Check. Ich prüfte die üblichen Verdächtigen: SQL-Injection über die Eingabefelder, Zugriff auf fremde Nutzerdaten über manipulierte IDs, Session-Handling. Das Ergebnis war besser als erwartet – die generierten Abfragen waren parametrisiert, die Autorisierung serverseitig sauber. Was fehlte, waren die zweite Verteidigungslinie und die Betriebsreife: kein Rate Limiting beim Login, keine Zwei-Faktor-Option, keine Audit-Logs. Für ein privates Tool akzeptabel, für eine App mit sensiblen Reisedaten fremder Nutzer eine offene Flanke.
Drittens der Export-Test, der mir am wichtigsten war: Kann ich den Code mitnehmen? Horizons bietet einen Code-Export an, und er funktioniert – man erhält ein vollständiges Repository. Aber der Teufel steckt im Detail: Der Code setzt an mehreren Stellen Horizons-eigene Bibliotheken für Authentifizierung und Deployment voraus. Ich schätzte den Aufwand, die App vollständig unabhängig auf eigener Infrastruktur zu betreiben, auf zwei bis drei Entwicklertage. Das ist machbar und deutlich besser als bei klassischen No-Code-Plattformen, wo ein Export schlicht unmöglich ist – aber es ist eben auch kein Knopfdruck.
Zahlen und Ergebnisse
Die quantitativen Ergebnisse des Experiments waren beeindruckend. Die Zeit von der Idee zur ersten funktionierenden Version: 1 Minute und 37 Sekunden. Im Vergleich: Ein erfahrener Entwickler würde für eine ähnliche App 2-3 Wochen brauchen. Mit Bubble oder Webflow würde es 3-5 Tage dauern. Horizons war um Größenordnungen schneller.
Rechnet man ehrlich, gehören zur Gesamtbilanz auch die vier Stunden Iterationsarbeit und etwa zwei Stunden für meine Tests. Macht in Summe rund sechseinhalb Stunden von der Idee bis zur geprüften, produktiv nutzbaren App. Bei einem Freelancer-Tagessatz von 800 Euro und realistischen zehn bis fünfzehn Entwicklungstagen hätte dieselbe App traditionell zwischen 8.000 und 12.000 Euro gekostet. Meine Gesamtkosten mit Horizons: unter 30 Euro und ein Nachmittag Arbeit. Das ist keine Optimierung um Prozentpunkte – das ist eine Verschiebung der Wirtschaftlichkeitsschwelle um zwei Größenordnungen.
Die Kosten waren minimal. Der Free Tier von Horizons erlaubte die App-Erstellung ohne Kosten. Das Hosting für die erste Version war inklusive. Für den produktiven Einsatz mit eigenem Domain und erweitertem Speicher würden etwa 20 Dollar pro Monat anfallen – im Vergleich zu Hunderten oder Tausenden für traditionelle Entwicklung.
Die Qualität war überraschend gut für den Anwendungsfall. Die Berechnung der 90/180-Tage-Regel war mathematisch korrekt. Die Benutzeroberfläche war intuitiv. Die mobile Darstellung war gut. Es gab keine offensichtlichen Bugs in der Grundfunktionalität.
Aber es gab auch Einschränkungen. Der generierte Code, obwohl funktional, war nicht optimiert. Die Ladezeiten waren etwas langsam. Die Datenbank-Struktur war simpel und würde bei sehr vielen Nutzern möglicherweise Probleme haben. Es gab keine automatisierten Tests. Die Fehlerbehandlung war minimal.
Zum Vergleich baute ich denselben Funktionsumfang parallel als grobe Kalkulation in Bubble nach, um die Aufwandsschätzung zu verifizieren. Nach vier Stunden hatte ich dort das Datenmodell und etwa die Hälfte der Eingabemasken – die rollierende 180-Tage-Berechnung hätte ich über verschachtelte Workflows abbilden müssen, was ich nach einem Blick auf die entstehende Komplexität abbrach. Die Hochrechnung von drei bis fünf Tagen für eine Bubble-Version halte ich daher eher für optimistisch. Der Abstand zwischen Horizons und der bisherigen No-Code-Generation ist bei logiklastigen Anwendungen noch größer, als es die reinen Erstellungszeiten vermuten lassen: Bei Horizons beschreibt man die Logik, bei Bubble konstruiert man sie – und Konstruktion skaliert schlecht mit Komplexität.
Risiken und Fehler
Der größte Fehler wäre, Horizons als vollständigen Ersatz für Entwickler zu betrachten. Das Tool ist phänomenal für Prototypen, MVPs, und einfache Apps. Aber für komplexe, skalierbare, sicherheitskritische Anwendungen reicht es nicht aus. Die generierten Apps brauchen menschliche Überprüfung, Optimierung, und Wartung.
Ein weiteres Risiko ist der Lock-in-Effekt. Apps, die mit Horizons erstellt werden, sind oft stark an die Plattform gebunden. Der Export des Codes ist möglich, aber nicht trivial. Wenn Horizons seine Preise erhöht, seine Funktionalität ändert, oder den Dienst einstellt, steht man vor Problemen.
Mein Export-Test hat diesem abstrakten Risiko eine konkrete Zahl gegeben: zwei bis drei Entwicklertage für die vollständige Unabhängigkeit. Meine Empfehlung daraus: Führen Sie diesen Export-Test durch, bevor Sie geschäftskritische Prozesse auf eine generierte App stützen – nicht erst dann, wenn Sie ihn brauchen. Ein Ausstiegsweg, den man nie erprobt hat, ist kein Ausstiegsweg, sondern eine Hoffnung.
Die "Works on My Machine"-Gefahr ist real. Mein Schengen-Tracker funktionierte in meinen Tests. Aber ich habe nicht getestet, wie er sich unter Last verhält, wie er mit ungewöhnlichen Eingaben umgeht, wie er auf verschiedenen Geräten und Browsern aussieht. Für einen produktiven Einsatz mit echten Nutzern wäre zusätzliche Qualitätssicherung nötig.
Ein subtileres Risiko ist die kognitive Abhängigkeit. Je mehr ich Tools wie Horizons nutze, desto weniger übe ich traditionelle Entwicklung. Meine Fähigkeiten könnten verkommen. Wenn dann ein Problem auftritt, das Horizons nicht lösen kann, bin ich möglicherweise nicht mehr in der Lage, es selbst zu beheben.
Langfristige Perspektive
Langfristig erwarte ich, dass Tools wie Horizons die Software-Entwicklung in zwei Lager spalten werden: Schnelle Prototypen und MVPs werden zunehmend von KI-generierten Tools erstellt. Komplexe, maßgeschneiderte, skalierbare Anwendungen werden weiterhin menschliche Entwickler erfordern.
Diese Entwicklung ist nicht bedrohlich für Entwickler, sondern befreiend. Sie eliminiert den großen Teil repetitiver, uninteressanter Arbeit und erlaubt Entwicklern, sich auf komplexe Probleme zu konzentrieren. Die Nachfrage nach hochqualifizierten Entwicklern wird nicht sinken – sie wird sich verschieben auf Architektur, Optimierung, Sicherheit, und die Lösung von Edge Cases, die KI nicht handhaben kann.
Für Nicht-Entwickler öffnet Horizons neue Möglichkeiten. Sie können Ideen testen, Produkte erstellen, Geschäfte aufbauen, ohne auf teure Entwickler angewiesen zu sein. Die Barriere zum Unternehmertum sinkt. Wir werden eine Welle von "Indie Makers" sehen, die allein oder in kleinen Teams komplexere Produkte auf den Markt bringen, als es heute möglich ist.
Die Qualität der KI-generierten Apps wird sich verbessern. Aktuell sind sie "gut genug" für viele Anwendungsfälle. In zwei bis drei Jahren werden sie für die meisten Standard-Anwendungen professioneller Qualität sein. Die Differenzierung wird dann in dem liegen, was die KI nicht kann: kreative Problemlösung, nuanciertes Verständnis von Benutzerbedürfnissen, Innovation.
Interessant wird auch die Frage, was diese Entwicklung mit dem Software-Markt selbst macht. Wenn jede Nische ihre eigene, in Stunden gebaute Speziallösung bekommen kann, verlieren generische SaaS-Produkte im unteren Preissegment ihre Existenzberechtigung. Warum 15 Euro monatlich für ein Tool zahlen, das zu 70 Prozent passt, wenn die zu 100 Prozent passende Eigenlösung 20 Euro Hosting kostet? Ich erwarte, dass sich SaaS-Anbieter in den kommenden Jahren entweder über Netzwerk-Effekte und Daten differenzieren müssen – oder über eine Qualität und Tiefe, die generierte Apps nicht erreichen. Das Mittelfeld wird dünn.
Fazit
Horizons ist kein Gimmick. Es ist ein ernstzunehmendes Werkzeug, das die Web-Entwicklung für einen großen Teil der Anwendungsfälle demokratisiert. Die 1:37 Minuten vom Prompt zur funktionierenden App sind nicht nur eine nette Demo – sie repräsentieren einen fundamentalen Shift in dem, was möglich ist.
Aber Horizons ist auch kein Allheilmittel. Es hat klare Grenzen in Bezug auf Komplexität, Skalierbarkeit, und Qualität. Es ersetzt nicht Entwickler, es verändert ihre Rolle. Es macht Nicht-Entwickler nicht zu Experten, es gibt ihnen Werkzeuge, die zuvor unzugänglich waren.
Meine Empfehlung ist kontextabhängig. Wenn Sie einen schnellen Prototypen brauchen, um eine Idee zu testen – nutzen Sie Horizons. Wenn Sie eine einfache interne App für Ihr Team brauchen – nutzen Sie Horizons. Wenn Sie ein komplexes, skalierbares Produkt für Millionen von Nutzern bauen – nutzen Sie Horizons für den ersten Prototypen, aber planen Sie professionelle Entwicklung für die Produktionsversion ein.
Die Zukunft der Software-Entwicklung ist hybrid. KI wird die Routine übernehmen, Menschen werden die Komplexität beherrschen. Tools wie Horizons sind der Anfang dieser Zukunft. Wer früh lernt, sie effektiv zu nutzen, wird einen Vorteil haben. Wer sie ignoriert oder sie als Bedrohung betrachtet, wird zurückfallen.
Der Schengen-Tracker, den ich in 1:37 Minuten erstellt habe, läuft heute produktiv. Ich nutze ihn für meine eigenen Reisen. Einige Freunde nutzen ihn auch. Mittlerweile sind es 34 registrierte Nutzer, die zusammen über 800 Aufenthalte erfasst haben, und die monatlichen Betriebskosten liegen bei 20 Dollar. Er ist nicht perfekt, aber er ist nützlich. Und er existiert nur, weil Horizons die Kluft zwischen Idee und Realität geschlossen hat. Das ist die wahre Revolution.