Stellen Sie sich die App eines Lauftrainers mit Mitgliederkonten, optionaler Standortfunktion, E-Mail-Formular und Analysefunktionen vor. Das sind bereits vier verschiedene Datenwege. Sobald sich eine Funktion ändert, verändert sich auch die Datenschutzsituation.Die größte Herausforderung besteht nicht darin, eine rechtliche Seite zu erstellen. Drei Bereiche müssen dieselbe App beschreiben:BereichWas er widerspiegeln mussDie App selbstDie tatsächlich verwendeten Daten, Berechtigungen und DrittanbieterdiensteDie DatenschutzerklärungWas erhoben wird, warum, von wem, wie lange und welche Möglichkeiten Nutzer dabei habenDie Angaben in den StoresDie Antworten für Apple App Privacy und Google Play Datensicherheit auf Grundlage der aktuellen AppWenn ein Bereich „keine Standortdaten“ angibt, die eingereichte App aber auf den Standort zugreifen möchte, liegt eine Inkonsistenz vor.Ein großer Teil der Datenschutzvorbereitung ist eine Konsistenzprüfung: App, Datenschutzerklärung und Store-Eintrag müssen dieselbe Geschichte erzählen. Konsistenz ist notwendig, ersetzt aber nicht die Einhaltung der grundlegenden Datenschutz- und Nutzerdatenregeln der Stores.Dieser Artikel hilft Ihnen, diese Geschichte vorzubereiten. Er ist keine Rechtsberatung: Die geltenden Anforderungen unterscheiden sich je nach Land, Zielgruppe und Art der Daten.

Eine Kirchen-App kostet ab 36 € im Monat mit einem No-Code-Baukasten, ab 119 $ auf Kirchenplattformen. Echte Preise 2026, versteckte Kosten, die Spendenfrage.

GoodBarber ist jetzt im App-Verzeichnis von ChatGPT. Verbinden Sie Ihre App und verwalten Sie Produkte, Inhalte, Mitglieder und Push in ganz normaler Sprache.

Planen Sie eine sogenannte Membership-App? Wählen Sie zwischen bezahltem Abo und privater Community und strukturieren Sie Inhalte, Zugriff und Push.

Jede GoodBarber-App bringt ihren eigenen MCP-Server mit. Er ist die sichere Tür, durch die ein KI-Assistent, mit Ihrer Erlaubnis, Ihre App lesen und verwalten kann: Artikel schreiben und planen, Produkte aktualisieren, Statistiken abrufen, Push-Benachrichtigungen vorbereiten. Sie verbinden den Assistenten einmal, er authentifiziert sich per OAuth und sieht ausschließlich Ihre App.Wenn das Thema neu für Sie ist, zwei gute Einstiege: unsere MCP-Seite erklärt, wie Sie einen Assistenten mit Ihrer App verbinden, und dieser Artikel erklärt, was einen Anwendungs-MCP-Server auszeichnet.

Die Kurzfassung. Eine mit KI gebaute App, die in der Demo glänzt, hat bewiesen, dass sie rendern kann, nicht, dass sie laufen kann. Über Produktion entscheiden sieben unglamouröse Dinge: Konten, leere Zustände, Store-Review, Push-Zustellung, die Rechnung für den Stack, das erste Update und der Betrieb Woche für Woche. Gehen Sie die sieben Checks unten durch, bevor Sie einen Launch-Termin ankündigen. Auf GoodBarber trägt die Plattform die ersten sechs, teils fertig eingebaut, teils als Service, und der siebte kommt mit dem Anschluss eines KI-Agenten.Sie haben eine App mit einem KI-App-Builder gebaut, oder sie an ein paar Abenden per Vibe Coding Prompt für Prompt entstehen lassen. Sie funktioniert. Aber sehen Sie sich die Bedingungen an, unter denen sie funktioniert: Ihr Telefon, Ihr WLAN, Ihr Konto, Daten, die Sie selbst eingetippt haben, ein Build, der vor einer Stunde generiert wurde. Eine Demo ist eine App, die ausschließlich unter freundlichen Bedingungen getestet wurde.Produktionsreif heißt das Gegenteil: Die App funktioniert weiter, sobald die freundlichen Bedingungen wegfallen. Fremde statt Sie, ein Reviewer statt eines Publikums, Monate statt eines Nachmittags.Warum diese Lücke existiert, haben wir bereits aufgeschrieben: Unser Artikel über die sieben Mauern zwischen einem Prototyp und den Stores kartiert die strukturelle Distanz, und unser Text über den Unterschied zwischen Bauen und Betreiben benennt die Arbeit, die nach dem Launch beginnt. Diese Artikel enden mit Fragen, die Sie sich stellen sollten. Dieser hier macht aus den Fragen Experimente: sieben Checks, jeder mit einem konkreten Ablauf und einer Bestehensbedingung, über die sich nicht streiten lässt, und alle noch diese Woche durchführbar. Wenn sich ein Check langweilig anfühlt, ist das Absicht. Die Produktion ist der Ort, an dem die langweiligen Bugs wohnen.

Kurz gesagt. Die meisten kleinen Unternehmen brauchen keine größere Website. Sie brauchen die richtige: auffindbar auf Google, offen für Terminbuchungen und ausgeliefert als PWA, eine Website, die sich zusätzlich wie eine App installieren lässt. Eine GoodBarber-PWA wird serverseitig gerendert, sie rankt also wie jede Website, und sie kommt als Teil einer Content-App: PWA plus native iOS- und Android-Apps, aus einer einzigen Konfiguration. Sie verkaufen physische Produkte? Das ist eine eigene App: die GoodBarber eCommerce App, mit eigenem Katalog und Checkout.In einem Thread mit dem Titel are we massively overengineering websites for small businesses? („Überdimensionieren wir die Websites kleiner Unternehmen massiv?“), veröffentlicht im Juli 2026 auf r/nocode, fragt jemand, der Websites für Kunden baut, warum einem Steuerberater, einem Klempner oder einem Hundefriseur von nebenan maßgeschneiderte Animationen, ein komplexes CMS und Dutzende Seiten verkauft werden. Die Antwort mit den meisten Upvotes argumentiert, die meisten dieser Kunden wären mit einem Google Business Profile und einer schlichten Link-in-Bio-Seite besser bedient als mit der Acht-Seiten-Website, die sie eigentlich bestellen wollten. Ein anderer Kommentar benennt die eigentliche Krankheit: Wir verwechseln, was Entwickler beeindruckt, mit dem, was Kunden nützt.Der Thread hat beim Problem recht und bleibt einen Schritt vor der Lösung stehen. Die nützliche Frage ist nicht, wie groß die Website sein soll. Sondern welches Werkzeug die drei Aufgaben erledigt, die ein Dienstleistungsbetrieb wirklich hat: von neuen Kunden gefunden werden, Termine ohne Telefon-Pingpong annehmen und auf den Telefonen der Stammkunden präsent bleiben. Das ist eine Frage der Form. Und ein Objekt am Markt hat exakt diese Form.Das Vokabular ist Ihnen noch neu? Die komplette Abgrenzung Website vs. App vs. PWA, mit den drei Definitionen, der SEO-Erklärung und der Vergleichstabelle, steht in unserem Entscheidungsleitfaden. Dieser Artikel bleibt beim Fall des kleinen Dienstleistungsbetriebs.

Die Kurzfassung. Anders, als Sie erwarten würden. Die führenden KI-App-Builder lassen Sie Ihren Code tatsächlich exportieren; Stand August 2026 synchronisiert Lovable in jedem Tarif mit GitHub, auch im kostenlosen, und die Dokumentation erklärt, Sie seien „never locked in“. Der Lock-in steckt woanders: im verwalteten Backend, in dem Ihre Daten liegen, im Hosting und in der Authentifizierung, die Sie ersetzen müssten, in der KI-Editierschleife, die zurückbleibt, und in der KI-geschriebenen Codebasis, für die Sie in dem Moment allein verantwortlich sind, in dem Sie gehen. Den Code zu besitzen war noch nie dasselbe wie gehen zu können.Lock-in bedeutete früher etwas Einfaches: Ihre Arbeit steckt in einem proprietären Format fest, und die Ausgangstür ist verschlossen. KI-App-Builder haben die Form des Problems verändert. Die Tür ist offen. Die Frage ist, was durch sie hindurchpasst.Eine App ist dreierlei Besitz unter einem Namen: der Quellcode, das laufende System, das echte Nutzer bedient, und das Geschäft, das die App trägt. Der Export nimmt das Erste mit. Die anderen beiden nicht. Die Frustration, die sich durch die Migrations-Threads dieses Sommers zieht, kommt daher, dass man diese Unterscheidung zu spät entdeckt.

Countdown zum Saisonstart und eine gemerkte Vorbereitungs-Checkliste für jedes Mitglied: eine KI-gebaute Sektion für die App deines Sportvereins — mit dem kompletten Prompt zum Klauen.

Website, App oder PWA: was jede Option leistet, was die Pflege kostet, wie Sie entscheiden. Eine serverseitig gerenderte PWA ist Website und App in einem.

Die Classic-Theme-Bibliothek von GoodBarber wächst weiter, und diese Runde bringt zehn neue Themes für Content-Apps. Jedes ist eine fertige visuelle Richtung, die Sie zu Ihrer eigenen machen können, damit Ihre App schon ab dem ersten Bildschirm durchdacht wirkt. Das Schwierigste an einer Content-App ist selten der Inhalt. Es ist, alles absichtsvoll wirken zu lassen, Bildschirm für Bildschirm, wenn Design nicht Ihr Metier ist. Ein Theme löst das, indem es Ihnen eine vollständige visuelle Richtung liefert: Farben, Typografie, Bildstil und Layout greifen bereits ineinander. Sie bringen Ihren Inhalt und Ihre Marke; das Theme bringt den Feinschliff. Und da jedes Theme auf Smart Design basiert, bleibt das Ergebnis stimmig, wie weit Sie es auch anpassen.

Was in den drei Jahren nach dem Launch mit einer App passiert: was sich um sie herum bewegt, was die Plattform an Ihrer Stelle abfängt und die kurze Liste dessen, was auf Ihren Namen bleibt.

Kurz gesagt: Der Launch-Tag ist die Halbzeit, nicht die Ziellinie. Die eigentliche Arbeit an einer Mobile App ist der tägliche Betrieb: Veröffentlichen, Push-Kampagnen, Katalogpflege, Bestellungen. Genau bei dieser täglichen Arbeit wird ein KI-Agent wirklich nützlich.Die KI-Debatte ist besessen vom Bauen. Prompt-to-App-Demos, generierte Screens, One-Shot-Prototypen. Verständlich: Erschaffen liefert eine spektakuläre Demo. Aber wer tatsächlich schon eine App veröffentlicht hat, kennt den unbequemen Teil: An dem Tag, an dem Ihre App in den Stores ankommt, liegt der größte Teil der Arbeit noch vor Ihnen.Eine App, die niemand betreibt, stirbt leise. Inhalte veralten, Push-Kampagnen versiegen, der Katalog gerät aus dem Takt, und die Retention zieht nach. Wir betreiben seit 2011 Live-Apps, und fünfzehn Jahre Betrieb lehren eine Lektion: Über das Schicksal einer App entscheidet nicht, wie sie gebaut wurde, sondern wie sie betrieben wird. Diesen blinden Fleck haben wir in KI-App-Builder können Apps bauen. Können sie auch eine betreiben? untersucht: Die Branche ist sehr gut darin geworden, Apps zu generieren, und schweigt erstaunlich beharrlich darüber, sie zu betreiben.Genau deshalb formt sich eine neue Kategorie: die agentenfähige App. Keine App, die von einer KI gebaut wurde, sondern eine App, deren täglichen Betrieb ein KI-Agent tatsächlich übernehmen kann, auf Ihre Anweisung, mit Leitplanken. Sie bauen einmal. Sie betreiben für immer. Gelebt wird im zweiten Teil.

Replit baut seit 2016 Entwicklungswerkzeuge im Browser. Anfang 2026 kam ein Mobile-Angebot dazu, unter einer Seite mit dem Titel „Idea to Mobile App in Minutes" — womit das Unternehmen erstmals auf dem Terrain der App-Baukästen steht.Wir haben also unser übliches Briefing durch die Plattform geschickt: AURORA, dieselbe hochwertige Reiseführer-App, die wir bei jedem Werkzeug dieser Serie bauen. Keine Funktionsliste, sondern eine echte App, die in die Stores muss, jede Woche aktualisiert wird und von jemandem betrieben werden soll, der keinen Code schreibt.Was Replit ausliefert, ist solide. Und es ist zugleich, ganz eindeutig, eine Codebasis: ein React-Native-Projekt, eine nutzungsabhängig abgerechnete Cloud und eine Entwicklungskonsole. Der ganze Vergleich steckt in diesem Satz — Replit antwortet Ihnen in natürlicher Sprache und übergibt Ihnen danach etwas, das sich wie ein Entwicklungsprojekt verhält. Ob das ein Geschenk oder ein Problem ist, hängt vollständig davon ab, wer die App am nächsten Dienstag betreiben soll.

Nennen Sie in Ihrem Prompt einfach eine Content-Sektion Ihrer App beim Namen, und der AI Extension Builder baut einen Bereich, der genau diese Inhalte anzeigt — in exakt dem Layout, das Sie beschrieben haben. Ihre Artikel, Ihr Template, immer aktuell. Jede Content-Sektion einer GoodBarber-App bringt eine Reihe sorgfältig gestalteter Templates mit. Sie wählen eines aus, und es funktioniert — genau das ist der Vorteil einer integrierten Plattform. Aber das Layout, das Sie im Kopf haben, steht nicht immer auf der Liste. Vielleicht stellen Sie sich Ihre neuesten Artikel im Magazin-Stil vor: ein großes Titelbild mit dem Titel darüber, kleinere Karten darunter. Oder Ihre Events als kompakte Agenda, nur mit Datum und Ort. Bisher haben Sie das Template genommen, das am nächsten dran war.Was viele Nutzer des AI Extension Builders noch nicht entdeckt haben: Diese Grenze gibt es nicht mehr. Der Builder erstellt nicht nur eigenständige Widgets — er kann die Inhalte der bestehenden Sektionen Ihrer App lesen. Das macht ihn zu etwas Interessanterem als einem Widget-Generator: einem Werkzeug, mit dem Sie Ihre eigenen Anzeige-Templates entwerfen.

Die Sichtbarkeit einer PWA in Suchmaschinen beruht auf einem einfachen Prinzip: Damit eine Seite in den Suchergebnissen erscheint, muss eine Suchmaschine sie zuerst besuchen, lesen und indexieren. Diesen Besuch — den Crawl — lösen nicht Sie aus. Die Suchmaschine entscheidet selbst, wann sie wiederkommt, in ihrem eigenen Rhythmus.Bei einer statischen Website spielt dieses Warten kaum eine Rolle. Bei einer App mit lebendigen Inhalten — einem Medium, das mehrmals täglich veröffentlicht, einem Shop mit wechselnden Preisen und Beständen, einem Kalender, in dem Termine auftauchen und ablaufen — ist es eine echte Bremse. Die Arbeit ist längst getan: Der Inhalt ist online, aktuell, bereit, gefunden zu werden. Doch er wartet auf einen Crawler, der noch nicht zurück war. In der Zwischenzeit erscheint in den Ergebnissen manchmal eine alte Version der Seite — oder gar nichts.

Wenn Sie Ihre PWA veröffentlicht haben, liefert sie gerade in diesem Moment eine robots.txt aus: die erste Datei, die ein Crawler liest, und die Datei, die alles Weitere bestimmt — welche Teile Ihrer Website abgerufen werden, und von wem. Ihre sagt zu allen Ja.Alles Folgende betrifft diese Web-Version Ihrer App. Ihre iOS- und Android-Apps werden von niemandem gecrawlt, und der Tab erscheint erst, wenn Ihre PWA mindestens einmal veröffentlicht wurde — vorher gibt es keine Datei zu konfigurieren.Das war eine vertretbare Antwort. Sie war nur nicht Ihre — und die Adressaten haben sich verändert. Vor ein paar Jahren war ein Crawler auf Ihren Inhalten Google, Bing oder ein Datensammler, der Ihnen gleichgültig sein konnte. Heute gehört ein wachsender Teil dieses Traffics KI-Unternehmen, und sie wollen nicht alle dasselbe von Ihren Seiten. Sie als Block zu behandeln heißt, zwischen allen und keinem zu wählen.Der neue Tab teilt sie in vier Familien: Search engines (Google, Bing und die anderen Suchmaschinen, die Ihre Website in ihren Ergebnissen listen), AI answers (ChatGPT, Claude oder Perplexity, wenn sie Ihre Website in ihren Antworten zitieren), AI training (die Bots, die Ihre Inhalte sammeln, um ihre Modelle zu trainieren) und On-demand reading (wenn jemand eine KI bittet, eine bestimmte Seite Ihrer Website zu öffnen und zu lesen). Vier Familien, weil es vier verschiedene Abmachungen sind.

Kurz gesagt. Eine mobile App, die nicht aktualisiert wird, bleibt nicht eingefroren: Sie verfällt. Push-Nachrichten kommen nicht mehr an, neue Nutzer finden die App nicht mehr, und die Stores verstecken oder entfernen sie irgendwann. Auf GoodBarber fängt die Plattform jede Änderung der Betriebssysteme und Stores ab und liefert die Korrektur mit Ihrem nächsten Update aus: Ein Jahr mobiler Umbrüche erreicht Sie als Versionshinweis. Das Einzige, was bei Ihnen bleibt: regelmäßig aktualisieren.Ihre App funktioniert heute. Lassen Sie sie ein Jahr unberührt: Sie wird sich weiter öffnen, weiter gut aussehen, auf Ihrem eigenen Telefon weiter ihren Dienst tun. Nichts in Ihrem Dashboard warnt Sie. Genau das ist die Falle.Denn während Ihre App stillstand, hat sich alles unter ihr bewegt. Apple und Google haben neue Betriebssysteme ausgeliefert, die Regeln ihrer Stores neu geschrieben, alte Leitungen stillgelegt. Sie merken es Monate später, an Symptomen, die wie ein Marketingproblem aussehen: Die Downloads flauen ab, Push-Kampagnen erreichen immer weniger Menschen, ein treuer Nutzer schreibt Ihnen, dass die App auf seinem neuen Telefon Probleme macht. Der Verfall ist real, und er hat nichts mit der Qualität Ihres Inhalts zu tun.

Kurz gesagt. Ein MCP-Server ist nur so nützlich wie das, was er zugänglich macht. BaaS-Plattformen wie Back4app und Supabase öffnen ihr Backend: Datenbanktabellen, Schemas, Queries, Cloud Code. GoodBarbers MCP-Server öffnet die Abläufe einer live geschalteten mobilen App: einen Artikel veröffentlichen, einen Push planen, den Katalog aktualisieren, die Statistiken lesen. 150 domänentypisierte Tools bei Redaktionsschluss, an aktivierte Features gebunden, per OAuth auf genau eine App begrenzt, mit verifiziertem Read-back nach jedem Schreibzugriff. Gleiches Protokoll, ganz andere Flughöhe.Das Model Context Protocol hat sich schnell durchgesetzt. Im November 2024 von Anthropic vorgestellt und ein Jahr später an die Linux Foundation übergeben, ist MCP heute der Standardweg, einem KI-Agenten Tools an die Hand zu geben: mit mehr als 9.400 öffentlichen Servern, die 2026 in der offiziellen MCP Registry gelistet sind. Das bedeutet: Der Satz „Wir haben einen MCP-Server“ ist still und leise zur Checkbox geworden. Jede Plattform kann sie abhaken, und der Haken sagt nichts aus.Die Fragen, auf die es ankommt, liegen eine Ebene tiefer. Was lässt der Server einen Agenten sehen? Was lässt er ihn ändern? Und wenn der Agent schreibt: Was steht dann noch zwischen einem gut formulierten Prompt und einem kaputten Produktivsystem? Die Antworten hängen weit weniger vom Protokoll ab, das für alle gleich ist, als von der Flughöhe, auf der eine Plattform ansetzt.

Niemand bezweifelt mehr, dass eine KI fähigen Code generieren kann — selbst „vibe-coded" funktioniert es, manchmal sehr gut. Das ist nicht die interessante Frage. Die interessante Frage lautet: Was macht diese Section, einmal generiert, tatsächlich in deiner App? Bleibt sie ein isolierter Block in der Ecke, oder nutzt sie, was Gerät und App bereits können? Am ehrlichsten beantwortet man das, indem man einen Prompt nimmt und ihn Zeile für Zeile auseinandernimmt.Dafür ist diese neue Reihe da. In jeder Folge nehmen wir einen Prompt aus der Bibliothek des AI Extension Builder und nehmen ihn auseinander: wo er der Plattform vertraut, wo er sie zwingt, und was die resultierende Section wirklich kann. Wir beginnen mit einem der Beispiel-Prompts der Bibliothek: „wo ich geparkt habe".Hier ist der kürzeste Prompt, den man dafür schreiben könnte:Build a "remember where I parked" helper.Das ist alles. Ein Satz, kein Lastenheft. Und das kommt dabei heraus:Ein Button, um deinen Standort zu speichern. Eine Section, die diesen Punkt beim erneuten Öffnen der App wiederfindet. Ein Button, um zum Auto zurückzukehren. Ein dezenter Link zum Löschen. Und wenn du die Ortung ablehnst, ein Bildschirm, der es erklärt, statt abzustürzen.Die Überraschung ist nicht, dass sieben Wörter einen Bildschirm zeichnen. Sondern dass diese Section, aus einem Satz geboren, bereits die Fähigkeiten des Geräts nutzt: Sie liest das GPS, hält einen Speicher, öffnet Maps. Um keine dieser drei Dinge haben wir gebeten.