Personal Software: Was nach dem Personal Computer kommt
Eine Studierendengruppe baut in einer halben Stunde einen persönlichen Shop über fremde Shopify-Shops. Was Personal Software ist, woher der Begriff kommt und warum schlechte UX künftig nicht nur zum Absprung führt, sondern zum Selbstbau.
Die halbe Stunde
Eine halbe Stunde, ein Prompt. Danach lief auf dem Laptop einer Studierendengruppe ein Shop. Keiner, der etwas verkauft, sondern einer, der die Produkte mehrerer Shopify-Shops an einem Ort zeigt. Ohne Werbebanner, mit eigener Suche und eigener Produktdarstellung. Bei Kleidung zeigt er, welche Größen gerade verfügbar sind. Und er hat einen eigenen Warenkorb. Wer bestellen will, landet per Link im Originalshop, und dort liegt der Warenkorb schon fertig gepackt. Bezahlung, Versand und Retoure bleiben beim Shop.
Das Ganze entstand in meinem Modul „KI in der Softwareentwicklung“, das ich in diesem Semester zum ersten Mal unterrichte. Die Gruppen arbeiten an eigenen Projekten, und ein Teil ist Pflicht: Harness Engineering. Gemeint ist, den Coding Agent mit Regeln, Architekturvorgaben, Tests und Prüfschritten so einzuengen, dass er genau das baut, was gewünscht ist, und zwar so, wie es gewünscht ist. Was ein Harness ist, habe ich am Beispiel von Interviewfragen mit einem LLM beschrieben.
Technisch ist an dem Shop nichts Exotisches. Viele Shopify-Shops liefern ihren Produktkatalog öffentlich als JSON aus, mit Varianten und Verfügbarkeit, meist aber ohne Lagerbestand. Und Shopify dokumentiert sogenannte Cart Permalinks, mit denen sich ein Warenkorb über einen Link vorbefüllen lässt.
Dieselbe Idee, vier Semester später
Das Bemerkenswerte ist nicht der Shop. Dieselbe Gruppe hatte genau dieses Projekt schon im ersten Semester begonnen und dann abgebrochen. Nicht, weil die Idee schlecht war, sondern weil die Zeit nicht reichte. Katalog anbinden, Suche bauen, Größen auswerten, Warenkorb übergeben: Für Erstsemester neben allen anderen Modulen war das zu viel.
Jetzt war es eine Fingerübung vor dem eigentlichen Projekt.
Nicht die Idee hat sich geändert, sondern der Preis. Und als ich gefragt habe, ob sie daraus ein Produkt machen wollen, kam ein klares Nein. Sie wollten einen Shop für sich. Für niemanden sonst.
Vom Personal Computer zur Personal Software
Der Personal Computer hat den Rechner aus dem Rechenzentrum auf den Schreibtisch geholt. Persönlich war dabei die Hardware. Die Software darauf blieb Massenware: dieselbe Textverarbeitung, dieselbe Tabellenkalkulation für Millionen Menschen, gestaltet von Anbietern für einen gedachten Durchschnittsnutzer. Wer etwas anderes wollte, musste programmieren können oder jemanden bezahlen.
Coding Agents verschieben diese Grenze. Wenn funktionierende Software eine halbe Stunde kostet, lohnt sie sich für eine einzelne Person. Das ist der Kern dessen, was ich Personal Software nenne.
Neu ist der Begriff allerdings nicht, und das will ich ehrlich einordnen. Robin Sloan hat 2020 eine Messenger-App nur für seine Familie gebaut und sie mit selbstgekochtem Essen verglichen. Maggie Appleton hat 2024 die „Barefoot Developers“ beschrieben, eine neue Gruppe zwischen Endnutzern und Profi-Entwicklern. Lee Robinson hat Anfang 2025 denselben Vergleich mit dem PC gezogen, am Beispiel eines Baby-Trackers. Und Adam Waxman hat im Juli 2026 unter dem Titel „Software for One“ fünf eigene Apps beschrieben, die er mit Claude Code gebaut hat.
Eine schöne Fußnote: Der Verlag, der 1979 VisiCalc herausbrachte, die erste Killer-App des Personal Computers, hieß Personal Software, Inc. Damals stand der Name für Software für den persönlichen Computer, nicht für Software einer Person.
Am nächsten an meinem Fall ist ein Text von 2004. Clay Shirky beschrieb „Situated Software“: Software für eine konkrete soziale Gruppe statt für generische Nutzer, bei der Skalierung kein Ziel ist. Entstanden ist die Beobachtung in seiner Lehrveranstaltung an der NYU, und gebaut haben die Projekte Studierendengruppen. Zweiundzwanzig Jahre später sehe ich in meinem Seminar dasselbe Muster, nur zu einem Bruchteil des Aufwands.
Ich präge den Begriff also nicht. Ich gebe ihm eine UX-Lesart. Meine Arbeitsdefinition: Personal Software ist Software, die eine Person oder eine kleine Gruppe für sich selbst baut oder von einem Agenten bauen lässt, ohne sie anderen anbieten zu wollen. Erfolg misst sich allein daran, ob sie den eigenen Zweck erfüllt. Sie hat kein Geschäftsmodell, darf kurzlebig sein und wird bei Bedarf neu gebaut statt gepflegt.
Zwei Spielarten
Die meisten bisherigen Texte beschreiben eine Spielart: das eigene Werkzeug. Eine App für eigene Daten und Abläufe, etwa Robinsons Baby-Tracker oder mein ProjectHub, ein persönliches Cockpit für Projekte, Aufgaben und Liquidität. Ein Anbieter kommt darin nicht vor. Ich ersetze keine fremde Oberfläche, ich baue mir etwas, das es so nicht gab.
Der Shop der Studierenden ist etwas anderes: eine eigene Oberfläche über einem fremden Angebot. Die Gruppe akzeptiert das Sortiment der Shops und deren Abwicklung. Was sie nicht akzeptiert, ist die Oberfläche. Also trennt sie Daten und Transaktion von der Darstellung und ersetzt nur die Darstellung.
Diese zweite Spielart ist für UX der interessante Teil, und in der Literatur ist sie kaum ausgearbeitet.
Was das für UX heißt
Bisher war die Reaktion auf eine schlechte Oberfläche der Absprung. Nutzer gehen zur Konkurrenz oder kommen nicht wieder. Mit Personal Software gibt es eine dritte Option: Sie bleiben beim Angebot und werfen nur die Oberfläche weg.
Wenn Nutzer sich ihre eigene Oberfläche bauen, ist das die härteste Form von Usability-Feedback. Und es ist Feedback, das der Anbieter nie zu sehen bekommt. Im Analytics-Dashboard erscheint die Gruppe als Besucher, der direkt im Warenkorb landet und kauft. Eine beachtliche Conversion, ganz ohne Suche, Filter oder Werbefläche.
Damit verschiebt sich, was die eigentliche Nutzerschnittstelle ist. Das Frontend wird austauschbar. Der Produktkatalog, die Verfügbarkeit, der Checkout per Link werden zur Schnittstelle, an der Nutzer andocken. Wer bei Shopify einkauft, nutzt mit diesem Shop im Grunde eine API, nur ohne es zu wissen.
Dieselbe Bewegung gibt es auch im Großen. Unter dem Stichwort Agentic Commerce suchen und kaufen KI-Agenten im Auftrag ihrer Nutzer und umgehen dabei die Shopfronts. Der Unterschied: Dort baut ein Plattformanbieter die neue Oberfläche, hier bauen die Nutzer sie selbst. Das Muster ist dasselbe. Die Oberfläche des Anbieters ist nicht mehr der Ort, an dem die Nutzung stattfindet.
Das heißt nicht, dass Design überflüssig wird. Robinson argumentiert umgekehrt: Wer selbst kocht, schätzt gute Restaurants mehr. Das halte ich für plausibel. Aber es verschiebt die Frage, die sich UX-Teams stellen müssen. Nicht mehr nur: Ist unsere Oberfläche gut genug, damit Nutzer bleiben? Sondern: Wofür kommen Nutzer noch auf unsere Oberfläche, wenn sie ihre eigene bauen können?
Die Grenzen
Personal Software ist kein Selbstläufer, und ich will die Grenzen nicht kleinreden.
Sicherheit. Veracode hat 2025 KI-generierten Code in über 100 Sprachmodellen getestet. In 45 % der Proben fanden sich Sicherheitslücken. Für einen Shop, der nur anzeigt und per Link weiterreicht, ist das überschaubar. Sobald Zahlungsdaten oder Personendaten im Spiel sind, ist es das nicht mehr. Dass die Studierenden die Bezahlung beim Originalshop lassen, ist deshalb kein Zufall, sondern die richtige Entscheidung.
Wartung. Waxman findet die Wartung seiner Apps bisher leicht. Martin Fowler warnt dagegen, dass schlecht strukturierter Code auch für Sprachmodelle schwer erweiterbar wird. Ich kenne beide Seiten: Mein ProjectHub ist inzwischen so groß, dass er gepflegt werden will.
Abhängigkeit. Die eigene Oberfläche lebt von fremden Schnittstellen. Ein Shop kann seinen öffentlichen Katalog abschalten, und große Plattformen begrenzen externe KI-Agenten bereits. Cory Doctorow nennt das Andocken ohne Erlaubnis „Adversarial Interoperability“. Was heute offen ist, kann morgen gesperrt sein. Und die Nutzungsbedingungen einzelner Shops können das Auslesen ausschließen, auch wenn es nur für den privaten Gebrauch ist.
Zugang. Noch ist das eine Sache für Technikaffine. Die Studierenden wissen, was ein JSON-Endpunkt ist. Die meisten Menschen wissen es nicht. Und wer ohne Harness einfach drauflos generiert, also im Sinne von Vibe Coding den Code ungelesen übernimmt, bekommt schnell Software, die er selbst nicht versteht. Harness Engineering ist das Gegenmittel: Es macht Personal Software kontrollierbar.
Ein neuer Maßstab
Wer einmal eine Oberfläche nach eigenen Regeln hatte, findet die generische danach kaputt. Ohne Werbung, mit der Suche, die man selbst will, mit nur den Größen, die man trägt: Das wird zum Maßstab, an dem sich jede Anbieter-Oberfläche messen lassen muss. Nicht für alle, aber für eine wachsende Gruppe.
Nicht die Idee war neu. Neu war, dass sie eine halbe Stunde gekostet hat.
Deshalb zum Schluss die Frage an dich: Welche Oberfläche würdest du als Erstes ersetzen, wenn es dich nur eine halbe Stunde kostet?
Quellen
Appleton, M. (2024). Home-Cooked Software and Barefoot Developers. https://maggieappleton.com/home-cooked-software
Doctorow, C. (2019). Adversarial Interoperability. Interview in IEEE Spectrum. https://spectrum.ieee.org/doctorow-interoperability
eMarketer (2026). AI shopping tools gain traction, but retailer pushback could cloud 2026 progress. https://www.emarketer.com/content/ai-shopping-tools-gain-traction-retailer-pushback-could-cloud-2026-progress
Fowler, M. (2025). Vibe Coding. https://www.martinfowler.com/bliki/VibeCoding.html
Litt, G., Horowitz, J., van Hardenberg, P., & Matthews, T. (2025). Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/
Robinson, L. (2025). Personal Software. https://leerob.com/personal-software
Shirky, C. (2004). Situated Software. https://www.gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html
Shopify (o. J.). Cart permalinks. https://shopify.dev/apps/channels/cart-permalinks
Sloan, R. (2020). An app can be a home-cooked meal. https://www.robinsloan.com/notes/home-cooked-app/
Veracode (2025). 2025 GenAI Code Security Report. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
Waxman, A. (2026). Software for One. https://www.ajwaxman.com/writing/software-for-one
Häufige Fragen
Personal Software ist Software, die eine Person oder eine kleine Gruppe für sich selbst baut oder von einem Coding Agent bauen lässt, ohne sie anderen anbieten zu wollen. Sie hat kein Geschäftsmodell und keine Roadmap für Dritte, darf kurzlebig sein und stützt sich oft auf fremde Daten und Dienste. Erfolg misst sich allein daran, ob sie den eigenen Zweck erfüllt.
Den Begriff gab es schon 1979: Personal Software, Inc. war der Verlag von VisiCalc, später VisiCorp. In der heutigen Bedeutung haben ihn unter anderem Lee Robinson (2025) und Adam Waxman mit Software for One (2026) beschrieben. Vorläufer sind Robin Sloans Home-cooked App (2020), Maggie Appletons Barefoot Developers (2024) und Clay Shirkys Situated Software (2004). Nicht zu verwechseln ist er mit dem Personal Software Process von Watts Humphrey, einem Prozessmodell für einzelne Entwickler.
Zwei Spielarten lassen sich unterscheiden. Das eigene Werkzeug ist eine App für eigene Daten und Abläufe, etwa ein Baby-Tracker oder ein persönliches Projekt-Cockpit; ein Anbieter kommt darin nicht vor. Die eigene Oberfläche ist eine persönliche UX über einem fremden Angebot: Der Anbieter liefert Daten und Abwicklung, die Oberfläche bauen die Nutzer selbst.
Wenn Nutzer sich eigene Oberflächen über fremde Dienste legen können, wird das Frontend eines Anbieters austauschbar. Schlechte UX führt dann nicht mehr nur zum Absprung, sondern zum Selbstbau. Daten, Schnittstellen und Abwicklung werden zur eigentlichen Nutzerschnittstelle. UX-Teams müssen beantworten können, wofür Nutzer noch auf ihre Oberfläche kommen.
Vibe Coding ist eine Arbeitsweise: Code wird ungelesen vom Sprachmodell übernommen. Personal Software ist ein Ergebnis: Software für den eigenen Zweck. Sie kann per Vibe Coding entstehen, aber auch kontrolliert mit Harness Engineering, bei dem der Coding Agent durch Regeln, Architekturvorgaben, Tests und Prüfschritte so eingeengt wird, dass er genau das baut, was gewünscht ist.