Or, "How I Learned to Stop Worrying and Love the Journey"
There's a running joke in engineering circles that if you sit still long enough, someone will come along and replace your perfectly functional code with the latest framework named after a fruit, bird, or obscure Norse god. I've seen the same thing happen at companies and startups when old contractors or staff leave, and new ones join: "oh no, this all needs to go" - 98% of the time, the real issue is: "its not how I would've done it" (spoiler alert: it often won't be, but you weren't around for the original context, motivations, decisions, meetings, PRs, discussions, etc)
In the past 15 years, I've gone from writing Backbone.js for a UK accounting software startup to architecting real-time financial infra as a CTO. Along the way, I've been a freelancer, a startup co-founder, a team lead, an idiot and a contractor parachuted in to untangle Things That Shouldn't Be Tangled™️.
This post isn't a framework war cry or "X vs. Y in 2025" nonsense. It's just what I've learned about building things that last—even as the tools and paradigms around them change at a dizzying pace.
1. Nothing Is Sacred. Not Even the Code You Wrote Yesterday.
At KashFlow, I led a full rebuild of their accounting app's UI. We went from jQuery/ASP soup to a Backbone architecture that was clean, modular, and (at the time) "future-proof." Less than five years later, React was stealing Backbone's lunch money, and we'd all moved on.
Did that mean the rewrite was a waste*?
Not at all. I have no ego in this fight. The point wasn't to immortalise the code. It was to enable the business to move faster at the time. That's the job. Write code with one foot in today and one eye on tomorrow—but don't expect a monument.
*no, KashFlow was acquired not long after (business > tech)
2. "Full-Stack" Isn't a Badge—It's a Necessity Sometimes
When you're the only/first engineer at a startup (hi, Letter), "frontend" vs. "backend" becomes a bit of a silly distinction. One day you're designing schema for a Postgres DB, the next you're debugging AWS Lambda cold starts, and by Friday you're shipping a React Component that powers 90% of the user experience. Craig David had an easy 7 days by comparison...
I've worked on real-time WebSocket platforms (Cisco), built CLI tools to standardise frontend scaffolding (Soho House), and implemented secure tax infrastructure (WorkMade) that sends actual money to actual governments. The common thread? Problem-solving. Not titles.
Being full-stack doesn't mean you're a generalist. It simply means you're quite useful.
3. CTO at a Startup Means "Can Still Write Code, Promise"
I've been CTO at two companies now. At both, I've run hiring, managed performance reviews, sketched product roadmaps, and still ended up fixing typo bugs* in PRs.
*my own
The job isn't about sitting in strategy meetings all day. It's about being deeply technical and unblocking others. You're the router. The glue. The "yes, I know where that service lives" person.
4. The Tools Will Change. The Patterns Stay the Same.
Back in the day, I used to write Backbone. Then React. Then React Native. These days it's TypeScript everywhere, AWS under the hood, and Prisma or raw SQL on the backend. More recently; Go at Clerk. Tomorrow? Who knows. No idea. Who cares.
But you know what doesn't change?
- Protecting data integrity
- Building secure boundaries
- Designing APIs that make sense
- Thinking in flows, not files
Good engineers don't fall in love with tools. They fall in love with solving problems—and learn whatever they need to do it well.
5. Hiring? Look for People Who Ship and Own
Every time I've built or inherited a team, one trait rises above all others: ownership.
Do you ship? Do you own it when it breaks? Do you make the system better for the next person?
At Letter, my team was async, remote, and often in wildly different timezones. The engineers who thrived weren't the loudest—they were the clearest communicators and the most reliable deliverers. That's who you want in your corner.
Final Thought: Shipping Is the Job. The Rest Is Just Code.
Frameworks change. APIs evolve. The tools we use today will look quaint tomorrow. But one thing won't change:
The goal is to ship something that works, solves a problem, and doesn't fall over the second you go on holiday.
I don't write Backbone.js anymore. But I'm still solving the same problems.
And I wouldn't have it any other way.
Also: your old jQuery plugin still probably works.