Die 5 Software-Arten, die du mit KI bauen kannst

TL;DR — Nicht jede Idee gehört in einen App-Store. Die meisten Produkte, die du wirklich brauchst, fallen in genau fünf technische Formen: ein lokales Tool, eine Web-App, eine Native App, ein Hintergrund-Dienst oder ein Hardware-Projekt. Die richtige Form zu erkennen, spart dir Monate an Fehlentwicklung und bestimmt, ob du mit einem hostierten KI-Builder in einer halben Stunde loslegst oder einen Coding-Agenten mit Supabase und Vercel kombinierst. Für Solo-Unternehmer in der DACH-Region ist die Web-App in den meisten Fällen der richtige erste Schritt — der Rest ist seltener, aber manchmal alternativlos.

Das Problem: Du weißt, was du willst, aber nicht, wie

Die meisten Menschen, die sich an KI-Buildern versuchen, stecken nicht am Code fest. Sie stecken an der Verwirrung über den Startpunkt fest. Sie wissen ungefähr, was sie verbessern wollen — eine unzuverlässige Tabelle, ein Prozess, der jedes Quartal von Neuem erklärt werden muss, eine Info, die irgendwo live ist und nirgends ankommt. Aber ob das jetzt ein Skript, eine Website oder ein kleines Gerät ist, steht in den Sternen.

Genau hier beginnt die eigentliche Arbeit: Die gewünschte Veränderung so zu beschreiben, dass sich daraus die technische Form ableiten lässt — bevor ein einziges Modell eine einzige Zeile Code schreibt. In einem viel diskutierten Video auf YouTube wird das am Beispiel zweier Projekte gezeigt: einem Fähren-Tracker in Amsterdam, der das per Gesetz geforderte AIS-Radiosignal der Schiffe mit einem Raspberry Pi, einer Antenne und einem Empfänger für zusammen rund 200 Euro abhört, um endlich pünktlich am Steg zu sein; und einer Haus-Wartungs-App, die für genau eine Wohnung gebaut wurde — ihre Geräte, ihre Pflanzen, ihren Garten — und jede Woche automatisch die Wartungsaufgaben für die Woche erzeugt.

Beide sind keine „fancy" Software. Sie sind klein, spezialisiert und passen in das Leben einer Person, genau wie keine Massenapp es je würde. Das ist der Kern von Personal Software — und genau dafür brauchst du eine Karte der fünf Formen.

Der Start: Fünf Fragen vor dem ersten Code

Bevor du ein Tool wählst, beantworte diese fünf Fragen. Sie entscheiden über die Form mehr als jede Modellwahl:

• Welche Veränderung willst du? Nicht „eine App", sondern: Was muss sich für dich messbar anders anfühlen?
• Woher kommt das Signal? Ist die Information in der realen Welt (Radio, Sensor, Kamera), in einer Datei, in einer API — oder sitzt sie nur im Kopf?
• Wo soll das Ergebnis auftauchen? Auf dem Handy, auf dem Schreibtisch-Monitor, auf einem Display am Küchentisch, gar nicht sichtbar?
• Wer darf sehen und ändern? Nur du? Ein Partner? Ein Team? Das bestimmt, ob du Login und Berechtigungen brauchst.
• Was passiert, wenn es versagt? Unangenehm, aber ungefährlich — oder wirklich sicherheitskritisch? Das skaliert deinen Aufwand massiv.

Diese Fragen liefern schon fast die Antwort: Ein Projekt, das ein physikalisches Signal empfängt und das Ergebnis lokal anzeigt, wird ein Hardware-Projekt. Ein Projekt, bei dem zwei Menschen dieselbe Liste auf zwei Handys synchron halten müssen, ist eine Web-App mit gemeinsamer Datenbank.

Die fünf Formen im Überblick

1. Das lokale Tool: Die einfachste Route

Ein lokales Tool läuft auf einem einzigen Computer und arbeitet mit Dateien oder einer kleinen lokalen Datenbank (meist SQLite). Es ist die absolut einfachste Route für alles, was nur du nutzt — ein Dokument-Organizer, ein privates Recherche-Tool, eine Utility, die tausend Fotos umbenannt und sortiert. Es braucht keine Website, keinen Login, keinen Host. Du sagst dem Coding-Agenten im Grunde: „Setz dich auf meinem Laptop auf und bau das" — und fertig.

Wann du es wählst: Wenn die Information privat bleibt, auf einer Maschine lebt und kein anderer Mensch je Zugriff braucht. Dann ist jede Cloud-Infrastruktur reiner Overhead.

2. Die Web-App: Dein Default für Personal Software

Die Web-App öffnet sich aus einem Link, läuft im Browser und lässt sich auf den Handy-Home-Screen ziehen. Sie ist der empfohlene Default für die meisten persönlichen Projekte, es sei denn, du hast einen konkreten Grund, es komplizierter zu machen. Eine einzige Version läuft auf Laptop, iPhone und Android. Du kannst sie mit Partner:innen oder Kolleg:innen teilen, ohne in einen App-Store zu gehen oder dir ein „Entwickler-Konto" bei Apple zu beschaffen.

Die typische Architektur für eine solche App ist schlicht: ein gemeinsames Supabase-Backend (Postgres-Datenbank + Login + Datei-Storage), die Web-App dahinter und Vercel als Host, der dir Preview-Links gibt, bevor du die Live-Version überschreibst. Genau diese Kombination — Web-App + geteilte Datenbank + Host — macht das Haus-Wartungs-Beispiel möglich: Zwei Personen sehen dieselbe aktuelle Liste auf zwei verschiedenen Handys.

Wichtig bei der Datenbank-Entscheidung: Hosted Builder wie Lovable fragen später, ob die Daten im eigenen Managed-Cloud-Backend oder in Supabase liegen. Die eigene Cloud ist der kürzeste Weg; Supabase ist etwas mehr Setup, hält aber Datenbank und Auth in einem breit genutzten Postgres-Standard — was deine Portabilität rettet. Die Faustregel: Wechsle das Interface früh, nicht die Daten. Eine App umziehen ist in Jahren weitaus schwieriger als eine neue Oberfläche davor.

3. Die Native App: Nur wenn das Handy mehr will

Das ist das, was die meisten Menschen unter „App" verstehen — Apple hat das Wort jahrelang trainiert. Aber es kostet mehr Arbeit. Du brauchst sie erst, wenn dein Produkt an eine tiefe Handy-Funktion hängt: zuverlässige Push-Benachrichtigungen, Bluetooth, Hintergrund-Location, NFC oder eine reine App-Store-Verteilung. Sonst springe nicht ins kühle Nass.

Der praktikable Weg ist ein Coding-Agent mit Expo: Aus einem Projekt wird eine iOS- und Android-App, ein Build-Dienst erledigt das meiste der Signierung und Verpackung. Du brauchst trotzdem Apple- und Google-Entwicklerkonten und musst deren Reviews bestehen — das ist ein echtes, etwas aufwendigeres Verfahren. Deshalb gilt die Regel: Beweise deine Idee zuerst als private Web-App, außer das Handy-Können lässt sich von deiner Idee gar nicht trennen. Du willst nicht die App-Store-„Steuer" zahlen, nur um herauszufinden, ob dein Partner die Wartungsliste überhaupt mag.

4. Der Hintergrund-Dienst: Software ohne Bildschirm

Ein Hintergrund-Dienst hat vielleicht gar kein UI. Er wacht auf — nach Zeitplan oder auf ein Ereignis —, erledigt seine Aufgabe und schickt das Ergebnis irgendwohin. Er prüft jeden Morgen einen öffentlichen Datensatz, verarbeitet eine Datei, sobald sie eintrifft, oder sendet einen Alarm, wenn ein Sensor einen Schwellwert überschreitet. Im Kern ist es ein Transformations-Schritt: Daten aus einer Quelle nehmen und an ein Ziel geben. Solche Dienste brauchen oft kein „Produkt-Gefühl", aber eine saubere Auslöser-Logik und einen Ort, an dem das Ergebnis landet (Mail, Chat, Datenbank).

5. Das Hardware-Projekt: Software so nah wie möglich an der Welt

Hier lebt die Software so nah wie möglich an der physischen Welt: der AIS-Fähren-Empfänger, ein Display am Küchentisch, eine Kamera, ein Werks-Sensor. Die Wahl des kleinen Rechners folgt der Aufgabe:

• Raspberry Pi — ein kleiner Allzweck-Computer, ideal, wenn ein Empfänger oder eine Antenne einen dauerlaufenden Decoder braucht.
• ESP32 — perfekt, wenn die Aufgabe fast nur „einen Sensor lesen" oder „ein Gerät schalten" ist.
• Home Assistant — der schnellste Einstieg, wenn die Geräte schon im Haus existieren und du sie nur an einem Ort zusammenführen willst.

Der entscheidende Hebel: Je näher du an den bestehenden Sensoren eines normalen Smart Home bist, desto weniger musst du selbst bauen und desto mehr kannst du Off-the-Shelf-Komponenten einfach verdrahten. Und weil moderne Coding-Agenten mittlerweile Fotos von Platinen und Bauteilen lesen, Verbindungen identifizieren, Pins erklären und dein Setup überprüfen können, ist die Grenze zwischen Software- und Hardware-Person so durchlässig wie nie.

Die zwei Routen: Hosted Builder vs. Coding-Agent

Sobald die Form steht, werden die Tool-Entscheidungen fast trivial. Du hast im Wesentlichen zwei Familien:

Der hostierte Builder (Lovable, Replit, Bolt) ist für die allererste Web-App der schnellste Weg: Du beschreibst die Software, der Builder erstellt das Projekt, zeigt dir eine Vorschau und gibt dir einen Publish-Knopf. Du installierst keine Programmiersprache, startest keinen Server, verstehst gar nicht erst die Kommandozeile — und hast trotzdem etwas Lauffähiges. Wenn das Projekt mehr als eine Web-Oberfläche braucht (Python-Scripting, ein immerlaufender Server, geplante Jobs, ein Mobile-Build), ist Replit der stärkere Kandidat, weil es mehr der Infrastruktur in einen Dienst packt. Bolt ist ein weiterer guter Weg für eine schnelle Full-Stack-Web-App.

Der Coding-Agent ist die nächste Stufe — und trotzdem noch nichts nur für Fortgeschrittene: Codex oder Claude Code sehen deine Projektdateien, verändern sie, starten die App lokal, lesen Fehler und versuchen es erneut. Dazu kommen GitHub Desktop für visuelle Versionskontrolle, Supabase für die geteilte Datenbank und Vercel für den Publishing-Schritt. Der große Vorteil: Du kannst eine Komponente tauschen, ohne alles zu tauschen. Das Modell kann wechseln, während die Datenbank bleibt. Der Host kann wechseln, während der Code bleibt. Die Oberfläche kann sich ändern, ohne die Daten zu bewegen — es ist ein anderes Fenster auf denselben Raum.

Modell ≠ Coding-Agent ≠ Builder — und warum das wichtig ist

Menschen vergleichen diese drei, als wären sie dasselbe Produkt. Sie sind das nicht. Die Schichtung ist klar:

• Das Modell ist die reine Denk- und Code-Fähigkeitsschicht.
• Der Coding-Agent gibt dem Modell Zugriff auf einen Ordner, auf Befehle, Vorschauen und Tools.
• Der hostierte Builder paketiert Agent + Environment + Publish-Knopf in ein Produkt.

Aus dieser Schichtung folgt die große Freiheit: Model und Arbeitsumgebung müssen nicht aus demselben Haus kommen. Du kannst ein offenes Modell wie GLM 5.2/5.3 über einen unterstützten Coding-Tool-Stack fahren. Für den allerersten Build: Wähle eine Umgebung, nicht drei. Die wahre Freiheit kommt nicht daher, drei Modelle über jeden Button streiten zu lassen, sondern daraus, dass du die Projektdateien, die Daten und die Entscheidungen besitzt — und weißt, was das Modell tut.

So hältst du das Modell in der Spur: Vier kleine Dateien

Der häufigste Fehler beim KI-Bauen ist nicht Code, sondern versteckte Entscheidungen. Das Modell wählt plötzlich eine vertraute Datenbank ohne zu erklären, fügt einen bezahlten Dienst hinzu oder macht die App öffentlich. Die Lösung ist keine magische Prompt-Erzählung — sondern eine Rollenänderung: Das Modell agiert als Baupartner, der seine Entscheidungen offenlegt. Praktisch heißt das, vier kleine Textdateien neben dem Projekt zu führen, die jedes Modell lesen kann:

• project.md — wer die Software für wen ist, was heute passiert, was stattdessen passieren sollte (Vorher/Nachher), wo sie laufen muss und welche Informationen privat bleiben.
• decisions.md — jedes Mal, wenn das Modell eine Wahl trifft, die Kosten, Daten, Zugriff, Deployment oder Portabilität beeinflusst, trage es die Optionen, die Empfehlung und die Begründung ein — besonders, wenn die Entscheidung gemeinsam mit dir entstanden ist.
• scenarios.md — die realen Situationen, die die Software behandeln muss (z. B. „Gerät per Handyfoto anlegen, das passende Handbuch finden, nächste Wartungsaufgabe erzeugen"). Diese echten Fälle sind deine Testfälle.
• agent.md / claude.md — die kurze Instruktionsdatei für den jeweiligen Coding-Agenten. Sie sagt nur, wie sich das aktuelle Tool verhält; die dauerhaften Wahrheiten bleiben in den ersten drei Dateien.

# agent.md
Du agierst als Baupartner, der Entscheidungen offenzulegen hat.
Wenn eine Wahl Kosten, Daten, Privacy, Portabilität, Deployment
oder Wartung betrifft: erkläre sie in plain English.
- Gib 2-3 realistische Optionen.
- Empfehlung: eine für dieses Projekt und begründe sie.
- Sage, was danach leichter / schwerer zu ändern ist.
- Frag vor: öffentlich, teuer oder destruktiv.
- Keine Secrets in Code, Screenshots oder Chats.

# project.md (Beispiel)
Ziel: Wartungs-App für genau eine Wohnung.
Vorher: Erinnerungen auf Post-its, kein gemeinsames Bild.
Nachher: beide Partner sehen dieselbe Liste auf zwei Handys.
Laufzeit: im Browser, privat, nur 2 Logins.
Privat: Seriennummern, Fotos, Handbuch-Links.

Sicherheit: privat vor öffentlich, Kontrolle im Backend

Die Security-Regeln klingen nach viel, sind aber einfach:

• Privat by Default. Mache die App erst öffentlich, wenn du wirklich öffentlichen Zugriff brauchst — und nutze dann ein Managed-Login-System. Erfinde nicht selbst Passwort-Storage, wenn es bereits existiert.
• Secrets bleiben draußen. API-Keys und Passwörter gehören in die Secret-Settings deines Hosts (z. B. Vercel), nicht in sichtbaren Code, Screenshots, Chat-Transkripte oder GitHub.
• Access Control im Backend, nicht im UI. „Knopf ausblenden" ist keine Berechtigungs-Kontrolle. Dass dein Haushalt die Daten des anderen nicht lesen kann, wird in der Datenbank erzwungen. Supabase ist dafür stark — und genau der häufigste, schwerste Fehler, wenn zwei Haushalte dasselbe Produkt nutzen.
• Backup + Wiederherstellung beweisen. Wenn die Daten wichtig sind: Backup anlegen und die Wiederherstellung testen. Bei Zahlungen, Kinder-Informationen, medizinischen oder rechtlichen Daten: lass die Software vor dem Einsatz prüfen.
• Nicht mit Sensiblem anfangen. Beginne mit dem Einfachen und steige in sicherere Apps ein, wenn dein Risiko-Profil wächst.

Testing: Kein „done" ohne echten Handschlag

Du brauchst keine Test-Vokabeln am Anfang. Du brauchst die Situationen, die dich betreffen, schriftlich — und dann auf dem Gerät testen, auf dem es wirklich laufen wird, und sehen, ob es funktioniert. Beim Haus-Beispiel heißt das: Kann ich ein Gerät fotografieren und die richtige Karte anlegen? Bleibt die Modellnummer erhalten? Sieht meine Partnerin dieselbe Liste? Was passiert, wenn das Foto unlesbar ist? Teste auch die unglücklichen Pfade.

Und der wichtigste Satz: Es gibt keinen Ersatz dafür, dass ein Mensch sagt: Das funktioniert tatsächlich. Du kannst Lovable, Codex oder Claude Code nicht einfach „testen, ob es alles funktioniert" fragen und dann darauf vertrauen. Das Modell liefert ein Ergebnis, nicht eine Garantie.

Deine erste Stunde — so starte ich

Wenn du jetzt loslegen willst:

1. Schreibe das eine auf, was du seit Jahren bauen wolltest.
2. Beschreibe, wie es heute aussieht und wie es stattdessen aussehen sollte.
3. Identifiziere das Signal oder die Information, die es möglich macht.
4. Bestimme, wo das Ergebnis auftaucht (welcher Screen, warum) und wer es sehen darf.
5. Frag: Was wäre schlecht, wenn es versagt?

Dann geh zurück und wähle deine Bauform. Für die allererste, private Web-App mit minimalem Setup: Lovable — mit der Managed-Cloud, außer du weißt, dass Portabilität der Daten dir wichtiger ist (dann Supabase ab Tag 1). Wenn du mehr Kontrolle willst, öffne Codex oder Claude Code. Wenn ein Sensor drin ist: Raspberry Pi, Home Assistant oder ESP32 — und lass den Coding-Agenten an der Verdrahtung arbeiten.

Fazit: Die Form ist die halbe Miete

Die Schicht, die die meisten verpassen, ist nicht das Modell und nicht der Builder — sie ist die entscheidende Frage vor dem ersten Code: In welche der fünf Formen fällt dein Wunsch? Sobald die Form steht, sind die Tool-Entscheidungen fast selbstverständlich, die Sicherheitsfragen klar und der erste Build in Stunden statt Monaten möglich. Die Ära der Personal Software gehört jetzt nicht mehr nur den Technikern, die in der Nähe von Produkten leben — sondern den Menschen, die in der Nähe ihrer eigenen Probleme leben. Und genau die wissen oft am besten, was ihnen fehlt.

FAQ

Brauche ich für Personal Software wirklich eine Web-App?

Nicht automatisch — aber die Web-App ist in den meisten Fällen der schnellste, günstigste und portabelste Startpunkt, weil eine Version auf Laptop und Handy läuft und ohne App-Store geteilt werden kann. Nimm ein lokales Tool, wenn die Daten privat auf einer Maschine bleiben dürfen, und eine Native App erst dann, wenn du tiefe Handy-Funktionen wie Push, Bluetooth, Hintergrund-Location oder NFC wirklich brauchst. Wenn du unsicher bist: Starte mit der Web-App und beweise die Idee, bevor du in App-Store-Prozesse und deren Kosten einsteigst.

Was ist der Unterschied zwischen Coding-Agent und hostiertem Builder?

Der Coding-Agent (z. B. Codex, Claude Code) arbeitet in deinen eigenen Projektdateien, sieht Fehler, startet die App lokal und ändert Code, während der hostierte Builder (Lovable, Replit, Bolt) Environment, Datenbank, Auth und Publish in einem Dienst bündelt. Die praktische Konsequenz: Mit dem Agenten bleibt jede Komponente austauschbar — das Modell, der Host und die Oberfläche können unabhängig wechseln, während die Daten liegen bleiben. Mit dem hostierten Builder erhältst du den kürzesten Weg von Beschreibung zu Interface, zahlst aber mehr Plattform-Bindung.

Wie halte ich das Modell davon ab, mir überraschende Entscheidungen durchzudrücken?

Du änderst die Rolle: Das Modell agiert als Baupartner, der seine Entscheidungen offenzulegen hat, statt sie still im Code zu verstecken. Konkret führst du vier kleine Dateien — project.md (Ziel, Vorher/Nachher, Privatheit), decisions.md (jede Wahl mit Kosten/Daten/Deploy + Begründung), scenarios.md (deine echten Testfälle) und agent.md/claude.md (Verhaltensregeln für das aktuelle Tool) — und erwartest, dass das Modell bei jeder folgenschweren Wahl zwei bis drei Optionen benennt, eine empfiehlt und vor öffentlichem, teurem oder destruktivem Handeln fragt.

Lohnt sich eine Native App für ein internes Tool?

Für ein internes Tool ist das in den allermeisten Fällen überdimensioniert, weil App-Store-Reviews, Apple- und Google-Entwicklerkonten und Signierung echtes Verfahren kosten, das du nicht brauchen solltest. Eine Web-App im Browser oder eine interne Expo-Build für die eigene Familie deckt dieselben Use-Cases ab, ohne Store-Reibung. Wähle eine Native App erst, wenn dein Produkt funktional an eine tiefe Handy-Fähigkeit gekoppelt ist, die sich nicht wegbrechbar lässt — sonst zahlt die Web-App dieselbe Funktion zu einem Bruchteil des Aufwands.

Wie sorge ich dafür, dass zwei Haushalte sich in einer App nicht gegenseitig sehen?

Access Control gehört ins Backend, nicht ins Interface — ein ausgeblendeter Knopf ist keine echte Einschränkung. Erzwinge die Grenze in der Datenbank (bei Supabase über Row-Level-Security oder äquivalenten Mechanismen), sodass ein Login nur die Datensätze seines eigenen Haushalts lesen oder ändern kann, und ergänze diese Grenze als einen der Fälle in deinen scenarios.md-Tests. Vermeide außerdem, den Fehler „das sieht fertig aus" mit „das ist sicher" zu verwechseln: Prüfe aktiv, ob ein zweiter Haushalt die Daten des ersten nicht sehen kann, bevor du das Produkt an mehrere Parteien ausrollst.

Kann ich ein offenes Modell wie GLM in einem Coding-Tool fahren?

Ja — Modell und Arbeitsumgebung müssen nicht aus demselben Haus kommen, und das ist eine der größten Freiheiten im heutigen KI-Tooling. Du kannst ein offenes Modell wie GLM 5.2 oder 5.3 über einen unterstützten Coding-Tool-Stack mit API-Key betreiben und behältst gleichzeitig die Kontrolle über Environment, Daten und Deployment. Für den allerersten Build empfehle ich trotzdem, eine einzige Umgebung zu wählen, statt mehrere Modelle in ein Projekt zu stopfen — die Freiheit kommt aus dem Eigentum an Dateien und Daten, nicht aus dem gleichzeitigen Einsatz dreier Agenten.

Quellen

• Video, das die fünf Software-Formen systematisch aufschlüsselt: „Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did." — https://www.youtube.com/watch?v=joRXo6x7Pgk
• Lovable (hosted AI-Builder für Web-Apps): https://lovable.dev
• Replit (Builder mit stärkerer Infrastruktur): https://replit.com
• Bolt (schnelle Full-Stack-Web-Apps): https://bolt.new
• Supabase (Postgres + Auth + Storage): https://supabase.com
• Vercel (Hosting & Preview-Links): https://vercel.com
• GitHub Desktop (visuelle Versionskontrolle): https://desktop.github.com
• Raspberry Pi (kleiner Allzweck-Computer): https://www.raspberrypi.com
• ESP32 (Einzel-Sensor-Gerät): https://www.espressif.com
• Home Assistant (zentrale Anbindung bestehender Haus-Geräte): https://www.home-assistant.io
• Expo (ein Projekt → iOS + Android): https://expo.dev
• Codex (Coding-Agent): https://openai.com/index/introducing-codex/
• Claude Code (Coding-Agent): https://www.anthropic.com/claude-code
• GLM 5.2 / 5.3 (offene Modelle von Z.ai): https://z.ai
• SQLite (lokale Datenbank): https://sqlite.org