A framework of my own in 2026
I started programming in COBOL, on a Philips machine — 6000 series, I believe; memory retires too — back when personal computers did not exist. Since then I have done almost everything this trade has to offer, except graphic design, video and CAD. I am sixty-four years old and I am about to retire.
Before I switch off the screen for the last time, I want to write down what worked for me, in case it works for someone else. That is what this blog is: no personal brand, no courses, no newsletter. Farewell notes from someone who has spent a lifetime keeping systems alive that were not allowed to fall over.
Let me open with the confession that puzzles younger colleagues the most: a dozen websites in production — sector directories, a couple of classified-ad search engines, newsletter delivery, internal management panels — and every one of them runs on a PHP framework that is not on GitHub, shows up in no survey, and nobody has heard of. I wrote it. And it is one of the best technical decisions I have ever made.
The constraint that rules everything
This is not nostalgia. It is arithmetic: I am a one-person business. The constraint that governs every technical decision I make is not elegance, and it is not performance — it is that all of this has to be maintainable by a single head, for decades. Every external dependency is a contract with a stranger who may change their mind, their license or their life. Every major version of a fashionable framework is a migration I never asked for. My framework has never demanded a migration from me: when it changes, it is because I changed it, and I know exactly why.
What it looks like inside (patterns, not blueprints)
One canonical directory holds the framework, and every application carries an
identical copy of it, plus its own application directory with everything specific.
The package manager is rsync; the lockfile is a written contract: the
framework copy is never touched — the fix always goes in the application, and if the
framework truly must change, you change the canonical copy and resync with an audit. Sounds
artisanal. It is. It also means none of my sites can break because another one needed a
different version of something.
The data layer is four functions — read, insert, update, delete — with prepared statements and the database name as a parameter. Instantiating the driver by hand inside a program is forbidden. An ORM? SQL in plain sight ages better than any abstraction that hides it: a query from ten years ago reads today exactly as it did then.
Routing is a declared array per application: URL, role allowed in, file that responds,
caching policy. "What does this URL do?" is answered with grep, not with a
step-by-step debugger crawling through fourteen layers of middleware.
The written rules
What really holds the system together is not the code: it is the rules. A file of
operating rules that says things like: no ternary operators; every if gets
braces even for a single line; every form that changes anything goes through POST with its
token; the database schema lives in SQL files and is never altered from code. They look like
an old man's manias. They are decisions taken exactly once so I never have to argue
about them again — not even with myself. Consistency is what makes a file from eight years
ago read as if I had written it yesterday.
The boring ritual
Deploying is a short liturgy, always the same: syntax-check every file, make a dated backup with a reason before overwriting anything, verify that what went up is byte-for-byte what was local, and spend a minute and a half watching the error log. Boring on purpose. The perfect deployment is the one that leaves no anecdote.
What hurts
I am not selling smoke: keeping identical copies demands liturgical resyncs; there is no typing; the automated tests never became what they should be; and some ancient warning still survives in a corner of a log. This is not a universal recipe — it is a local optimum for a one-person business that has to keep working ten years from now, whether I am the one updating it or not.
Patterns, not blueprints
A note on what I will not tell you: I write about patterns and decisions, never about the actual geography of my systems. An old programmer also knows that security begins with not giving away the map. If an example ever feels deliberately vague, that is because it is.
The final twist
And the reason this blog exists now rather than five years ago: the newest member of the team is not human. An artificial intelligence works inside this framework every day — and the same boring rules that protected me from myself turned out to be exactly what an agent needs in order not to break things. How I built that AI an operating system of its own — out of MySQL, PHP and bash — is what the next article is about.
— an old programmer · 64 years old · rss