App ohne Code erstellen: Schritt-für-Schritt-Anleitung für 2026

Vor fünf Jahren bedeutete „ich habe eine App gebaut" ein Team aus drei Personen, ein halbes Jahr Entwicklung und ein Budget, das niemand laut aussprechen wollte. 2026 sieht das anders aus: Eine Person mit einer Idee, einem Laptop und einem freien Wochenende kann ein funktionierendes Produkt veröffentlichen — einen Katalog, einen Marktplatz, ein kleines CRM, einen Gewohnheits-Tracker — ohne eine einzige Zeile Code zu schreiben. No-Code ist längst kein Spielzeug für Landingpages mehr und reicht bis zu vollwertigen Webanwendungen mit Anmeldung, Zahlungen, Rollen und mobilen Builds.

Diese Freiheit hat eine Kehrseite. Die Werkzeuge sind einfach, die Entscheidungen nicht: Bei der Plattformwahl stehen Anfänger vor einem Dutzend ähnlich klingender Namen und entdecken einen Monat später, dass die gewählte Engine genau das eine nicht kann, worauf es ankommt. Dieser Leitfaden ist eine praktische Route: von der rohen Idee bis zur veröffentlichten App, mit ehrlichen Grenzen bei jedem Schritt. Zehn Etappen, die Stellen, an denen Menschen hängen bleiben, und das tatsächliche Geld.

Was No-Code ist und für wen es passt

No-Code heißt: Anwendungslogik wird aus fertigen Bausteinen in einem visuellen Editor zusammengesetzt, statt in einer Textdatei geschrieben zu werden. Hinter den Bausteinen steckt weiterhin Code — jemand hat ihn vorher geschrieben und verborgen. Man arbeitet mit Entitäten: „Schaltfläche", „Tabelle", „Bedingung", „E-Mail senden".

Für wen es passt:

• Gründer ohne technischen Hintergrund. Eine Hypothese prüfen, bevor Entwickler bezahlt werden.
• Kleine Unternehmen. Interne Anfrageverwaltung, Lager, Termine — Dinge, für die sich kein Entwickler lohnt.
• Produkt- und Marketingteams. Schnelle interne Werkzeuge: Dashboards, Rechner, Formulare mit Logik.
• Entwickler. Ein Prototyp an einem Abend statt einer Woche Boilerplate.

Für wen es nicht passt:

• Sie brauchen ein Produkt mit hoher Last und komplexer Serverlogik;
• Performance ist kritisch (Spiele, Videobearbeitung, aufwendige Berechnungen);
• eine geschlossene Integration ohne API ist zwingend erforderlich;
• es geht um ein Medizin- oder Finanzprodukt mit Zertifizierung und strengen Vorgaben zur Datenhaltung.

Wenn Ihr Fall nicht zu den letzten vier gehört, lesen Sie weiter.

Schritt 1. Definieren Sie eine Aufgabe, nicht „eine App"

Der häufigste Fehler am Anfang: das Produkt in Kategorien beschreiben („ich baue einen Marktplatz für Dienstleistungen"). No-Code belohnt Engführung: Je präziser die Aufgabe, desto einfacher das Datenmodell und desto schneller die veröffentlichte Version.

Eine Übung für eine halbe Stunde. Nehmen Sie ein Blatt und beantworten Sie vier Fragen:

1. Wer ist der Nutzer? Eine Rolle, nicht drei. „Ein Kunde, der eine Fachkraft sucht", nicht „Kunden, Fachkräfte und Admins".
2. Welche eine Handlung führt er aus? „Er stellt eine Anfrage mit Foto und Adresse".
3. Was bekommt er zurück? Der Nutzen in einem Satz. „Er sieht, dass die Anfrage angenommen wurde und wann eine Antwort kommt".
4. Was passiert danach? „Die Fachkraft sieht die Anfrage in einer Liste und ändert den Status".

Alles, was nicht in diese vier Punkte passt, gehört in Version zwei. Die Versuchung, in Schritt eins „noch Chat, noch Bewertungen, noch Zahlung" zu ergänzen, endet fast immer mit einem abgebrochenen Projekt bei 40 Prozent.

Das zweite Werkzeug ist die MVP-Liste: drei bis fünf Bildschirme, die funktionieren müssen, damit das Produkt Sinn ergibt. Steht ein Bildschirm nicht auf der Liste, wird er jetzt nicht gebaut. In No-Code sind die Kosten für ein zusätzliches Feature niedriger als in klassischer Entwicklung — die Kosten für Pflege und Verwirrung in der Oberfläche verschwinden aber nicht.

Schritt 2. Wählen Sie die Plattform nach Aufgabe, nicht nach Werbung

Plattformen unterscheiden sich nicht in „Leistungsfähigkeit", sondern in der Art der App, für die sie taugen. Grob vier Gruppen.

Tabellenzentriert. Airtable, NocoDB, Baserow in Kombination mit einer Oberflächenschicht (Softr, Glide). Die beste Wahl, wenn das Produkt im Kern aus strukturierten Datensätzen besteht: Katalog, Verzeichnis, Kundenstamm, Tracker. Schneller Start, ordentliche Listen und Filter ab Werk, schwächer bei individueller Oberflächenlogik.

Mobile App-Baukästen. Glide, Adalo, Thunkable. Auf das Telefon ausgerichtet: untere Navigation, Karten, Push-Nachrichten. Gut für Verbraucher-Apps — Tracker, Guides, Kataloge mit Karte. Die Web-Version ist meist zweitrangig.

Vollwertige Web-Baukästen. Bubble, FlutterFlow (mit Code-Export), WeWeb. Fast alles möglich: freie Logik, Workflows, API-Konnektoren, Rollen. Der Preis ist eine Lernkurve — die ersten zwei, drei Tage gehen in das Verständnis der Plattform, nicht des Produkts.

Spezialisierte. Softr (Portale und Kundenbereiche auf Airtable oder Google Sheets), Glide Pages (interne Tools), Carrd (einseitige Seiten). Eng, aber in ihrer Nische am schnellsten.

So wählen Sie ohne monatelanges Testen:

Kriterium	Was Sie vor der Anmeldung prüfen sollten
App-Typ	Web, mobil oder PWA? Gibt es einen echten mobilen Build?
Datenmodell	Verknüpfte Tabellen, berechnete Felder, Limits bei Datensätzen
Anmeldung	Rollen, Einladungen per E-Mail, Google-Login — inklusive oder extra?
Integrationen	Gibt es API und Webhooks oder nur eine Galerie fertiger Konnektoren?
Export	Kommen Sie an Ihre Daten, wenn Sie gehen? (Wichtiger als es klingt)
Preis in Ihrem Maßstab	Nicht der Starttarif, sondern der, den Sie bei 1000 Nutzern brauchen

Ein praktischer Trick: Vergleichen Sie Plattformen nicht anhand der Beschreibungen. Bauen Sie denselben Bildschirm — eine Liste mit Filter und ein Formular zum Hinzufügen — auf den beiden Finalisten. Eine Stunde Arbeit lehrt mehr als zehn Vergleichsartikel, weil sie zeigt, welchen Editor Sie persönlich verstehen.

Zu kostenlosen Tarifen: Sie enthalten fast immer das Branding der Plattform auf Ihrer Domain und ein Limit bei den Datensätzen. In Ordnung zum Prüfen einer Idee, nicht für ein Produkt, das Menschen nutzen.

Schritt 3. Modellieren Sie die Daten vor dem ersten Bildschirm

Fast jede No-Code-Plattform dreht sich um Tabellen. Ist das Datenmodell falsch, muss die Oberfläche neu gebaut werden — die teuerste Nacharbeit in No-Code, weil sie alle Bildschirme, Filter und Automatisierungen mitzieht.

Grundregel: eine Entität, eine Tabelle. Mischen Sie nicht Kunden und ihre Aufträge in einer Tabelle: Aufträge werden viele, und Sie erhalten doppelte Kunden und unbrauchbare Auswertungen.

Für die meisten Apps genügen drei bis fünf Tabellen. Beispiel für einen Anfragedienst:

• Kunden — Name, Telefon, E-Mail, Registrierungsdatum;
• Anfragen — Beschreibung, Adresse, Foto, Status, Datum, verknüpft mit dem Kunden;
• Fachkräfte — Name, Spezialisierung, Gebiet, Verfügbarkeit;
• Status — Nachschlageliste: neu, in Arbeit, erledigt, storniert.

Was Sie sofort festlegen sollten:

• Feldtypen. Ein Datum ist ein Datum, kein Text. Eine Zahl ist eine Zahl. Sonst verhalten sich Filter und Sortierung seltsam.
• Beziehungen. Eine Anfrage verweist auf Kunde und Fachkraft. Einmal eingerichtet, spart das Dutzende Stunden.
• Status als Nachschlageliste. „in Arbeit" und „In Arbeit" sind zwei verschiedene Werte — der klassische Grund, warum Auswertungen nicht aufgehen.
• Pflichtfelder. Weniger Felder, aber Pflicht, ist besser als zehn optionale, die niemand füllt.
• Eine Tabelle, ein Zweck. Ein Feld, das nur der internen Buchhaltung dient, gehört woandershin oder wird ausgeblendet.

Prüfung vor dem Bau der Oberfläche: Tragen Sie von Hand fünf Datensätze pro Tabelle ein. Wenn der Vorgang nervt oder Sie sich fragen „was kommt hier rein" — das Modell ist schlecht, korrigieren Sie es jetzt, solange es billig ist.

Schritt 4. Bauen Sie die Oberfläche Bildschirm für Bildschirm

In No-Code ist die Oberfläche eine Sammlung von Komponenten: Liste, Karte, Formular, Schaltfläche, Filter, Karte (Map), Galerie, Kalender. Es funktioniert wie ein Baukasten: hineinziehen, an ein Datenfeld binden, Aktion festlegen.

Eine Reihenfolge, die Nerven spart:

1. Listenbildschirm — der Hauptbildschirm. Richten Sie sofort Filter und Suche ein: Menschen müssen finden, was sie brauchen, ohne hundert Karten durchzuscrollen.
2. Detailkarte — was man beim Öffnen eines Datensatzes sieht. Hier liegen die Aktionen: „kontaktieren", „Status ändern".
3. Formular zum Hinzufügen — minimale Felder, klare Beschriftungen, klare Bestätigung nach dem Absenden.
4. Bildschirm „Meine" — die Datensätze des aktuellen Nutzers. Braucht einen Besitzerfilter, sonst sieht jeder alles.
5. Admin-Bildschirm — Tabelle mit allen Daten und Bearbeitungsmöglichkeit. Oft als separate App oder eingeschränkte Seite.

Drei Regeln, die am häufigsten gebrochen werden:

• Nicht früh dekorieren. Erst funktionierende Logik, dann Farben und Schriften. Sonst lackieren Sie einen Bildschirm, den Sie ohnehin neu bauen.
• Ein Bildschirm, eine Aufgabe. Ein Bildschirm mit Registrierung, Katalog und Zahlung gleichzeitig funktioniert für niemanden.
• Ab Tag eins am Telefon testen. Der Großteil Ihres Publikums kommt mobil, und „auf dem Desktop schön" bedeutet nichts.

Noch etwas zu leeren Zuständen: Eine App ohne Daten muss erklären, was zu tun ist. „Die Liste ist leer" ist ein schlechter Bildschirm. „Noch keine Anfragen. Erstellen Sie die erste — das dauert eine Minute" mit Schaltfläche ist ein guter.

Schritt 5. Richten Sie Logik und Automatisierungen ein

Logik in No-Code besteht aus Bedingungen und Ereignissen: „wenn ein Datensatz erstellt wird → E-Mail senden", „wenn Status auf erledigt wechselt → Datum schreiben", „wenn der Nutzer kein Admin ist → Löschschaltfläche ausblenden".

Beginnen Sie mit drei Automatisierungen, die fast jede App braucht:

• Benachrichtigung über neue Anfragen per E-Mail oder Messenger, damit Sie das Backend nicht manuell prüfen;
• Bestätigungsmail an den Nutzer — sie senkt die Sorge „hat das jemand gehört?" deutlich;
• Automatisches Datum und Autor beim Erstellen und Ändern — ohne das ist die Historie später unlesbar.

Danach nach Bedarf: Erinnerungen nach Zeitplan, Statuswechsel per Bedingung, Preisberechnung, Dokumentenerzeugung aus einer Vorlage.

Eine typische Falle: Automatisierungen, die sich selbst auslösen. „Bei Datensatzänderung den Datensatz ändern" ist eine Endlosschleife, die die Plattform irgendwann am Limit abschneidet. Prüfen Sie immer, welches Ereignis ein Szenario startet und ob dieses Ereignis Folge des Szenarios selbst ist.

Die zweite Falle ist Logik, die niemand erklären kann. Fünf verschachtelte Bedingungen bedeuten, dass Sie in einem Monat nicht mehr wissen, wozu sie da sind. Führen Sie ein kurzes Protokoll: welche Automatisierung, warum, was bricht, wenn man sie abschaltet.

Schritt 6. Verbinden Sie Integrationen: Zahlungen, E-Mail, Analyse

Praktisch jede App trifft irgendwann auf vier externe Dienste.

Zahlungen. Je nach Plattform ein eingebautes Zahlungsmodul oder ein Webhook zu einem Zahlungsanbieter. Prüfen Sie vorab: Unterstützt die Plattform Ihre Währung und Zahlungsart, gibt es einen Testmodus? Ohne Testmodus wird das Debuggen von Zahlungen zu echten Abbuchungen.

E-Mail und Benachrichtigungen. Transaktionsmails (Bestätigung, Passwort-Reset) verschickt man besser über einen eigenen Mail-Dienst statt über den Plattform-Versand: bessere Zustellbarkeit, echte Statistik. Push-Nachrichten in mobilen Baukästen liegen meist im bezahlten Tarif.

Analyse. Installieren Sie den Zähler vor dem Start, nicht danach. Sonst vergehen die interessantesten ersten zwei Wochen ohne Daten. Webanalyse mit Ereignissen genügt: Registrierung, Datensatz erstellt, Zahlung.

Backups. Regelmäßiger Datenexport ist keine Paranoia. No-Code-Plattformen schließen, ändern Preise und Limits. Richten Sie wöchentlichen Export als CSV oder in eine Cloud-Tabelle ein und bewahren Sie Kopien separat auf.

Schritt 7. Testen Sie mit echten Menschen, nicht mit sich selbst

Sie wissen, wie Ihre App funktioniert, deshalb sehen Sie die Schwachstellen nicht. Sie brauchen fünf bis sieben Personen, die das nicht wissen.

Testszenario: Geben Sie eine Aufgabe in einem Satz — „stelle eine Reinigungsanfrage für morgen" — und helfen Sie nicht. Beobachten Sie, wo die Person stehen bleibt. Schweigend. Das ist die schwerste und nützlichste Übung im Projekt.

Was fast immer auftaucht:

• unklare Feldbeschriftungen („Status" — Status für wen?);
• eine Schaltfläche, die am Telefon unsichtbar ist;
• ein Formular, das nicht bestätigt, dass es gesendet wurde;
• eine Validierungsfehlermeldung ohne Erklärung, was falsch ist;
• zu viele Schritte, wo einer reichen würde.

Testen Sie auch die „schlechten" Szenarien: Was passiert, wenn jemand Text in ein Telefonfeld tippt, die App mittendrin schließt, zweimal auf „Senden" tippt oder sich von einem fremden Gerät anmeldet. No-Code-Plattformen schützen nicht immer vor doppeltem Absenden — doppelte Anfragen hat jeder gesehen, der ein Formular ohne Schutz gestartet hat.

Schritt 8. Domain und Hosting: Wo die App lebt

Anfänger schieben diesen Schritt bis zum Ende auf, zu Unrecht: Adresse und Plattform beeinflussen Vertrauen, Geschwindigkeit und Auffindbarkeit in Suchmaschinen. Eine öffentliche Adresse wie myapp.platform.io ist für einen Test in Ordnung, ein Produkt braucht aber eine eigene Domain.

Domain. Wählen Sie die Zone nach Zielgruppe: .ru für den russischen Markt (lokales Vertrauen plus Yandex-Suche), .com als universelle Option, .app als Signal „das ist eine Anwendung" (diese Zone funktioniert nur über HTTPS). Die Registrierung kostet im Vergleich zum restlichen Budget wenig, nehmen Sie den Namen also für mehrere Jahre und aktivieren Sie WHOIS-Schutz. Der Registrar, den ich nutze und für russische Projekte empfehle, ist REG.RU: übersichtliches DNS-Panel, Zonen .ru/.com/.app an einer Stelle, kostenloses SSL-Zertifikat zur Domain.

Hosting. Viele No-Code-Plattformen hosten die App selbst, dann braucht es keinen eigenen Server. Sobald aber eine Landingpage, ein SEO-Blog, eine Werbeseite oder ein eigener API-Proxy dazukommt, brauchen Sie normales Hosting. Für das Paket „Website + Domain + E-Mail" passt Timeweb gut: Tarife mit Platz auf der Platte, SSL in wenigen Klicks, erreichbarer Support. Wenn das Projekt eher klassisches Shared Hosting mit täglichen Backups und Mail auf eigener Domain braucht, sehen Sie sich SprintHost an — dort lässt sich auch eine Testumgebung halten.

Praktische Orientierung:

Was Sie brauchen	Wohin schauen	Worauf achten
Nur Domain + Weiterleitung auf die Plattform	Registrar	DNS-Panel, Subdomains, WHOIS-Schutz
Landing, Blog, statische Seite	Shared Hosting	SSL, tägliche Backups, Inode-Limit
Eigene API, Webhooks, Hintergrundjobs	VPS	RAM, Docker, Snapshots
Viele Medien und Dateien	Hosting + Objektspeicher	Traffic-Abrechnung

Das technische Minimum, sofort:

• HTTPS ist Pflicht. Ein kostenloses Let’s-Encrypt-Zertifikat löst das; Browser markieren HTTP als unsicher, und .app-Domains funktionieren über HTTP gar nicht.
• Subdomains für Umgebungen. app.example.com für Produktion, staging.example.com für Tests. Auf Live-Daten zu testen ist gefährlich.
• Korrektes DNS. A-Record auf die IP, CNAME für www. DNS-Fehler sind die häufigste Ursache für „die Seite öffnet nicht" nach einem Umzug.
• Mail auf eigener Domain. Mails von noreply@example.com wirken verlässlicher als aus einem Gratis-Postfach und landen seltener im Spam.

Speziell für russische Projekte: Wenn Publikum und Zahlungen in Russland liegen, vereinfacht Hosting in Russland die Zusammenarbeit mit Zahlungsanbietern und verbessert die Antwortzeit für lokale Nutzer. Bei globalem Publikum zählt neben dem Preis die Latenz — ein Server in einer anderen Region kostet bei jedem Aufruf Hunderte Millisekunden.

Schritt 9. Veröffentlichen und die Adresse bequem machen

Das Veröffentlichen einer No-Code-Web-App ist meist ein Klick: Die Plattform baut und liefert die Version aus. Danach trennen drei Dinge „läuft bei mir" von „läuft bei Menschen".

1. Eigene Domain statt Plattformadresse. Richten Sie CNAME/A-Record nach Anleitung ein und prüfen Sie, dass HTTPS mit und ohne www funktioniert.
2. PWA-Manifest. Eine Progressive Web App lässt sich wie eine native App aufs Telefon installieren: Icon auf dem Home-Bildschirm, Vollbildmodus. Günstiger und schneller als Store-Veröffentlichung und deckt 80 Prozent der Bedürfnisse ab.
3. Metadaten. Titel, Beschreibung, Vorschaubild für Messenger und soziale Netze. Kleinigkeit, aber Links mit ordentlicher Vorschau werden deutlich öfter angeklickt.

Wenn es wirklich ein App-Store sein muss, kommt eine eigene Etappe: Entwicklerkonto, Screenshots, Beschreibung, manchmal Prüfung. Mobile Baukästen erzeugen meist ein Binary, aber Store-Anforderungen, dass die App kein reiner Website-Wrapper sein darf, sind schwerer zu erfüllen als es aussieht.

Schritt 10. Schauen Sie auf die Zahlen und streichen Sie Überflüssiges

Nach dem Start ist die Stille der Hauptfeind. Nicht „wie viele Installationen", sondern was Menschen darin tun.

Minimaler Kennzahlensatz für den ersten Monat:

• Zentrale Handlung erreicht (Datensatz erstellt, Anfrage gesendet) — Anteil aller Besucher;
• Am zweiten Tag wiedergekommen — kommen fast keine zurück, wird das Produkt in dieser Form nicht gebraucht;
• Wo sie abbrechen — der Bildschirm mit der höchsten Abbruchquote;
• Zeit bis zur ersten Handlung — versteht jemand in 20 Sekunden nicht, was zu tun ist, ist er verloren.

Danach ist die Schleife einfach: Bildschirm mit der schlechtesten Konversion finden, vereinfachen, erneut prüfen. In No-Code dauert eine Korrektur Minuten, also sollten Iterationen schnell und klein sein — eine Änderung auf einmal, sonst wissen Sie nicht, was gewirkt hat.

Und erweitern Sie die Funktionen nicht, bevor der Kern funktioniert. Eine zweite App für dasselbe Publikum ist fast immer die bessere Investition als zehn neue Bildschirme in der ersten.

Was es kostet

Größenordnung für einen Solo-Entwickler mit No-Code in 2026:

Position	Monatlich
Plattform (Produktionstarif)	$20–70
Domain (pro Jahr)	$10–25
Hosting für Landing/Blog	$3–15 (oder VPS $6–20)
E-Mail-Dienst	$0–20
Analyse	$0 (Basis)
Summe zum Start	$35–100 pro Monat

Vergleichen Sie das mit einem Entwicklungsteam: Eine Woche zweier Spezialisten kostet meist mehr als ein Jahr Plattform-Abo. Genau deshalb ist No-Code ein rationaler Weg, eine Hypothese zu prüfen. Aber rechnen Sie ehrlich: Der Tarif wächst mit Nutzern und Datensätzen, und der „günstige" Plan enthält oft nicht, was Sie brauchen (eigene Domain, Rollen, API).

Grenzen, die man vorher kennen sollte

• Vendor-Lock-in. Daten und Logik liegen auf einer fremden Plattform. Erhöht sie die Preise oder schließt sie, wird der Umzug schmerzhaft. Daher die Regel zum regelmäßigen Export.
• Leistungsgrenze. Listen mit Tausenden Datensätzen und aufwendigen berechneten Feldern werden langsam. Tiefer als eine bestimmte Ebene lässt sich nicht optimieren.
• Begrenzte SEO-Kontrolle. Manche Plattformen liefern HTML und Metadaten schlecht aus. Ist Suche Ihr Hauptkanal, prüfen Sie vor der Investition, wie Seiten für Crawler aussehen.
• Komplexe Logik stößt an Grenzen. Sobald Transaktionen, Warteschlangen oder feine Rechteverwaltung nötig sind, beginnt die Zone von Code und API-Konnektoren.
• Die Geschwindigkeit täuscht. Schnell gebaut, aber nicht schnell aufgeräumt. Ohne Disziplin bei Tabellen- und Feldnamen ist das Projekt in drei Monaten schwer zu überblicken — selbst für Sie.

Häufige Anfängerfehler

1. Fünf Plattformen parallel. Zersplitterte Kräfte. Eine wählen, bis zum Start bringen.
2. Sofort bezahlen. Starten Sie kostenlos: Beweisen Sie zuerst, dass die App gebraucht wird.
3. Alles in einer Tabelle. Später lässt sich das ohne Neubau der Oberfläche nicht entwirren.
4. Keine leeren Zustände und Hinweise. Der Nutzer sieht eine leere Seite und geht.
5. Mobile ignorieren. Mehr als die Hälfte des Traffics kommt vom Telefon.
6. Keine Benachrichtigungen. Anfragen sammeln sich, niemand weiß davon, das Produkt „funktioniert nicht".
7. Start ohne HTTPS und eigene Domain. Eine Kleinigkeit, die Vertrauen kostet.
8. Start ohne Analyse. Der erste Monat ist der wertvollste und vergeht ohne Daten.
9. Keine Backups. Ein Plattform-Zwischenfall, und die Historie ist weg.
10. Endloses Feilen statt Start. Eine perfekte Version, die niemand sah, ist nichts wert.

Checkliste vor dem Start

• Aufgabe passt in einen Satz, es gibt eine Nutzerrolle
• Plattform nach Test eines Bildschirms auf zwei Finalisten gewählt
• Datenmodell: Entitäten getrennt, Beziehungen gesetzt, Feldtypen korrekt
• Fünf Bildschirme fertig: Liste, Karte, Formular, „Meine", Admin
• Drei Automatisierungen: Benachrichtigung, Bestätigung, Datum/Autor
• Rollen und Zugriff mit zweitem Konto geprüft
• Test mit fünf Personen bestanden, kritische Stellen behoben
• Eigene Domain verbunden, HTTPS mit und ohne www
• Mails gehen nicht verloren, Backup-Export eingerichtet
• Analyse zählt die zentrale Handlung
• Geprüft, wie die App für Suchmaschinen-Crawler aussieht

Fazit

Eine App ohne Code zu bauen ist 2026 realistisch, und die Einstiegshürde ist niedriger als je zuvor. Erfolg entscheidet hier aber nicht die Plattform, sondern die Disziplin: enge Aufgabe, sorgfältiges Datenmodell, fünf Bildschirme, drei Automatisierungen, eigene Domain und Analyse ab Tag eins. Die Plattform ist ein Werkzeug — jede der genannten schafft es, wenn Sie wissen, was Sie bauen.

Fangen Sie heute mit einem Bildschirm an. Nicht mit der Wahl der „besten" Plattform, nicht mit Name und Logo — mit einer funktionierenden Liste und einem Formular. In einem Abend haben Sie einen Prototyp, in einer Woche eine App, die man nutzen kann, in einem Monat die Daten für die Entscheidung, ob es weitergeht. Registrieren Sie die Domain bei REG.RU und stellen Sie die Landing auf Timeweb — mehr Infrastruktur braucht es in dieser Phase nicht.