Es läuft. Sie haben Nutzer. Sie sind nicht sicher, ob Sie deren Geld schon annehmen dürfen.
Den schwierigen Teil haben Sie geschafft - Sie wissen, dass Menschen es wollen. Jetzt macht jeder Fix etwas anderes kaputt, die Paywall lässt sich im Browser umgehen, und Sie wissen nicht, was Sie nicht wissen. Vibe Coding validiert. Engineers machen es haltbar. Wir sind beides - und bauen auch mit Claude Code.
Sie sind bei 80 %. Die letzten 20 % sind nicht mehr Prompts - sondern Engineering: Zahlungen, die sich abgleichen lassen, ein Backend, das keine Daten verliert, Umgebungen, die sich keine Datenbank teilen.
Sie haben von offengelegten API-Keys gelesen, von der Abo-Prüfung im Frontend, von fehlender Row-Level-Security. Sie haben das Modell gefragt, ob Ihre App sicher ist. Es hat Ja gesagt.
Die Token-Rechnung steigt, die App wird jede Woche langsamer, und Sie hätten gern, dass ein Senior einfach draufschaut und ehrlich sagt: härten oder neu bauen.
Ein Review in wenigen Tagen. Ein Plan, mit dem Sie handeln können - mit uns oder ohne uns.
Wir bringen es in Produktion und bleiben, bis es langweilig wird.
Ein fester Umfang zum Ausliefern: die „Zuerst“-Liste aus dem Review - erledigt, deployt, mit Tests und Pipeline. Sie sehen jede Woche einen klickbaren Build und zahlen nach Meilensteinen.
Danach halten wir, wenn Sie wollen, den Betrieb am Laufen: Monitoring, Upgrades, das Store-Review, das zurückkommt, das Feature, das Ihr größter Kunde verlangt hat. Oder wir übergeben an den Engineer, den Sie einstellen - und helfen Ihnen, ihn zu finden.
Ihr Repo, Ihre Accounts, Ihre Daten. Wir werden nie zu dem, wovor man Sie retten müsste.
Nicht „von Grund auf neu, sechs Monate, sechsstellig“.
Wir sind nicht gegen Vibe Coding. Sie haben den schnellsten Weg genutzt, um herauszufinden, ob es jemanden interessiert - das ist die Methode, und wir nutzen sie selbst. Was Sie gebaut haben, ist eine funktionierende Spezifikation. Bezahlen Sie nicht zweimal für dieselbe App.
Wir sind auch kein 24-Stunden-Fix von einem Marktplatz. Ein Patch, den Sie nicht lesen können, von jemandem, den Sie nie wieder erreichen, ist keine Produktion.
Wir verkaufen keine Angst. Es geht darum, dass Sie ruhig schlafen und die Daten Ihrer Nutzer bleiben, wo sie hingehören.
Schicken Sie den Repo-Link und einen Satz dazu, was Ihnen am meisten Sorgen macht. Wir sagen Ihnen, was wir zuerst beheben würden.
Wir setzen auf schnelle Kommunikation: keine Formulare, kein Briefing, kein Termin für einen Call. Schreiben Sie einfach - ein Senior aus dem Team antwortet direkt.
Von der Vibe-coded App zum produktionsreifen Produkt
Lovable, Bolt, Replit, v0 und Cursor haben verändert, wer Software bauen kann. Eine Produktmanagerin, ein Vertriebler, eine Ärztin oder ein Ladenbesitzer kann heute an einem Wochenende eine funktionierende App vor Kunden stellen. Viele tun es, und viele finden Kunden. Dann stoßen sie an die Wand, an die jede Generation von Buildern stößt: den Abstand zwischen „läuft in der Demo“ und „läuft für tausend Fremde, die dafür bezahlen“.
Dieser Abstand sind nicht mehr Prompts. Es ist Engineering: Zugriffskontrolle auf dem Server, Secrets, die nicht im Browser landen, Zahlungen, die mit dem Store übereinstimmen, eine Datenbank, die Wachstum übersteht, Tests, die vor den Nutzern fehlschlagen, und ein Weg, dasselbe zweimal zu deployen. Die Gründer-Version dieser Liste haben wir in eine Sicherheits-Checkliste für Vibe-coded Apps gepackt, die Sie selbst durchgehen können, bevor Sie jemanden anrufen.
„Es läuft“ heißt nicht „es ist sicher“
Die häufigsten Befunde in Vibe-coded Apps sind nicht exotisch. API-Keys in einem öffentlichen Repo. Eine Abo-Prüfung, die im Frontend läuft und sich durch zwei Zeilen CSS umgehen lässt. Ein Supabase-Projekt ohne Row-Level-Security, sodass jeder eingeloggte Nutzer jede Zeile lesen kann. Passwörter oder Gesundheitsdaten im Klartext. Nichts davon ist in der Oberfläche sichtbar, und das Modell, das es geschrieben hat, wird Ihnen selbstbewusst sagen, dass alles in Ordnung ist. Ein Senior-Engineer findet es an einem Nachmittag.
Härten oder neu bauen?
Die Reflexantwort klassischer Entwicklungsteams lautet „von Grund auf neu - sechs Monate, sechsstellig“. Meistens ist sie falsch. Was Sie gebaut haben, ist eine funktionierende Spezifikation: Sie enthält jede Entscheidung, die Sie im Gespräch mit Kunden getroffen haben - und das ist der teure Teil. Standardmäßig härten wir, was funktioniert, und bauen nur dort neu, wo die Risikorechnung es erzwingt - ein Zahlungsfluss, eine Datenschicht, ein Auth-System. Wir halten die Entscheidung schriftlich fest, mit Begründung, damit Sie sie jedem vorlegen können.
Wo die Daten Ihrer Nutzer liegen
Sind Ihre Nutzer in Europa, ist der Speicherort der Daten kein Detail. Standardregionen, Aufrufe externer KI-Dienste und Analytics-SDKs können personenbezogene Daten aus der EU bringen, ohne dass Sie irgendetwas entschieden haben. Wir hosten in der EU, wissen, welche Dienste man auf Abstand hält, und dokumentieren, was wohin geht - genau die Antwort, nach der ein Konzernkunde oder eine Aufsichtsbehörde früher oder später fragt.
Für wen das ist
Gründer mit einem Vibe-coded Produkt und echten Nutzern oder Umsatz, die es sicher, wartbar und wachstumsbereit brauchen. Unternehmen, in denen ein Fachbereich etwas in Lovable gebaut hat und die IT jetzt das Risiko trägt, ohne den Code zu besitzen. Nicht für ungetestete Ideen - dafür beginnen Sie mit Lohnt sich der Bau? - und nicht für Projekte, die ein Dienstleister mittendrin aufgegeben hat; das ist ein anderes Problem, siehe Softwareprojekt retten.
Häufige Fragen
Nicht unbedingt. Viele Apps bleiben auf ihrem Stack - mit einem richtigen Backend, Auth und Zahlungen dahinter. Wir sagen Ihnen, wenn die Plattform selbst das Risiko ist.
Einige Tage. Sie bekommen eine schriftliche, nach Risiko sortierte Liste: was vor der nächsten Zahlung behoben werden muss, was warten kann und was Sie nie anfassen sollten.
Nein. Sie haben ein Produkt schneller validiert als die meisten finanzierten Teams. Wir haben selbst KI-generierten Code in Produktion gebracht; die Aufgabe ist, ihn haltbar zu machen, nicht ihn zu benoten.
Ja - native und plattformübergreifende Mobile-Entwicklung gehört zum Team, ebenso das Store-Review mit seinen eigenen Regeln zu Abos und Daten.
Ihre Wahl: Wir bleiben und betreiben es, oder wir übergeben an einen Engineer, den Sie einstellen - und helfen Ihnen, ihn zu finden. Repo und Accounts gehören so oder so Ihnen.