Zwanzig Apps in Eigenbau
Über digitale Unabhängigkeit, Single-File-HTML und die Frage, was heute eigentlich noch schwer ist
Der Ausgangspunkt
Die Diskussion über digitale Souveränität wird meist auf der ganz großen Bühne geführt: Gaia-X, europäische Cloud-Infrastruktur, Cloud Act, Schrems II, Beschaffungsrichtlinien für Behörden. Das ist alles richtig und wichtig, hat aber einen unangenehmen Nebeneffekt — es erzeugt den Eindruck, digitale Unabhängigkeit sei eine Frage von Milliardenprogrammen und Konsortialverträgen. Etwas, das andere Leute regeln müssen.
Für den einzelnen Nutzer, für einen Verein, für eine kleine Beratungsstelle oder ein Uni-Institut stellt sich die Frage viel konkreter: Meine Aufgaben liegen bei einem US-Anbieter. Mein Kalender liegt bei einem US-Anbieter. Meine Notizen, meine Kontakte, meine Präsentationen, meine Tabellen, meine Zwischenablage über Geräte hinweg — alles bei US-Anbietern, alles in proprietären Formaten, alles mit Abo, alles mit AGB-Änderungen im Halbjahrestakt, und in zunehmendem Maß alles auch als Trainingsmaterial für irgendein Modell.
Die übliche Antwort darauf lautet: Nimm eine Open-Source-Alternative. Das funktioniert oft, hat aber Grenzen. Open-Source-Suiten sind entweder große Systeme, die man administrieren muss, oder sie tun genau das, was ihr Entwickler wollte — und nicht das, was man selbst braucht. Der Kompromiss ist manchmal größer als der bei der proprietären Lösung.
Es gibt eine dritte Möglichkeit, und die ist in den letzten zwei Jahren erst praktikabel geworden: Man baut sich die Anwendungen selbst. Nicht als heroisches Wochenendprojekt, sondern als Nebenprodukt der eigentlichen Arbeit — im Dialog mit einem Sprachmodell, in Sitzungen von zwanzig Minuten bis zwei Stunden, mit einem Ergebnis, das man am selben Abend benutzt.
Dieser Artikel beschreibt, wie das konkret aussieht: eine Sammlung von inzwischen rund zwanzig Anwendungen, die als „Werkbank" zusammengefasst sind, alle nach denselben Prinzipien gebaut, alle im täglichen Einsatz.
1. Die entscheidende Entscheidung: eine Datei
Die wichtigste architektonische Festlegung wurde ganz am Anfang getroffen und seither nie revidiert: Jede Anwendung ist genau eine HTML-Datei. Kein Build-Schritt, kein Framework, keine ausgelagerten JavaScript-Dateien, kein npm install, kein Bundler, kein Transpiler. CSS und JavaScript stehen eingebettet in derselben Datei wie das Markup.
Das klingt nach einer Einschränkung und ist in Wahrheit die Voraussetzung für alles Weitere. Die Gründe:
Die Datei ist das Programm. Man kann sie per Mail verschicken, auf einen USB-Stick legen, in ein Backup packen, per Doppelklick öffnen. Es gibt keinen Unterschied zwischen „dem Quellcode" und „der Anwendung". Wer die Datei hat, hat alles.
Kein Verfall durch Abhängigkeiten. Ein Node-Projekt von 2019 lässt sich heute oft nicht mehr ohne Weiteres bauen — nicht wegen des eigenen Codes, sondern wegen der 900 transitiven Abhängigkeiten. Eine HTML-Datei, die nur Browser-APIs benutzt, läuft in fünf Jahren noch. Das ist keine Vermutung, das ist die Erfahrung mit einer Plattform, deren Betreiber Rückwärtskompatibilität religiös ernst nimmt.
Der ideale Umfang für die Arbeit mit einem Sprachmodell. Eine vollständige Anwendung passt in ein Kontextfenster. Das Modell sieht immer alles: Datenmodell, UI, Logik, Styling. Es gibt keine Situation, in der eine Änderung in Datei A eine Annahme in Datei F bricht, die niemand gerade anschaut. Wer schon einmal versucht hat, ein LLM durch ein verteiltes Repository zu steuern, kennt den Unterschied.
Debugging ohne Werkzeugkette. Rechtsklick, Quelltext anzeigen — und man liest genau das, was läuft. Keine Source Maps, keine minifizierten Namen.
Der Preis dieser Entscheidung ist Disziplin. Man verzichtet auf Komponentenbibliotheken, auf reaktive Frameworks, auf TypeScript. Man schreibt Zustandsverwaltung selbst. Das ist bei einer Anwendung von 3.000 bis 8.000 Zeilen völlig beherrschbar — und diese Größenordnung reicht für erstaunlich vollständige Programme.
Ein gemeinsames Gesicht
Damit zwanzig einzelne Dateien nicht wie zwanzig einzelne Dateien wirken, gibt es ein festes Designsystem, das in jeder Anwendung identisch umgesetzt ist: Fraunces für Überschriften, Inter für Fließtext, JetBrains Mono für Metadaten und Code. Ein dunkles Petrol (#2f4f4f) als Akzentfarbe, im Dunkelmodus zu einem helleren Grünton aufgehellt. Alle Farben als CSS Custom Properties — --paper, --card, --ink, --muted, --line, --accent, --danger, --radius — sodass der Hell-Dunkel-Umschalter überall gleich funktioniert. Die Oberflächensprache ist durchgehend Deutsch, bis hinein in Variablen- und Funktionsnamen.
Das ist keine Kosmetik. Ein einheitliches Erscheinungsbild ist der Unterschied zwischen „ein paar Bastelskripte" und „meine Software". Es senkt auch die Hürde für neue Anwendungen erheblich: Das Grundgerüst ist immer dasselbe, das Modell kennt es, eine neue App startet nie bei null.
2. Das Inventar
Die Anwendungen lassen sich grob in fünf Gruppen ordnen. Die Werkbank selbst — der Launcher — bildet diese Gruppierung in einer klappbaren Seitenleiste ab und lädt die einzelnen Anwendungen in einen iframe-Bereich. Die Zuordnung lässt sich pro App manuell überschreiben, der Zustand der Gruppen wird lokal gespeichert, und Alt+1 bis Alt+9 springen direkt.
Büro und Produktivität
todo.html — Aufgabenverwaltung mit Tags, Prioritäten, Wiederholungen, Unteraufgaben, einer Ampelansicht für Dringlichkeit und einem Papierkorb. Das Kernstück des Alltags.
kalender.html — Kalender mit Tag-System, Import und Export im ICS-Format (damit die Daten jederzeit in jedes andere Programm wandern können), wiederkehrenden Terminen und einer Verbindung zur Netzwerk-App, sodass Aufgaben aus Kontakten heraus entstehen können.
pads.html — Rich-Text-Editor mit Markdown-Import und -Export, Wiki-Links zwischen Notizen, einem Literaturbereich und einer Export-Funktion direkt in ein Obsidian-Vault. Wer seine Notizen jemals wieder herausnehmen will, kann das mit einem Klick.
tabellen.html — Tabellenkalkulation mit Serversynchronisierung. Kein Excel-Ersatz, aber vollkommen ausreichend für Listen, Auswertungen, Planungen.
folien.html — Präsentationswerkzeug mit verschiedenen Layouts und Themes, Markdown-Import und -Export. Ein Vortrag entsteht als Textdatei und wird zur Folie.
clipboard.html — verschlüsselte Zwischenablage über Geräte hinweg. Text auf dem Rechner kopieren, auf dem Handy einfügen. Mit direkter Übergabe an Pads.
freitextimport.html — vermutlich die unterschätzteste Anwendung der Sammlung: Man wirft unstrukturierten Text hinein — eine Mail, eine Sitzungsnotiz, eine Sprachnachricht als Transkript — und heraus fallen strukturierte Termine, Aufgaben und Notizen, die in die jeweils richtige Datenbank geschrieben werden.
mail.html — Mail-Client auf Gmail-Basis mit OAuth und abgeschirmtem Rendering von HTML-Nachrichten.
Daten und Verwaltung
netzwerk.html — verschlüsselte Kontakt- und Netzwerkverwaltung mit fünf Entitätstypen (Personen, Organisationen, Beziehungen, Vorgänge, Notizen). Für die Koordination über mehrere Initiativen hinweg der zentrale Ort.
social-media.html — Redaktionsplanung für mehrere Organisationen, mit verschlüsseltem Zugangsdaten-Tresor und Anzeige von Planungslücken.
backup.html — Sicherung und Wiederherstellung über mehrere Datenbankprojekte hinweg. Die Versicherung gegen das eigene Werk.
Beratung und Fachliches
medikationscheck.html — Prüfung von Wechselwirkungen mit Patientenkontext, gestützt auf die openFDA-Label-Schnittstelle.
Karten, Wetter, Medien
karte.html — Kartenanwendung auf Leaflet-Basis mit Nominatim-Suche, Valhalla-Routing und Sprachnavigation.
wetterstation.html — Wetter über Open-Meteo, mit einer eigenen Auswertung für Segelbedingungen.
mediathek-suche.html — Suche über die deutschen öffentlich-rechtlichen Mediatheken, mit zwei parallel angebundenen Indizes, Live-TV-Bereich und einem eigenen Proxy für die Zugriffsbeschränkungen der Browser.
plattenschrank.html — Musikplayer und Playlist-Verwaltung auf YouTube-Basis.
Familie und Spiel
supabase-chat.html — verschlüsselter Familienchat in Echtzeit.
kunstquiz.html — Kunst- und Musikquiz, das seine Fragen live aus Wikipedia und Wikimedia zieht.
Ein Jump-and-Run mit über fünfzehn Ebenen, Touch-Steuerung und einer Rahmenhandlung, in der Familienmitglieder gerettet werden. Der Beweis, dass die Methode nicht auf Formulare beschränkt ist.
3. Wie das technisch zusammenhält
Ein Server, den man nicht administriert
Alle Anwendungen sprechen mit einer gemeinsamen PostgreSQL-Datenbank über eine REST-Schnittstelle (Supabase). Das ist der entscheidende Trick, der reines Frontend-Bauen überhaupt ermöglicht: Man braucht kein eigenes Backend zu schreiben, weil die Datenbank selbst eine HTTP-Schnittstelle mitbringt. Tabelle anlegen, fertig — sie ist abrufbar.
Sicherheit wird dabei über Row Level Security in der Datenbank selbst geregelt, nicht in der Anwendung. Für unkritische Daten offene Richtlinien, für personenbezogene Daten Richtlinien, die eine Anmeldung erzwingen. Das SQL dafür wird vorher im Editor ausgeführt — Schema first.
Für Echtzeitfunktionen (Chat) kommt der WebSocket-Kanal derselben Plattform zum Einsatz. Für Backups eine SQL-Funktion, die die Tabellenliste ausliefert.
Verschlüsselung, die auch ohne HTTPS funktioniert
Mehrere Anwendungen verschlüsseln ihre Inhalte clientseitig: Zwischenablage, Kalender, Netzwerk, Chat und der Zugangsdaten-Tresor der Social-Media-App. Verfahren ist AES-256-GCM, der Schlüssel wird per PBKDF2 mit 250.000 Iterationen aus einer Passphrase abgeleitet. Der Server sieht in diesen Tabellen nur Chiffrat. Die Passphrase liegt ausschließlich im sessionStorage und wird nie dauerhaft gespeichert.
Hier lag die härteste technische Hürde des ganzen Projekts, und sie ist lehrreich: crypto.subtle steht im Browser nur in einem „sicheren Kontext" zur Verfügung — also bei HTTPS oder auf localhost. Ruft man dieselbe Datei über die lokale IP-Adresse im Heimnetz auf, ist die Krypto-API schlicht nicht vorhanden. Die Anwendung startet, sieht normal aus und kann nichts entschlüsseln.
Die Lösung war eine vollständige Implementierung von PBKDF2-SHA-256 und AES-256-GCM in reinem JavaScript, die als Rückfallebene einspringt. Entscheidend dabei: Das Ausgabeformat ist byteidentisch mit dem der Browser-API. Was auf dem Laptop über HTTPS verschlüsselt wurde, lässt sich auf dem Tablet über HTTP im LAN lesen und umgekehrt. Zwei echte Fehler mussten dabei gefunden werden — ein Off-by-one in der S-Box und ein Übertragsfehler im GCM-Zähler. Beide wurden durch Vergleichstests gegen die native Implementierung entdeckt, nicht durch Nachdenken.
Schlüsselverteilung
Damit man nicht in jeder App einzeln Zugangsdaten eingeben muss, gibt es ein gemeinsames Modul: Es sucht Schlüssel zuerst im lokalen Speicher, nimmt zweitens entgegen, was die Werkbank per postMessage an das eingebettete Fenster schickt, und fragt erst als letzte Möglichkeit nach. Für den Betrieb einzelner Dateien ohne Werkbank existiert ein hinterlegtes Notfall-Verzeichnis.
Auch hier eine Falle, die man einmal erlebt haben muss: Eine Datei, die per Doppelklick geöffnet wird, hat den Ursprung "null" — als Zeichenkette. Wer beim postMessage einen konkreten Zielursprung angibt oder in der Prüfliste erlaubter Ursprünge nur echte Domains führt, bekommt eine Anwendung, die im Browser tadellos und vom Dateisystem gar nicht funktioniert.
Betrieb
Für den Zugriff im Heimnetz und von unterwegs läuft ein Tunnel, für die öffentliche Bereitstellung ein statischer Hosting-Dienst, für die Umgehung von Zugriffsbeschränkungen bei fremden Schnittstellen ein kleiner Proxy mit Domain-Positivliste. Externe Bibliotheken — nur eine Handvoll: Supabase-Client, hls.js, Turndown, marked.js, Leaflet — kommen über CDN.
4. Wie man damit arbeitet
Im Alltag öffnet man die Werkbank, wählt links eine Anwendung, und die läuft im Hauptbereich. Auf dem Handy funktioniert dasselbe im Browser. Die Daten sind überall dieselben, weil sie in der Datenbank liegen und nicht im Gerät.
Was dabei entsteht, ist eine Eigenschaft, die man bei gekaufter Software praktisch nie hat: Die Anwendungen kennen einander. Aus einem Kontakt im Netzwerk wird eine Aufgabe. Aus einer Notiz in der Zwischenablage wird ein Pad. Aus einem Absatz Freitext werden drei Termine und zwei Aufgaben in zwei verschiedenen Datenbanken. Die Präsentation entsteht aus derselben Markdown-Datei, die auch das Pad füllt.
Das ist der eigentliche Ertrag. Nicht, dass jede einzelne App besser wäre als ihr kommerzielles Vorbild — das ist sie meist nicht. Sondern dass sie zusammenpassen, weil sie für einen einzigen Arbeitsablauf gebaut wurden, nämlich den eigenen.
Ebenso wichtig: Der Ausgang steht immer offen. Kalender exportiert ICS. Pads exportiert Markdown und schreibt direkt in ein Obsidian-Vault. Tabellen und Folien beherrschen Standardformate. Die Backup-App zieht die gesamte Datenbank. Es gibt keinen Zustand, in dem die eigenen Daten in dieser Sammlung gefangen sind — und das ist die härteste Form von Unabhängigkeit, die man erreichen kann.
5. Der Preis
Die Kostenrechnung ist der Teil, bei dem die meisten Leute ungläubig schauen.
- Datenbank und Schnittstelle: kostenloses Kontingent reicht für diesen Umfang; bei Bedarf etwa 25 US-Dollar im Monat
- Hosting und Tunnel: kostenloses Kontingent
- Domain: rund 10 bis 15 Euro im Jahr
- Sprachmodell: 20 bis 30 Euro im Monat
Dem gegenüber steht ein Abo-Bündel aus Aufgaben-App, Notiz-App, Kalender, Cloud-Speicher, Passwort-Manager und Office-Paket, das für eine Familie schnell bei 30 bis 60 Euro monatlich liegt — bei geringerer Passgenauigkeit und ohne jede Kontrolle über Format und Verbleib der Daten.
An Zeit: Eine einfache Anwendung entsteht in ein bis zwei Stunden. Eine komplexe mit Verschlüsselung, Synchronisierung und Sonderfällen in zwei bis vier Sitzungen. Danach fällt Pflege an, aber sie ist gering, weil die Abhängigkeiten gering sind.
6. Die ehrliche Bilanz: Wo die Unabhängigkeit endet
Hier muss man deutlich werden, sonst wird der Artikel unredlich.
Die Datenbankplattform ist ein US-Unternehmen. Der Hosting- und Tunnel-Anbieter ist ein US-Unternehmen. Das Sprachmodell, mit dem gebaut wird, stammt von einem US-Unternehmen. Der Mail-Client hängt an einem US-Konzern, der Musikplayer ebenfalls, das Kartenmaterial teilweise. Wer diese Sammlung als „unabhängig von US-Software" bezeichnet, sagt die Unwahrheit.
Was tatsächlich erreicht ist, ist etwas anderes — und immer noch viel wert:
Unabhängigkeit von proprietären Anwendungen. Die Logik gehört einem selbst. Sie ist lesbar, änderbar, kopierbar. Keine Funktion verschwindet, weil ein Produktmanager sie gestrichen hat.
Unabhängigkeit vom Datenformat. Alles liegt in PostgreSQL, dem am besten dokumentierten und am breitesten unterstützten Datenbanksystem der Welt. Ein pg_dump ist ein pg_dump.
Austauschbarkeit der Anbieter. Und das ist der eigentliche Punkt: Die verwendete Plattform ist selbst quelloffen und lässt sich selbst betreiben. Zwischen „läuft bei einem US-Anbieter" und „läuft auf einem Server in Nürnberg" liegt bei dieser Architektur eine geänderte URL und ein geänderter Schlüssel — nicht eine Neuentwicklung.
Wer die Unabhängigkeit weitertreiben will, hat konkrete Schritte zur Hand:
- Datenbank selbst hosten — PostgreSQL mit PostgREST auf einem Server bei Hetzner, netcup, IONOS, Scaleway oder OVH, oder das quelloffene Gesamtpaket im Docker-Verbund. Der Anwendungscode bleibt unverändert.
- Tunnel und Hosting ersetzen — Caddy oder nginx mit automatischem Zertifikat, WireGuard oder Tailscale für den Fernzugriff, statische Auslieferung von einem beliebigen Webserver.
- Bibliotheken lokal ablegen statt über CDN. Für Single-File-HTML ohnehin naheliegend: Die wenigen benötigten Skripte lassen sich direkt einbetten.
- Mail auf IMAP/SMTP umstellen, etwa gegen mailbox.org oder Posteo, statt gegen die Gmail-Schnittstelle.
- Karten und Routing selbst betreiben — OpenStreetMap-Daten, ein eigener Tile-Server, eine eigene Valhalla-Instanz. Aufwendig, aber möglich.
- Beim Sprachmodell europäische Anbieter (Mistral) oder lokal laufende offene Modelle über Ollama oder llama.cpp. Für das Schreiben dieser Art von Code sind die stärksten Modelle noch deutlich im Vorteil — aber der Abstand schrumpft, und für Änderungen an bestehendem Code reichen kleinere Modelle bereits häufig.
Und der wichtigste Punkt: Der Code läuft nach dem Umzug weiter. Genau das ist der Unterschied zwischen einer Abhängigkeit und einer Anbieterwahl.
7. Sicherheit — was das Modell leistet und was nicht
Ebenfalls ehrlich zu benennen: Ein öffentlich erreichbares Frontend mit eingebettetem Zugangsschlüssel und offenen Datenbankrichtlinien bedeutet öffentlichen Schreibzugriff. Wer die Datei liest, hat den Schlüssel. Den Schlüssel zu verschleiern ist Selbstbetrug.
Die belastbare Sicherheitsgrenze liegt woanders:
- Ein Zugangsschutz vor der Anwendung — Zero-Trust-Zugang beim Hosting-Anbieter, Basic Auth im Webserver, oder gar keine öffentliche Erreichbarkeit und nur VPN-Zugriff. Das ist die eigentliche Tür.
- Datenbankrichtlinien, die eine Anmeldung erzwingen, überall dort, wo personenbezogene Daten liegen.
- Clientseitige Verschlüsselung für alles wirklich Vertrauliche. Selbst bei kompromittiertem Datenbankzugang bleibt dort nur Chiffrat.
Eine praktische Warnung aus dem Betrieb: Datenbankrichtlinien scheitern gern still. Man bekommt eine leere Liste statt einer Fehlermeldung und sucht den Fehler stundenlang in der eigenen Logik. Deshalb geben alle Anwendungen die Felder message, details, hint und code der Antwort sichtbar in der Oberfläche aus und brechen bei Authentifizierungsfehlern sofort ab, statt weiterzulaufen.
8. Wie man mit einer KI so arbeitet
Weil das die eigentlich interessante Frage für Nachahmer ist — hier das Verfahren, das sich bewährt hat:
Absicht statt Spezifikation. Man beschreibt, was man erreichen will, nicht wie es implementiert werden soll. „Kalender mit Tags und ICS-Import, gleiches Design wie die anderen" ist ein besserer Auftrag als eine Anforderungsliste mit dreißig Punkten. Die Details klären sich in der Benutzung.
Nicht die ganze Welt auf einmal. Erst die kleinste Fassung, die tatsächlich läuft. Dann benutzen. Dann erweitern. Anwendungen, die aus dem Gebrauch wachsen, treffen den Bedarf; Anwendungen, die aus einem Konzeptpapier wachsen, meistens nicht.
Änderungen als Patch, nicht als Neuschrieb. Bestehende Dateien werden über gezielte Textersetzungen geändert, mit Prüfung, dass der Ankerpunkt genau einmal vorkommt. Das verhindert die häufigste Frustration beim Arbeiten mit LLMs: dass bei jeder kleinen Änderung die ganze Datei neu generiert wird und dabei still Funktionen verschwinden.
Tests vor Auslieferung. Für eine Single-File-HTML-Anwendung reicht dafür erstaunlich wenig: linkedom als DOM-Ersatz, das vm-Modul von Node zum Ausführen des extrahierten Skripts, gefälschte fetch- und Datenbankantworten. Damit lassen sich Zustandslogik, Sortierung, Wiederholungsregeln und Verschlüsselungs-Rundläufe automatisch prüfen. Die feste Reihenfolge lautet: strukturelle Prüfung der Bezeichner → node --check für die Syntax → Funktionstests → Auslieferung. Diese Kette hat wiederholt echte Fehler abgefangen, die beim Durchlesen nicht aufgefallen wären.
Fehler sind Wissen. Die interessanten Erkenntnisse dieses Projekts — der sichere Kontext bei der Krypto-API, der Ursprung "null" bei lokalen Dateien, die Notwendigkeit deterministischer Standard-IDs (zufällig vergebene IDs beim ersten Start vervielfältigen sich über Geräte hinweg unbegrenzt, wenn zusammengeführt wird), die nicht mitgezogenen Sequenzen nach einer Wiederherstellung, der Stapelüberlauf beim Spread-Operator auf großen Byte-Feldern — stehen in keinem Tutorial. Sie entstehen im Betrieb und gehören dokumentiert, sonst macht man sie zweimal.
9. Was als Nächstes sinnvoll wäre
Die Sammlung hat erkennbare Lücken. Einige Vorschläge, geordnet nach dem Verhältnis von Nutzen zu Aufwand.
Naheliegend und mit hohem Ertrag
Dokumentenarchiv. Datei-Ablage mit Volltextsuche und Verschlagwortung. Der offensichtliche nächste Schritt, sobald der Datei-Speicher der Plattform angebunden ist — was für die Bilder in der Folien-App ohnehin ansteht. Mit Texterkennung für Scans und PostgreSQL-Volltextsuche wird daraus ein vollwertiges kleines Dokumentenmanagement.
Vereins- und Sitzungsverwaltung. Für die Arbeit in Vereinen und Initiativen die größte Zeitersparnis überhaupt: Tagesordnung erstellen, Beschlüsse mitschreiben, Protokoll erzeugen, Einladung versenden, Anwesenheit erfassen. Alles Dinge, die heute in Word und Mail von Hand passieren. Eine Erweiterung um Mitgliederverwaltung mit Beiträgen und SEPA-Erzeugung (pain.008) hätte für kleine Vereine sofort spürbaren Wert.
Haushaltsbuch und Finanzübersicht. Import von Kontoumsätzen im CAMT- oder MT940-Format, Regelwerk zur automatischen Kategorisierung, Auswertung. Vollständig lokal, ohne dass Kontodaten an einen Dienstleister gehen — hier ist der Souveränitätsgewinn besonders greifbar.
PDF-Werkzeugkasten. Zusammenführen, teilen, drehen, Seiten entfernen, Formulare ausfüllen — direkt im Browser mit pdf-lib, ohne dass jemals eine Datei einen fremden Server erreicht. Der Ersatz für die üblichen kostenlosen Konverter-Seiten, bei denen man nie weiß, wo das Dokument landet.
Scanner. Handykamera, Perspektivkorrektur, Kontrastanhebung, PDF-Ausgabe, direkt ins Dokumentenarchiv.
Für den akademischen und beratenden Kontext
Literaturverwaltung. DOI-Abfrage über Crossref, BibTeX-Export, Zotero-kompatible Ausgabe, Anbindung an den bereits vorhandenen Literaturbereich in Pads. Für wissenschaftliches Arbeiten die Lücke, die derzeit am deutlichsten spürbar ist.
Fragebogen- und Erhebungswerkzeug. Fragebögen anlegen, per Link verteilen, Antworten sammeln, deskriptiv auswerten, als CSV exportieren. Ein schlanker Ersatz für LimeSurvey — und mit dem großen Vorteil, dass die Daten auf einem selbst kontrollierten Server bleiben, was bei Erhebungen mit Personenbezug den Unterschied zwischen genehmigungsfähig und nicht genehmigungsfähig ausmachen kann.
Auswertung im Browser. Deskriptive Statistik, Kreuztabellen, einfache Tests, Diagramme — auf Basis der Tabellen-App oder als eigenständiges Werkzeug. Mit Pyodide ließe sich sogar echtes Python samt pandas im Browser ausführen.
Alltag und Familie
Rezepte und Essensplanung mit automatisch erzeugter Einkaufsliste, die als Aufgaben in todo.html landet.
Haushaltsinventar mit QR-Etiketten für Kisten und Regale. Klingt banal, spart beim ersten Umzug oder bei der ersten Versicherungsmeldung mehr Zeit, als der Bau gekostet hat.
Karteikarten mit verteilter Wiederholung und Anki-Import. Bewährtes Verfahren, triviale Datenstruktur, hoher Nutzen.
Feed-Reader für RSS und Podcasts. Angesichts des Zustands der sozialen Netzwerke die vielleicht sinnvollste Rückkehr zu einer offenen Technik, die es gibt.
Fotogalerie auf Basis des Datei-Speichers — die eigene Alternative zu den Foto-Diensten der großen Anbieter.
Passwort-Tresor. Die Krypto-Bausteine liegen bereits fertig vor; ein eigenständiger Tresor mit Generator und Ablaufwarnungen ist von dort aus ein kurzer Weg.
Infrastruktur, die allen Anwendungen zugutekäme
Progressive-Web-App-Hülle mit Service Worker. Damit würden alle Anwendungen offline lauffähig, auf dem Startbildschirm installierbar und deutlich schneller. Vermutlich die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung in dieser ganzen Liste.
Übergreifende Suche. Ein Suchfeld in der Werkbank, das Aufgaben, Notizen, Kontakte, Termine und Dokumente gleichzeitig durchsucht. Mit pgvector ließe sich das um semantische Suche erweitern.
Automatisiertes Backup statt manuellem Anstoßen — ein zeitgesteuerter Auftrag, der Sicherungen verschlüsselt ablegt und im Fehlerfall benachrichtigt.
Ein Wochen-Dashboard, das aus Kalender, Aufgaben, Wetter und offenen Vorgängen einen Morgenüberblick erzeugt.
Fazit
Die verbreitete Vorstellung, eigene Software zu schreiben sei etwas für Fachleute, stammt aus einer Zeit, in der der Engpass das Erzeugen von Code war. Dieser Engpass ist weitgehend verschwunden. Was geblieben ist — und was auch bleiben wird — ist die Fähigkeit zu wissen, was man eigentlich will, Ergebnisse zu prüfen, statt ihnen zu glauben, und Entscheidungen zu treffen, die in zwei Jahren noch tragen.
Genau darin liegt der Souveränitätsgewinn. Nicht darin, dass kein Byte mehr über amerikanische Server läuft — das wäre in dieser Konstruktion schlicht gelogen. Sondern darin, dass die Anwendungen, mit denen man arbeitet, verstanden, änderbar und umzugsfähig sind. Dass ein Anbieterwechsel eine geänderte URL bedeutet und keinen Datenverlust. Dass eine fehlende Funktion eine Frage von zwei Stunden ist und nicht von einem Feature-Request, der nie beantwortet wird.
Zwanzig Anwendungen. Eine Datei pro Anwendung. Ein Designsystem. Eine Datenbank, die man mitnehmen kann.
Das ist keine Ausnahmeleistung. Es ist eine Methode — und sie steht jedem offen, der bereit ist, seine Werkzeuge selbst in die Hand zu nehmen.