Ich kann nicht programmieren. Trotzdem läuft es jetzt. I can't code. It's running anyway.
Vor ein paar Monaten hätte ich auf die Frage, ob ich programmieren kann, mit Nein geantwortet. Das würde ich heute immer noch tun. Trotzdem läuft seit ein paar Wochen eine App im Internet, die ich gebaut habe — auf einem Server, den ich selbst eingerichtet habe.
Diese Ausgabe ist das Protokoll dazu. Womit ich angefangen habe, was ich unterwegs entschieden habe, und an welchen drei Stellen es unangenehm wurde.
Angefangen habe ich mit meinen Kindern
Nicht mit einem Plan, sondern mit einem Nachmittag. Wir haben uns ein einfaches Spiel ausgedacht — nichts Großes, ein paar Regeln, eine Idee, die sie lustig fanden. Ich habe beschrieben, was es können soll, ChatGPT Codex von OpenAI hat den Code geschrieben, wir haben zusammen ausprobiert, korrigiert, wieder ausprobiert.
Nach wenigen Stunden lief es. Meine Kinder haben es gespielt.
Der eigentliche Effekt war nicht das Spiel. Es war, wie kurz die Strecke zwischen „Idee" und „läuft" geworden ist. Diese Strecke war früher der Grund, warum ich solche Sachen nie angefangen habe.
Dann habe ich es in meine Arbeit gezogen
Der nächste Schritt kam nicht privat, sondern beruflich — im Anforderungsmanagement. Anforderungen leben dort normalerweise in PowerPoint und Jira: beschrieben, nummeriert, priorisiert, abgehakt. Sauber dokumentiert. Nur erlebt hat sie in dem Moment niemand.
Also habe ich angefangen, sie stattdessen zu bauen. Kein fertiges System, sondern ein klickbarer Prototyp, in dem man den gedachten Ablauf einmal durchspielen kann — in Stunden statt in einem Sprint.
Der Unterschied in einer Abstimmung ist größer, als es klingt. Über eine Folie oder ein Ticket diskutiert jeder seine eigene Vorstellung davon. Über etwas Klickbares diskutieren alle dasselbe. Missverständnisse fallen in der ersten Runde auf, nicht drei Wochen später in der Umsetzung.
Und jetzt: das erste Projekt für andere
In den letzten Wochen habe ich wieder mehr Zeit für eigene Projekte. Dafür bin ich von Codex zu Claude Code gewechselt und habe bewusst das größere Abo genommen — nicht aus Prinzip, sondern weil mich Kontingentgrenzen mitten in der Arbeit rausreißen. Wenn ich zwei Stunden am Stück konzentriert bin, will ich nicht in Minute 90 aufhören müssen.
Damit habe ich etwas gebaut, das nicht nur für mich ist. Und genau da fingen die eigentlichen Probleme an.
Hürde 1: Es muss ohne mich verständlich sein
Alles, was ich vorher gebaut hatte, war für mich. Da braucht es keine Erklärung — ich kenne jede Entscheidung, jeden Knopf, jede Abkürzung, weil ich sie selbst getroffen habe.
Die Familien-App war die erste Anwendung für Menschen, die meine Gedanken nicht lesen können. Und das ist ein anderer Anspruch: Jeder Bildschirm muss sich von selbst erklären. Kein „ich zeige dir kurz, wie es geht".
Das hat mich einige Schleifen gekostet. Nicht technische — gestalterische. Die Technik stand schnell. Die Frage „versteht das jemand, der es zum ersten Mal sieht" habe ich mehrfach falsch beantwortet, bis sie saß.
Hürde 2: Hosting und Deployment — wo läuft die Anwendung?
Zwei realistische Wege: ein Raspberry Pi bei mir zu Hause, oder ein gemieteter Server.
Ich habe mich für den Server entschieden. Nicht wegen der Leistung, sondern wegen des Aufwands drumherum: kein Basteln mit Router und Anschluss, keine Abhängigkeit davon, dass zu Hause der Strom läuft, erreichbar auch dann, wenn ich gerade tausende Kilometer entfernt bin.
Gelandet bin ich bei netcup. Was mich überrascht hat, war der Preis: Ein kleiner virtueller Server kostet dort wenige Euro im Monat und reicht für ein Projekt mit einer überschaubaren Zahl an Nutzern völlig aus. Die Hürde, über die ich jahrelang nicht nachgedacht habe, kostet ungefähr so viel wie zwei Kaffee.
Hürde 3: Sicherheit — der Teil, bei dem ich Bauchschmerzen hatte
Sobald etwas öffentlich erreichbar ist, ist es angreifbar. Das gilt für ein kleines privates Projekt genauso wie für eine große Seite — nur dass hinter der großen Seite ein Team sitzt und hinter meiner ich.
Dazu kommt etwas, das ich neulich auf LinkedIn schon angedeutet habe: Dieselbe Entwicklung, die mir das Bauen leichter macht, macht auch das Angreifen leichter. Kleine, nicht professionell gehärtete Projekte automatisiert abzuklopfen ist heute billig.
Ich habe das nicht weggeschoben, sondern zu einem eigenen Arbeitspaket gemacht. Viele Runden Fragen und Antworten: Was ist an meinem Aufbau angreifbar? Was ist Standard, den ich noch nicht habe? Was übersehe ich, weil ich nicht weiß, dass es das gibt? Genau für diese letzte Frage ist ein Werkzeug, das man ausfragen kann, unbezahlbar — ich kann nicht suchen, was ich nicht kenne.
Ehrlich gesagt: Ich bin kein Sicherheitsexperte, und ich behaupte nicht, dass mein Aufbau perfekt ist. Aber „darüber habe ich nicht nachgedacht" wäre die schlechteste aller möglichen Antworten gewesen.
Was ich daraus mitnehme
Das Bauen ist nicht mehr die Hürde. Das war die Überraschung.
Die Hürden liegen heute woanders: Ist es ohne mich verständlich? Ist es zuverlässig erreichbar? Ist es sicher genug für das, was drin steckt? Das sind keine Programmierfragen. Das sind Fragen, die jeder beantworten kann, der schon mal ein Vorhaben zu Ende gebracht hat.
Wenn du also überlegst, ob du selbst etwas bauen willst: Fang mit etwas Kleinem an, das nur für dich ist. Der Sprung von „läuft bei mir" zu „läuft für andere" ist der lehrreiche — und den machst du erst, wenn das Kleine steht.
Beim nächsten Mal
Die Familien-App im Detail: was sie kann, wie die Fotos funktionieren, welche Entscheidungen ich unterwegs revidiert habe.
Eine ausführlichere Liste der Werkzeuge, die ich benutze — mit dem, was sie jeweils wirklich leisten — findest du im Lexikon. Dort ist Platz für Details, die eine Mail sprengen würden.
Und wenn du an einer der drei Hürden gerade selbst hängst: Antworte einfach auf die Newsletter-Mail. Ich lese wirklich mit.
Bis in zwei Wochen,
Fabian
A few months ago, asked whether I can code, I would have said no. I'd still say the same today. And yet, for a few weeks now, there's been an app of mine running on the internet — on a server I set up myself.
This issue is the log of how that happened. What I started with, what I decided along the way, and the three points where it got uncomfortable.
It started with my kids
Not with a plan, but with an afternoon. We came up with a simple game — nothing big, a few rules, an idea they found funny. I described what it should do, OpenAI's ChatGPT Codex wrote the code, and together we tried it, fixed it, tried again.
After a few hours it was running. My kids played it.
The real effect wasn't the game. It was how short the distance between "idea" and "running" has become. That distance used to be the reason I never started things like this.
Then I pulled it into my work
The next step wasn't private but professional — in requirements management. Requirements normally live in PowerPoint and Jira there: described, numbered, prioritised, ticked off. Neatly documented. Except nobody has actually experienced them at that point.
So I started building them instead. Not a finished system, but a clickable prototype that lets you play through the intended flow once — in hours instead of a sprint.
The difference in a review meeting is bigger than it sounds. Given a slide or a ticket, everyone discusses their own mental picture of it. Given something clickable, everyone discusses the same thing. Misunderstandings surface in the first round, not three weeks later during implementation.
And now: the first project for other people
In recent weeks I've had more time for my own projects again. For that I switched from Codex to Claude Code and deliberately took the larger plan — not on principle, but because usage limits tear me out mid-flow. If I'm focused for two hours straight, I don't want to stop at minute 90.
With that I built something that isn't just for me. And that's exactly where the real problems started.
Hurdle 1: it has to make sense without me
Everything I'd built before was for me. That needs no explanation — I know every decision, every button, every shortcut, because I made them myself.
The family app was the first application for people who can't read my mind. And that's a different standard: every screen has to explain itself. No "let me quickly show you how it works".
That cost me several rounds. Not technical ones — design ones. The technology came together quickly. The question "will someone seeing this for the first time understand it" I answered wrong several times before it landed.
Hurdle 2: hosting and deployment — where does the application run?
Two realistic options: a Raspberry Pi at home, or a rented server.
I went with the server. Not for the performance, but for everything around it: no tinkering with routers and connections, no dependency on the power staying on at home, reachable even when I'm thousands of kilometres away.
I ended up at netcup. What surprised me was the price: a small virtual server costs a few euros a month there and is entirely sufficient for a project with a manageable number of users. The hurdle I hadn't thought about for years costs roughly as much as two coffees.
Hurdle 3: security — the part that gave me a knot in my stomach
The moment something is publicly reachable, it's attackable. That's true for a small private project just as much as for a large site — except the large site has a team behind it, and mine has me.
On top of that, something I hinted at on LinkedIn recently: the same development that makes building easier for me also makes attacking easier. Probing small, not professionally hardened projects in an automated way is cheap today.
I didn't push that aside; I made it its own work package. Many rounds of questions and answers: what about my setup is attackable? What's standard practice that I don't have yet? What am I missing because I don't know it exists? For that last question especially, a tool you can interrogate is priceless — I can't search for what I don't know about.
Honestly: I'm no security expert, and I'm not claiming my setup is perfect. But "I didn't think about it" would have been the worst of all possible answers.
What I take away from this
Building is no longer the hurdle. That was the surprise.
The hurdles are elsewhere today: is it understandable without me? Is it reliably reachable? Is it secure enough for what's inside it? Those aren't programming questions. Those are questions anyone can answer who has ever seen a project through to the end.
So if you're wondering whether to build something yourself: start with something small that's only for you. The leap from "runs for me" to "runs for others" is the instructive one — and you only make it once the small thing stands.
Next time
The family app in detail: what it does, how the photos work, which decisions I reversed along the way.
A more detailed list of the tools I use — with what each of them actually delivers — is in the Tools section. There's room there for details that would burst an email.
And if you're stuck on one of the three hurdles yourself: just reply to the newsletter email. I really do read them.
See you in two weeks,
Fabian
Keine Ausgabe verpassen.
Never miss an issue.
Mit der Anmeldung stimmst du der Datenschutzerklärung zu. Double-Opt-in; Abmeldung jederzeit möglich.
By subscribing you agree to the privacy policy. Double opt-in; unsubscribe anytime.