Twenty years of shipping taught me one thing

I started shipping web software professionally around 2005, right after university. Two decades later, if I had to compress everything I’ve learned into one sentence, it would be this:

The craft that survives is smaller and quieter than any hype cycle wants to admit.

Here’s what that means, from inside.

The cycles I’ve lived through

XML everything. SOAP. REST. AJAX. Web 2.0. “Mobile first.” HTML5. Flash is dead. No, Flash is back. Responsive design. SPAs. Single page apps are bad; server-rendered is back. NoSQL will kill SQL. SQL is back. Microservices. Microservices are a mistake. Kubernetes solves everything. Kubernetes is overkill for everything. React Native will replace native. Native is back. Blockchain will eat finance. Blockchain is... mostly quiet now. The metaverse. AI.

Every single one of those cycles had people telling me in meeting rooms that if I didn’t adopt it immediately, my career was over. I adopted some of them — the ones that actually shipped software better. I skipped others. My career did not, in fact, end.

What actually survived, every time

Under every cycle, the same small set of things kept mattering. These are what I check for now, on any project, in any stack:

• Did the thing ship? Not demo. Ship, to real users, in a state they can actually use.
• Is the feedback loop short? Hours or days, not weeks. The loop length decides how fast you learn.
• Can one person hold the system in their head? If not, the architecture is probably wrong for the team size.
• Do the owners actually use it? If the client is not testing their own product in production, nothing else you measure matters.
• Is the boring bit done? Backups. Logging. Error reporting. Uptime. If you don’t have these, the product isn’t a product, it’s a prototype with ambitions.

None of that is exciting. None of it is on a conference slide. All of it is what separates a fifth year of revenue from a fifth PowerPoint.

The thing I didn’t expect

I spent a lot of my early career assuming the senior engineers around me — the people in their forties I was trying to become — had some secret knowledge I was missing. Twenty years later, I am one of them, and I can tell you there’s no secret.

What they had was more reps at the same small set of fundamentals . They had written more migration scripts. They had debugged more race conditions. They had rolled back more deploys at 2 a.m. The knowledge was not a secret. It was just time.

Which is also the thing AI changes, but doesn’t change. AI can compress a lot of the repetitive parts of that time. It cannot compress the judgement that comes out of it. Someone who has debugged twenty different production incidents over twenty years recognises the shape of the twenty-first, faster, even with AI at the keyboard. Someone who hasn’t, doesn’t, even with the best tools.

What Cybind is, in this frame

Cybind is the second half of my career. The bet is that the fundamentals I picked up in the first half — shipping, short loops, caring about boring things — still matter, and that modern AI is a massive multiplier on top of them rather than a substitute for them.

So far, every month of running Cybind has made me more sure of this, not less. The hype cycle will keep cycling. The craft will keep being quiet. I’ll keep shipping.