Orchids

Sie beschrieben die gewünschte App, und Orchids erzeugte ein Projekt, nicht das Bild eines Projekts. Das bedeutete echte Dateien und echte Komponenten, die Sie ausführen konnten. Kein Design-Mockup, das Sie trotzdem noch per Hand bauen müssten. Für Menschen ohne Programmierhintergrund war genau das der Reiz. Der Haken? Vage Prompts lieferten vage Ergebnisse. Die Qualität der Ausgabe folgte der Klarheit Ihrer Beschreibung. Ohne Code, den man per Hand korrigieren konnte, musste die Beschreibung gleich in den ersten Versuchen sitzen.

Orchids blieb nicht beim Front End stehen. Es richtete die Backend-Teile ein, die eine funktionierende App braucht, mit Anwendungslogik und einer Datenbank, damit Funktionen wie Formulare und Konten echte Daten speicherten. Das ist der Unterschied zwischen einer Website, die fertig aussieht, und einer, die funktioniert. Damit eignete sich Orchids für kleine Web-Apps, nicht nur für Info-Seiten. Alles Komplexe brauchte trotzdem einen Menschen, der die Ausgabe prüfte.

Jede Änderung erschien in einer Live-Vorschau, und Sie verfeinerten das Ergebnis im Chat statt durch Bearbeiten von Code. Sie konnten ein anderes Layout, ein neues Feld oder eine Farbänderung verlangen und sahen sie angewendet. Diese Schleife machte das Tool zugänglich. Sie beurteilten die App, indem Sie sie ansahen, nicht indem Sie Quelldateien lasen. Das bedeutete aber auch, dass der größte Teil Ihrer Zeit in ein klares Beschreiben der Absicht floss, was manche schwieriger fanden als erwartet. Programmieren in natürlicher Sprache klingt einfach, bis man konkret sein muss.

Projekte, die Daten speichern mussten, konnten eine für Sie bereitgestellte verwaltete Datenbank nutzen. Ein Anmeldeformular, eine To-do-Liste oder ein kleiner Kunden-Tracker konnte echte Datensätze halten, ohne dass Sie einen Server aufsetzten oder Migrationsskripte schrieben. Für nicht technische Nutzer nahm das einen der größten Stolpersteine beim Bauen von etwas Interaktivem weg. Kein Server, um den man sich kümmert. Der Kompromiss war die Kontrolle. Sie arbeiteten innerhalb des verwalteten Setups, statt die Datenbank selbst abzustimmen.

Orchids übernahm das Deployment, sodass ein fertiges Projekt aus dem Dashboard heraus unter einer öffentlichen URL live gehen konnte. Kein separates Hosting-Konto. Keine CI-Pipeline. Sie konnten Ihre Arbeit zeigen, ohne das Tool zu verlassen. Als der Dienst abschaltete, wurde genau diese Bequemlichkeit zum Problem: Bereitgestellte Projekte liefen nicht mehr und mussten übernommen oder auf einen anderen Host verschoben werden. Das erinnert daran, dass Hosting, das an ein einzelnes Tool gebunden ist, mit diesem Tool lebt und stirbt.

Neben der Web-Version bot Orchids eine Desktop-App, die Ihre Projekte lokal speicherte, meist in einem Ordner auf Ihrem Rechner. Für alle, denen es wichtig war, ihre Arbeit zu behalten, zählte diese lokale Kopie. Sie überstand die Abschaltung ohne einen einzigen Migrationsschritt. Eine kleine Funktion, die sich im Rückblick als eine der nützlicheren erwies.