I am going to say something that will upset a lot of people who have invested significant portions of their careers into container orchestration: Docker Compose is probably all you need.
Not Kubernetes. Not ECS. Not Nomad. Not whatever managed container platform your cloud provider is pushing this quarter. Docker Compose. The thing you used in tutorials before graduating to real infrastructure. That thing. It is enough.
Kubernetes is incredible technology you do not need Kubernetes can do amazing things. It can manage thousands of containers across hundreds of nodes. It can self-heal, auto-scale, handle rolling deployments, manage secrets, configure networking, and orchestrate workloads across multiple data centres. It is genuinely impressive engineering.
GraphQL is dying and I could not be happier. The hype has faded. The conference talks have dried up. The true believers have gone quiet. Teams are quietly migrating back to REST and pretending they never suggested GraphQL in the first place. The fever has broken.
Good. It was a fucking mistake.
The problem it solved did not exist GraphQL was supposed to solve over-fetching. Your REST API returns too much data, they said. You are wasting bandwidth, they said. The mobile clients only need three fields but you are sending back fifty.
Microservices were a mistake. Not the concept itself, which has legitimate uses at genuine scale. The mistake was convincing an entire generation of developers that their CRUD app needed to be split into 47 independently deployable services communicating over a message bus designed by someone who watched one too many conference talks.
I said what I said. Come at me.
Netflix ruined everything This is Netflix’s fault. Not intentionally. They shared how they solved their genuinely massive scale problems, and the rest of the industry collectively lost its mind.
I should not need to read a novel to call your endpoint.
If your API documentation spans forty pages, multiple guides, a getting started tutorial, a concepts section, a best practices section, and a troubleshooting FAQ, your API is not well documented. Your API is badly designed. The documentation is compensating for failures that should have been fixed in the API itself.
Good APIs are self-evident. You look at the endpoint, you understand what it does. You look at the request, you understand what to send. You look at the response, you understand what you got back. The documentation exists to confirm what you already intuited, not to explain an incomprehensible system.
I have spent more time than I care to admit writing technical documentation for Aurelia 2. The docs at docs.aurelia.io have been through countless revisions, rewrites, restructures, and moments where I stared at the screen wondering if I had forgotten how to form sentences.
Writing code is hard. Writing about code in a way that helps other people write code is harder. Nobody prepares you for this.
The first thing you learn is that you do not actually understand the thing you are documenting. You think you do. You have used it, you have built things with it, you can explain it to a colleague at your desk.
You are a startup. You have twelve users, three of whom are your mum, your co-founder, and your co-founder’s mum. You have six months of runway. You have not found product-market fit. You are still pivoting weekly based on whatever feedback you got from the last person who agreed to a demo.
And you want to build a mobile app.
No. Stop. Put the Xcode down and step away from the keyboard.
I am a front-end developer. That is my main thing. JavaScript, TypeScript, component frameworks, state management, the DOM and all its quirks. I have spent years in this world and it is where I am most comfortable. If you need someone to build a reactive UI or argue about whether signals are better than virtual DOM diffing, I am your guy.
I am also a PHP developer. Have been for a long time. Back-end work, WordPress, Laravel, the lot. That is another core part of my toolkit that has served me well for years.
It is not a secret anymore. Most developers use AI tools now. If you are not using something like GitHub Copilot, Claude Code, OpenAI Codex, or even just pasting problems into ChatGPT, you are probably in the minority. The stigma has evaporated. Nobody is pretending they wrote every line by hand anymore.
Using AI to write code is just what we do now, like using Stack Overflow was ten years ago except the answers are usually better and you do not have to scroll past three people arguing about whether the question is a duplicate.
I have had more ideas than I can count. A notes folder full of app concepts, half-baked prototypes in forgotten repos, domain names I bought in a fit of optimism at 2am. Over a decade of this. Life gets in the way. Work gets in the way. Kids, mortgages, health, relationships, fatigue. The ideas pile up and the backlog grows.
If you look at my GitHub, you might think I ship a lot. Nearly 200 repositories. Aurelia plugins, blockchain games, CLI tools, a regex battle game, apps for finance tracking and tattoo previews and bedtime stories. From the outside it probably looks prolific. But I know what is missing. The projects that never left my head. The code that never got written. The things I talked about for years and never touched.
I have never been a TDD purist. The whole write-tests-first-no-exceptions religion always felt a bit much. Sometimes you are exploring. Sometimes you do not know what the code should do until you have written it. Sometimes you just need to ship the thing and circle back to tests later. I get it. I have lived it.
But AI assisted coding has changed my relationship with TDD. Not because I suddenly found religion, but because tests solve a very specific problem that AI introduces: you cannot trust the output.