Ten months ago, one of my senior backend engineers, Vitaliy, left three comments on a piece of AI-generated code I'd pushed into one of our repos. He called the file awful. Said the logic was in the wrong place. Said a switch case belonged in a constants file. He wasn't joking. He was a senior engineer doing his job, and he genuinely thought the code was bad.

This week, the same Vitaliy sent me an unprompted 8-page proposal to build our first agentic AI coding system at We UC. And in his Slack message, he wrote the line that's stuck with me since: "those MRs you used to send me that gave me plenty to comment on." Winking emoji at the end.

He named the moment he was mocking. He updated his view when the evidence changed. He was the loudest sceptic on my team. Now he's the one leading the build.

What flipped in those ten months is the answer to a question I keep getting asked: why are some engineers leaning hard into AI coding while others are getting actively angry about it? This post is about what the real fight is, why it isn't about the code, and the two paths I see open from here.

A Scale, Not a Divide

AI coding usually gets framed as two camps. Hand coders versus AI-native coders. Real engineers versus vibe coders. Old school versus new school.

That framing is wrong. It's a scale, not a divide.

At one end you've got fully AI-native engineers. They write PRDs and specs in plain English and let AI handle the implementation, the review, the tests. Their craft has moved from typing to specifying, architecting and managing agents.

At the other end, the 100% hand coders. Every line typed. Every character earned. Their craft is in their fingers, along with the discipline and pride they built over a career. To them, AI-written code isn't real work.

Most of the industry sits somewhere in between. The question isn't which camp you're in. It's which way you're leaning, and how fast.

The data backs the direction. Google, at Cloud Next this year, said 75% of their new code is AI-generated. Microsoft puts the number at 20 to 30%. Anthropic's Claude Code team is at pretty much 100%. "AI-generated" means different things at different companies, but the trend is unambiguous: every major engineering organisation is moving down the scale, fast.

The developer side is more interesting. The Stack Overflow 2025 survey showed 84% of engineers use AI tools or plan to. But trust dropped 11 points year on year, to 29%. The gap between use and trust is exactly where the anger lives.

What the Anger Is Really About

When you've spent 10 or 15 years typing code, you've built a self-image around the act of typing. Your reflexes, your shortcuts, the way you think while you write. All of it tuned to the keyboard.

If I walk in and say "stop typing code, write a spec instead", I'm not asking you to learn a new tool. I'm asking you to change who you are. That's hard for anyone.

MIT Technology Review published a piece at the end of last year with a line from an engineer called Luciano Nooijen that landed harder than any data point I've seen. He'd been leaning on AI tools heavily at work, tried to build a side project without them, and realised he'd lost something: "I was feeling so stupid because things that used to be instinct became manual, sometimes even cumbersome."

Feeling stupid. That's what this transition does to the muscle memory, and to the self-image built on it.

The technical term for what happens next is cognitive dissonance. Your identity says one thing. The world says another. You can update your self-image, which is painful and slow and requires humility. Or you can reject the evidence, which is easier and gives immediate relief, at the cost of being isolated over time. Most people pick the second one first.

The cleanest example I've seen came in a comment on one of my own videos: "He is completely mistaken. Specification-driven development is not the future, but I won't explain why." That last bit is the tell. There's no argument underneath. There's just discomfort.

And it goes deeper than psychology. Your nervous system, biologically, can't tell the difference between transformation and threat. When something familiar starts ending, your body reacts the way it would to physical danger.

The anger isn't malice. It's grief, dressed up as opinion.

Who Makes the Turn

After three years of watching this inside my own team, three things predict who makes the turn.

One, the tools have got dramatically better in a short space of time. Engineers who tested AI coding in early 2024 and concluded it wasn't ready were not wrong then. The code often was bad. But if you haven't re-tested in the last three months, your opinion is out of date.

Two, identity. The engineers who adapted earliest on my team weren't the youngest or the smartest. They were the ones whose self-image was less tied to the typing. The ones who already saw themselves as problem solvers first, code writers second.

Three, humility. The technical version, not the soft version. The willingness to be a beginner again at something hard. Most senior engineers got senior by being the smartest person in the room. AI coding makes them wrong, on repeat, until they're not. Getting better feels like getting worse, at first. The ones who could sit with that made the turn. The ones who couldn't, didn't.

The Pattern That Keeps Repeating

None of this is new. Every digital transformation in living memory has followed the same shape.

I watched it up close once before. My father ran a photography business. His craft was developing the film, working with the chemicals, exposing prints in the darkroom. Digital came. He stuck with what he knew for a while because he was good at the old craft. But his competitors switched. They got faster. They started winning more work. So one day he made the call. Renewed his lab, bought a minilab, and within a month he was fully converted. The decision took him years. The execution took weeks.

Today most professional photography is digital. Film still exists, in a respected niche. Same with music. Vinyl passed a billion dollars in US revenue last year for the first time since 1983. Real niche, real money, not how the mainstream listens.

The old craft doesn't die. It becomes a respected niche. Mainstream production moves on.

The legends of hand coding agree. John Carmack, who founded id Software and shipped Quake and Doom, posted earlier this year: "Coding was never the source of value, and people shouldn't get overly attached to it. Problem solving is the core skill."

And DHH, the creator of Ruby on Rails and a vocal AI sceptic for years, summer last year: "I can literally feel competence draining out of my fingers." Six months later, January this year: "Any time I have to type precise syntax by hand now feels like such a tedious chore. Programming is still fun, probably more fun."

From "competence draining" to "tedious chore" in six months. The same pattern I watched with Vitaliy, just on a bigger stage.

Two Honourable Paths

Here's where I think we're heading, with the usual caveat that these are estimates, not guarantees.

Within a year, I think 90% of new production code will be written by AI, with humans writing specs, reviewing plans and approving the work. Within three years, hand coding will be considered a niche craft. Beloved. Respected. Real. But not how mainstream production happens.

I could be wrong on the timeline. Anthropic's CEO Dario said in March last year that we'd hit 90% AI-written code across the industry in three to six months, and the latest estimates put us at around 42%. Predictions miss. The direction doesn't.

So I see two paths forward.

Path one. Adapt. Learn to write specs in plain English. Get comfortable letting AI write the implementation while you architect, review and manage. Find the new craft inside the new workflow. This is where mainstream production work is heading.

Path two. Choose the niche. If your love is the keyboard, the typing, the craft of writing every line yourself, that is valid. There's a place for you. Just understand that the place is getting smaller, and your value proposition has to get sharper. Film photography is a respected niche. Vinyl is a respected niche. So can hand coding be.

Both paths are honourable. What doesn't work is the third path. Denial. Insisting the change isn't happening, attacking the people reporting it, pretending the world will rewind. That position has never won in any technology transition.

Pick Your Path

Vitaliy chose path one. Ten months ago he was the loudest sceptic on the team. This week he's the one leading the build. He had the humility to update his view when the evidence shifted, and he's a better engineer for it.

If you're a CEO or operator looking at your own dev team and seeing the same split, don't try to win the argument by force. Outlast it. Keep showing the work. Let the people they respect online start changing their tune too. The wall cracks slower than you'd like, but it cracks.

And if you're an engineer reading this and you feel the anger rising, be honest with yourself about which path you actually want. Either of them is real. Neither requires denial.

Pick your path. Just don't stand in the middle, defensive and angry at the people who picked.

Watch the video:

If running a business through the AI transition is on your plate, I also wrote The CEO Operating System, the framework I use to run multiple companies without burning out. It's free. axelmolist.com/ceo-os

Got thoughts, pushback, or a story of your own on this? Hit reply. I read every email.

Thanks,
Axel.

I've spent four years and £1.5 million building a SaaS, and almost nobody knows it exists.

That sentence took me longer to admit than it should have.

I'm Axel. I founded circle.cloud in 2015, a UK telecoms company that grew to over 100 people without outside investment. I now run We UC as CEO, the unified communications SaaS we've spent four years building. I've shipped software before. I've sold software before. I just hadn't, until now, sold software the way software actually needs to be sold in 2026.

Here's what I got wrong, and the plan I'm running to fix it.

How I Learned Distribution

I built circle.cloud one phone call at a time.

In 2015 I was working out of a spare bedroom with a desk phone, a laptop, and a CRM full of cold leads. Two hundred calls a day. I'd ring through the list until someone agreed to a meeting. Drive out. In-person demo. Close. Install. Repeat.

Over the next few years I hired people to run the same process at scale. By the time we started building We UC in 2021, we had around 25 people on the phones, nine field salespeople sitting demos every day, and nine engineers installing phone systems on site. A conveyor belt with humans at every stage.

That model works. It still works for us today. circle.cloud is heading toward 100 installs a month right now using the same playbook.

It works because the unit economics support it. The average telecoms deal is big enough to pay for the cold call, the travel, the demo, the install, the engineer, the account manager. The customer wants someone holding their hand. They want a face in the room. They want an engineer on site in their comms cupboard.

High-touch distribution isn't outdated. It's the right tool for the right unit economics.

Why That Engine Doesn't Transfer

We UC is a different animal.

It's a SaaS. The plan is to sell it to founders, operators, IT directors, COOs, CTOs - the kind of tech-savvy operator who scrolls through the internet at two in the morning, finds a product that looks well made, signs up there and then, and onboards their team without ever talking to a salesperson.

A SaaS product priced like a meal out can't pay for a cold call. It can't pay for travel. It can't pay for an engineer on site. The maths just don't work.

So it needs a completely different motion. Different process, different team, different metrics, different content, different acquisition channels.

I Did It Backwards

The traditional advice for a new founder is to validate the market first. Build a landing page. Run some ads. Pull together a small audience. Sign up a waitlist. Then, if the interest is real, build the product.

I did it the other way around. Four years and £1.5M of investment into the build before I had a landing page worth driving traffic to. No waitlist. No email list. No audience.

I'm not proud of that. But I want to be honest about it, because there's a specific reason it happened.

I knew how to build software. I had a 20-person dev team and a decade of muscle memory running a business that ships things. Building was the part I knew how to do, so I kept doing it. Marketing, especially the modern AI-augmented kind, was new. New is uncomfortable. The natural pull is to retreat into the thing you already know.

That's the trap. Building feels like progress. Building is comfortable. And when you're a founder who's good at building, the work that actually changes the trajectory of the business gets postponed.

What broke me out of it was sitting back and asking why the engine that built circle.cloud doesn't fit a SaaS. Once that became clear, the work I'd been avoiding became unavoidable.

The Modern Way to Go to Market

Five years ago, if you'd asked me how to launch a software product, I'd have said hire telemarketers if the unit economics allow it, and run a heavy SEO play if they don't. That was the orthodoxy.

It isn't anymore.

The people I look at now run a different motion entirely. Jordan Crawford and his Blueprint GTM team are the cleanest example. Audience-first. Content-led. AI-augmented. They aren't optimising for cold outreach. They're building media properties around the product, and the product gets shipped into the audience that's already paying attention.

Another company that puts this into focus for me is Kinzo (kinzo.ai). Two founders with a big exit behind them, now building an AI inbox assistant. Roughly 60% of their team is content and marketing. The other 40% is engineering and go-to-market. That ratio used to be the inverse for any sane software company. It isn't anymore.

At We UC today, the split is roughly 99% product and 1% marketing. That has to change.

The Plan, In Layers

Here's how I'm thinking about it. Four layers, with the first one as the foundation everything else sits on.

Layer One: Personal Brand.
The thing you're reading right now. I started writing in public and showing up on YouTube and LinkedIn in November 2024. I'm six months in. Growth is slow. Engagement is slow. Some days it feels like nobody's listening.

I'm doing it anyway because people buy from people. If a founder or operator finds me through this content and trusts how I think, the product gets to skip the hardest part of a cold sale: building trust from zero. The personal brand isn't the marketing. It's the foundation underneath the marketing.

Layer Two: Product and Company Content.
Once the SaaS is publicly live, we run a content engine for the product itself. Blog posts at volume. LinkedIn, YouTube, Instagram. Product demos. Carousels and visual artefacts created with AI tools like Claude Design. A mountain of content, AI-assisted but with a high quality bar set by humans.

The plan is funnel-shaped. Top-of-funnel content is informational, educational, broad. Mid-funnel content is product-led: what the product does, why we built it the way we did, what changes for the buyer. Bottom-of-funnel content is the call to action: start a trial, join the waitlist, talk to us.

Layer Three: Paid Media.
Take the best-performing organic content and sponsor it. Run paid social experiments. Use Google for the high-intent searches. Paid is amplification, not replacement. We only put money behind content that's already proving itself organically.

Layer Four: PR.
A structured PR push around launch. Embargoed press releases sent to around 150 publications, trade press, business press, telecoms press. We'll either engage a PR agency or run it ourselves to keep costs down. The press releases go out under embargo so the coverage all lands on launch day. A second wave later in the year, with a circle.cloud customer who's selected We UC as their communications platform.

Personal brand first. Product content second. Paid amplification third. PR around the launch moments.

The Edge I Already Have

There is one thing I have that most SaaS founders don't.

circle.cloud has around 2,500 customers on the existing phone system, supporting over 10,000 users. We're now migrating them onto We UC. So far we've moved three customers across, and about 150 users are now live on the new platform. Each migration gives us real feedback from real businesses paying real money.

Most SaaS launches don't have that. They go live with hope and a waitlist. We go live with a product that's already been battle-tested by paying UK businesses.

That's the edge on the product side. The SaaS will be hardened before it's publicly available.

What I don't have is an audience for the SaaS itself. That, I'm building from zero.

The Rebrand

There's one detail I haven't mentioned. We UC isn't the name we'll launch the SaaS under.

"UC" stands for unified communications. Inside the telecoms industry, that's table-stakes vocabulary. Outside it, nobody knows what it means. Buyers guess "universal communications" or assume it's part of the company name. Every first impression starts with a small piece of confusion. The label also undersells the product, because what we're building is a modern, AI-augmented, keyboard-first communications platform, not a category-standard UC tool.

So the parent company stays as We UC Ltd. The product gets a new name, marketed direct to operators.

The criteria are tight. Six letters or fewer. Communications at its root, ideally implying voice or conversation without saying it literally. International, not English-bound. Friendly to the ear, no hard Xs. Available, meaning trademark-clearable and domain-buyable. And distinctive enough that we don't sound like the rest of the category.

Every name we've liked has been trademarked. Every name that clears the legal check doesn't quite sound right. It's harder than I expected. We'll land on it, and the moment we do I'll show the rebrand and the new website here.

If you've got an idea, I'm taking suggestions. Drop them in the comments under the video.

The Mindset Shift

Underneath all of this is a transition I'm still working through.

For ten years I've been the founder of a services business. The mental model for growth is staffing the conveyor belt: more callers, more field reps, more engineers, more installs. Capacity scales linearly with headcount. Revenue scales with capacity. You optimise the funnel.

A product business doesn't grow that way. You don't scale a SaaS by hiring more salespeople, because the unit economics don't carry the cost. You scale it by building an audience, shipping the product into that audience, and compounding both at the same time.

That's an entirely different game. New muscles. New ratios. New ways of measuring whether the week was a good one.

I'm excited about it, even though I'm new at it. I've always found my way through a thing once I've decided to obsess over it. This is the latest obsession.

If you're building a SaaS in 2026, this is the order I'd run it in. Audience first, then product, then paid amplification of what works. Money doesn't get you organic growth. The list compounds slowly. You can't buy it.

It's the work I'm doing now, in public.

Watch the video:

If running a software business in the AI era is on your plate, I wrote The CEO's Operating System, the free framework I use to run circle.cloud and build We UC. axelmolist.com/ceo-os

If you're a CEO or CTO with engineers who learned to code before AI, and you can feel that AI coding should be transforming your business but it isn't, this is for you.

The tools aren't the problem. The problem is the people. Specifically, the engineers who built their craft before AI was useful. The ones your business actually runs on.

I've been a fanatic of AI coding since the month ChatGPT shipped. For most of the three years since, my dev team at We UC pushed back. Hard. They called the code bad. They mocked everything I built with AI. I've still got the Slack messages.

Then six months ago, the wall started to crack.

The December 2022 MySQL Moment

Let me take you back to the moment I knew everything was about to change.

December 2022. I'm at my laptop trying to build a dashboard to display phone system data. I'm not a developer. Never have been. But the data lived inside a MySQL database, and to get it into our BI dashboard I had to write a fair amount of SQL. Selects, joins, all of that.

I'd spent months grinding through Stack Overflow. Asked friends who knew MySQL. Always hit a wall.

Then ChatGPT came out. I described the query I wanted in plain English. It wrote the query. It worked. First try. Then I asked it for a script. The script worked too.

Within six months, I'd built a working prototype of a full app I'd been wanting for years. I sat there, blown away. And I remember thinking, this is the new way of writing code. The world is never going to be the same again.

So in early 2023, I went to my dev team and said, you need to start using this. This is the future. Get on it.

Three Years of No

Every single one of them pushed back.

The objections came in waves. You can't trust it. It hallucinates. It writes ugly code. It writes bad code, because it's been trained on the worst code on the internet. It can't fit our app in its context window. It will suggest packages that are out of date because of the training cutoff window, so it will write code with known vulnerabilities.

Every time I built something with AI, an internal tool, a script, anything, the team picked it apart. "Why is this file so long? Why did it pass these arguments? This is way more complicated than it needs to be. Look how I can simplify this function."

That last line, I heard a hundred times. "Look how I can simplify this function."

And underneath it, the unspoken word was always the same. AI coding doesn't work, Axel. Stop dreaming.

It took me two years to realise the resistance wasn't really about the code. It was about identity.

If you've spent years building muscle memory for what good code looks like, and someone walks in saying "let the machine write it," you don't hear "use a new tool." You hear "your craft no longer matters." That's the real reason. Not hallucinations. Identity.

I kept pushing. They kept pushing back. For three years.

The First Crack

Six months ago, things started to shift. I noticed it first in the small things.

We needed a marketing automation script. One of our mid-level developers, the same person who'd been mocking my AI scripts twelve months earlier, opened Claude Code, wrote a thorough prompt, and the script came out clean. Worked first try. He didn't tell me he'd used AI. I had to ask.

Around the same time, one of our senior backend developers, the one who'd called AI coding unreliable for the previous two years, started insisting on detailed technical specs for every new feature. Working with our PM on the PRD first, then writing the spec sheet himself. As if that's just how you do it now.

Why? Because once we have a good spec, AI can handle far more of the implementation than before. We move reliably faster.

I asked him why we couldn't just let AI write all of We UC. And he said something that stuck with me.

"We UC has been built over four years by different people, without a clearly defined coding standard from day one. So whenever AI looks at our code, it sees five different opinions about the right way to do things. Of course it gets confused."

That was honest. And he was right.

AI Coding Exposes, It Doesn't Fix

Here's the reframe that took me three years to see. AI coding doesn't fix bad engineering practices. It exposes them. And then it forces you to fix them properly.

The problem wasn't AI. We had never written down what good code should look like inside our company. So now we have. We're building a comprehensive coding standards document. We're refactoring our backend services into a monorepo so everything lives in one place: code, docs, tests. Where any developer, or any AI, can navigate it.

We had also been under-documenting our architecture decisions for years. The why behind choices, not just the what. So when we feed our codebase into AI now, we have something to feed in beyond the raw code. Without documented decisions, the AI was filling in the gaps with its own guesses. That's where the problems were starting.

We've improved our security stack too. Docker hardened images for the attack surface. Context7 MCP inside Claude Code so the AI uses the latest version of every package, not whatever was current at its training cutoff. Aikido running for the last month, scanning containers and deployments for vulnerabilities.

But none of this is really about AI. It's about wanting to write good code as an organisation. Bad packages get shipped by humans too. Insecure code gets written by humans too. The question isn't "is AI safe?" The question is, are we set up to produce good code, regardless of who or what wrote it?

We've started treating AI like another developer on the team. I think that's the right approach.

Permission from Skeptics

Why did my team finally come round? Honestly, three things hit at once.

I'd been hammering the same drum for three years. They were tired of hearing it from me.

Claude Code itself got dramatically better. The models stepped up significantly over the last twelve months.

And the third one, which surprised me. The developers my team follows online started talking about the tools seriously. Not as evangelists. As skeptics. ThePrimeagen, the YouTuber my team trusts most, is still cautious about AI coding. But cautious is different from dismissive. When the practitioners my team respects moved from "this is hype" to "this is a real tool with real trade-offs," that gave my team permission to do the same.

They didn't get converted by hype. They got permission from skeptics.

Sometimes you don't win the argument. You outlast it. And you let other people make it for you.

Two Generations of Developer

The process of converting my team has made me think about something much bigger.

There's a fork in the road in software development right now. Two generations of developer. One shaped before AI existed. One being shaped now. The gap between them is going to define the next decade.

On one side: developers who learned to code before AI was useful. That's my team and probably yours. They learned the syntax. They learned languages by typing them out, character by character. Their craft is in their fingers.

I call them hand coder software engineers. Or hand coders, for short.

On the other side: developers learning to build software now, with AI in the editor from day one. They won't memorise JavaScript or Python or Rust syntax, because they don't need to. AI handles that. What they will learn is the concepts. The architecture. Computer science principles. How memory gets allocated. How a system scales.

I call them AI native software engineers. They become managers of agents. They define the system, write the spec, set a fleet of agents loose, review the output. They're responsible for what the agents produce. But they don't write the code by hand. They don't need to.

I think I'm an early version of how this works. I never learned to code in the syntax sense. I learned to build software with AI from the start. I architect the system, write the spec, pass it to Claude Code, then test the output.

That's how I built The Scheduler. It started as an internal tool at one of my other companies. Now it's a fully working product, in production, used by real customers. Not a demo. I didn't write a single line by hand. I built it the way I think an AI native software engineer is going to be building everything.

I've done it twice. Before The Scheduler I built a search tool that pulled customer data from across our CRM, our phone system, and several internal servers. Two days. Working app. I'm not a developer.

If you're hiring a junior developer in two years time, the people applying for those jobs are going to look very different from the hand coders you've hired before. We're going to be hiring AI native software engineers. People who don't need to know how to write code in the syntax sense, but who absolutely know how to build software. Real software. Production grade.

What This Means If You're Hiring

If you're a CEO or CTO trying to push AI coding into a team of hand coders, keep pushing. Be patient. Pick AI native engineers when you hire.

Most of the rest will come around when the evidence is loud enough. Probably faster if it's coming from someone other than you.

And if you're where I was a year ago, don't be discouraged. Their mindset will change. Their work will change. Mine did.

A year ago they called it bad code. Today they're using it daily, in production. The argument resolves itself. If you outlast it.

Watch the video:

Last week I got on a call with a customer who'd built a working app for his business in a week. When I asked him what database it was running on, he didn't know.

That's vibe coding.

And there's a line, currently invisible to most people, between vibe coding and what I think of as professional AI coding. Same tools on both sides. The code can look identical on the surface. The difference doesn't show up until something breaks. And by then, it's usually too late.

I'm running a 20-person dev team at We UC, our unified communications platform. I founded circle.cloud, the telecoms business behind it. I spend most of my days either building software with AI or watching my customers try to do the same, and what I'm seeing is a line forming between two completely different disciplines. One side is genuinely transformative for small businesses. The other side is a time bomb waiting to go off in production.

This post is about where that line sits, and which side of it your business needs to be on.

A Customer Who Built an App in a Week

Back to that phone call.

The guy on the other end of the video call runs a commercial refurbishment business. He fits out schools, hospitals and offices. His biggest operational headache was managing contractors. Sending out jobs, collecting quotes, tracking documents. The off-the-shelf tools were either too generic or required four separate products duct-taped together.

So he opened Claude Code and tried to build the thing himself.

He isn't a developer. His background is in web design, so he knows Figma and Photoshop. He knows what good user experience looks like. He doesn't know software engineering.

A week later, he had a working app; with login, contractor onboarding, job offers & bidding for his contractors, document uploads, messaging, everything he needed for a v1.

That's when I asked the question.

"What database are you using?"

He paused. Then logged into Vercel to check. Came back and said Supabase.

That's pure vibe coding. He'd built an app, and he had no concern about the architecture or the infrastructure. The AI was handling all of it, and for his internal use case, that was fine. It's brilliant, in fact. Five years ago, this person couldn't have built a single screen of that app, let alone the whole thing. Now he's solving a real operational problem in his own business in a week.

But if he ever opens that app to real customers, or starts holding data that matters, he's going to find a line he didn't know was there.

The Line, Explained

Vibe coding is the practice of describing what you want and accepting what the AI gives you. The AI picks the database and the infrastructure. The person vibing doesn't need to know any of it. For an internal tool sitting behind a corporate network or Cloudflare Access, that's a perfectly reasonable trade-off.

Professional AI coding is something else. The AI still writes the code, but before it writes a single line, three things have already happened.

1. A Detailed PRD and Technical Spec

Not an agile user story on a Post-it note. A proper product requirements document, paired with a technical spec. It explains, in the least ambiguous way possible, what the software does, why it needs to exist, how it integrates with other systems, what it doesn't do, and every edge case you can think of.

The best test I can think of is this: if you handed those documents to three separate engineers in isolation, they should all build roughly the same thing. If the spec leaves more room for interpretation than that, it isn't tight enough.

2. A Human Engineer Has Made the Architectural Decisions

The db, data structure, API endpoints, security, whether there's a queueing system or message bus like RabbitMQ or Apache Kafka in the mix, etc.

These aren't handed off to the AI agent. They're handled by a professional who understands what those choices will cost six to twelve months down the line, when your customer base has grown, the product has evolved, and a design decision made in week one is suddenly the bottleneck.

3. The AI Confirms Its Plan Before It Writes Anything

You feed in your docs, and instead of letting the model start coding straight away, you ask it to come back with its implementation plan first. It should return something like: "Here's what I understood from your request, and here's what I'm going to build." A human then reads that plan and confirms it's correct before any code is generated.

The AI is the muscle. The human is the brain.

That's the line. Everything else is a consequence of it.

Same AI tools on both sides. The code may even look similar at first glance. The difference is invisible on the surface until something breaks.

What Professional AI Coding Looks Like in Practice

At We UC, we're in the middle of building a serious upgrade to our analytics module. Custom dashboards, with the option to pull data from external sources. Effectively a mini BI tool built into the platform. Because of what we've learned, we're approaching this one very differently from how we've built things before.

First, we've written a properly detailed PRD. What the module does, why it exists, how it integrates, what it explicitly doesn't do, every edge case.

Second, our lead software architect is writing the technical specification. Data models, API contracts, state diagrams, error handling. The things AI coding tools aren't qualified to decide on their own.

Third, we'll use Claude Code to actually generate the implementation. With the architecture documented and the spec unambiguous, the AI should be able to handle that part with discipline.

There's a fourth idea I want to test as part of this project. I've been calling it an "anti-ambiguity agent". The idea is simple: we feed our documentation into a sequence of agents whose job is to look for ambiguity in the spec. Anything unclear comes back with a short list of possible interpretations, and our architect either picks one or proposes a better alternative. The output is a specification so unambiguous that whatever writes the code has no room for doubt.

It's slower to start than vibe coding. The PRD takes time. The spec takes time. The back-and-forth with the architect takes time. But once the foundation is in place, the AI moves fast, and the code that comes out is something we can actually deploy to paying customers.

The Wave Is Already Hitting Small Businesses

The other phone call I had recently was with a dentist. Not my dentist, a customer of ours. He owns two dental practices, but between them they do the patient volume of five, because he's automated most of the usual admin away. His whole thing is business efficiency through technology.

And he'd hit the same problem as the refurb guy. He wanted a single piece of software that did exactly what his practices needed. The only off-the-shelf answer was to stitch together four or five different subscriptions.

So instead, he built the thing himself. A CRM with lead tracking and marketing. A finance dashboard that integrates with Dentally. A built-in learning management system. All in one platform, running production-quality code. He isn't doing it solo. He hired a developer with about ten years of experience who's now all-in with AI coding. Together they wrote the documentation first, then fed it into Claude Code. Eight weeks later, they've got a working prototype, and he's planning to launch it as a SaaS to other dental practices.

This isn't a one-off. Right now at We UC, we've got three open integration requests from customers who've either built their own custom CRM from scratch or are in the middle of doing it. Three, just from our own customer base. People who, a few years ago, would never have imagined themselves building software at all.

This is the thing I want small business owners and founders to understand. It's happening everywhere, behind the scenes, inside ordinary SMBs. Every one of those founders is going to run straight into the vibe-versus-professional line at some point. Usually the moment they sign up real customers, or something breaks under load, or they need to add a feature the prototype can't support.

Where This Fits in the Bigger Picture

There's a useful framework from Dan Shapiro that maps this territory. He describes five levels of AI coding, running from "spicy autocomplete" at level zero to what he calls the "dark factory" at level five, where software is generated fully autonomously from specifications with no human in the writing loop. A company called StrongDM claims to be operating at level five already. They only hire developers who don't write code.

Most dev teams I talk to are sitting at level zero or one without realising it. Most vibe coders, meanwhile, are actually operating somewhere around level four, writing specifications in plain English and directing the AI without ever touching the code. The gap isn't the level of autonomy. The gap is engineering discipline.

Know Which Side You Need to Be On

I'm not anti-vibe-coding. I vibe code things on the side for fun. I love it. It's a genuinely useful skill for prototypes, internal tools and low-stakes builds.

But if your business is shipping software to real customers, or holding data that matters, or running on the assumption that more users will join next month, vibe coding alone will eventually bite you. The foundation simply isn't built for the weight you're going to put on it.

The businesses that win with AI coding over the next few years will be the ones that recognise this line early, and plan the transition from vibe coding to professional AI coding before it's forced on them by an outage or a security incident. That transition is exactly what we're working through at We UC, piece by piece, starting with the analytics module.

Vibe coding is for prototypes. Professional AI coding is for production.

The line is almost invisible right now. The founders who learn to see it will ship better software, for longer.

Be one of them.

The video version of this drops on YouTube tomorrow. Same content, different format. If you're not subscribed to the channel already, that's where to find it: youtube.com/@axelmolist.

If running a business through the AI transition is on your plate, I also wrote The CEO Operating System, the framework I use to run multiple companies without burning out. It's free. axelmolist.com/ceo-os

Got thoughts, pushback, or a story of your own on this? Hit reply. I read every email.

Thanks,

Axel.

If your business builds software - even a little - your dev team is changing faster than you realise. Not the people. The work itself.

I'm running a 20-person team building We UC, our unified communications platform. And over the last six months, I've watched something strange happen. The bottleneck in software development isn't where it used to be. It's moved.

And if you're hiring developers right now - or trying to figure out why your team isn't shipping faster despite using AI tools - you need to understand this shift.

This is not just for tech CEOs. If you have two developers and a Claude Code subscription, this applies to you. If you run a services business that hired a dev to build an internal tool, this applies to you. If you are a founder vibe-coding your own MVP in Replit, Lovable or Cursor, this applies to you. Anywhere software is being built, the shape of the work has moved.

How Software Development Used to Work

Here's how it worked when I started building We UC.

You hired developers to write code. You measured their output in lines committed, features shipped, story points closed. Code review was the quality gate. If it passed review, it shipped.

The craft was the code itself.

But now with We UC, something fundamental shifted. We started using AI coding tools - Claude Code primarily, with some of the team using Cursor. And the entire rhythm broke.

The code started arriving faster than we could process it. Therefore the job changed.

The Question That Started Everything

Three months ago, one of my senior engineers came to me visibly frustrated. He'd spent two days reviewing pull requests from a junior developer using Claude Code. Thousands of lines. Feature worked perfectly. Tests passed.

But he looked at me and said: "I didn't actually read the code. I couldn't. There was too much of it. What's my job now?"

That question landed. Because I'd been feeling the same thing but couldn't name it.

Around the same time, I came across findings from a Thoughtworks retreat - senior engineering leaders from the biggest tech companies, brought together to figure out what happens when AI writes the code. They didn't leave with answers. They left with a map of fault lines. Places where traditional software development is cracking right now.

And reading through it felt like reading my own notes from building We UC.

Where the Work Migrated

Here's what nobody tells you about AI writing code: the engineering quality doesn't vanish. It just moves upstream.

Think about a normal user story: "As a user, I want to upload a photo."

Your developers know what that means. JPEG, PNG, reasonable file size, progress bar. Cultural context fills in the gaps automatically.

But an AI doesn't have that context.

The 50,000 Email Problem

We learned this at We UC the hard way. One of our developers asked an agent to build a notification system. Simple request. The agent built it. Worked beautifully in testing.

Went to production. Started sending 50,000 emails in three minutes.

Because there was no rate limit in the specification.

The engineering rigour we used to apply after the code was written now has to happen before a single line exists.

We've gone back to techniques that felt dead - structured requirements, state machines, decision tables. The kind of formal documentation agile was supposed to kill.

But here's the thing - that rigour makes the AI incredibly effective. When we feed an agent a state machine showing exactly what states are allowed and what transitions can happen, the code it generates is almost always correct.

The specification became the product. The code? Disposable.

The code died. The spec won.

That is the shift. Everything else is a consequence of it.

If we have a perfect test suite and decide to rewrite our backend from Python to Rust, we just feed the tests to an agent and say: make these pass.

This is a complete inversion of how software used to be built.

The Layer Nobody Named Yet

There's a layer of work emerging in my team that doesn't have a name yet. It sits between writing code and shipping to production.

I call it supervisory work.

Breaking problems into agent-sized chunks. Knowing when to let the agent run and when to step in. Fixing output not by rewriting code but by adjusting the prompt or the constraints.

And here's what surprised me. My team split into two groups.

Group one: the seniors who understand the whole system. They're drowning. The juniors and agents generate code at 10x speed, but code doesn't ship itself. It needs architectural review. It needs to fit legacy systems. It needs to be unblocked. My senior engineers became traffic controllers, too busy reviewing AI output to actually build anything themselves.

Group two: the juniors who just started. They're thriving. No muscle memory telling them to write code a certain way. They treat the AI as a teammate, not a threat to their identity.

And the net-negative phase is gone. We used to hire a junior and they'd drain productivity for six months whilst learning where everything is. Now? A junior with Claude Code ships useful code in week one.

The Danger Zone: Mid-Level Engineers

But there's a danger zone nobody's talking about. The mid-level engineers. Three to five years of experience. Just enough skill to be set in their ways. Not enough to be true architects.

Retraining them - teaching them to supervise agents instead of writing syntax - that's the hardest organisational challenge we're facing as a company.

So here's what I'm learning as a CEO hiring developers. The job description just changed. If you're looking for people who write code fast, you're hiring for the wrong skill.

You need people who can architect systems, write unambiguous specifications, and supervise non-deterministic agents. That's a completely different person.

What Breaks: The Tribal Knowledge Problem

Last month, our server went down at 2am. Error code 503: Service unavailable.

On-call engineer - sharp, capable - asked an AI assistant for help. AI read the documentation. Said: restart the server.

He did. Crashed again five minutes later. Restarted. Crashed. Restarted. Crashed.

By the time he escalated to me, we'd restarted the server six times.

I looked at the logs for 30 seconds and knew exactly what it was. Database connection pool was full because a marketing batch job was running.

That's not documented anywhere. It's tribal knowledge. Lived experience.

An AI doesn't have that. It sees 503, reads the manual, restarts the server. Over and over.

This is why all the hype about "self-healing systems" is rubbish right now. To make an agent effective during an outage, you need to build what the Thoughtworks retreat called an "agent subconscious" - a knowledge graph of every incident, every weird edge case, every bit of undocumented institutional knowledge that lives in your senior engineers' heads.

We're starting to build that at We UC. Every time something breaks, we document not just what happened but why someone with experience would know what to do.

The Yes-Man Problem

But there's another problem. AI agents are trained to be helpful. They're yes-men.

During an incident, you don't want a yes-man. You want someone to challenge your assumptions. One engineer at the Thoughtworks retreat suggested we need "angry agents" - specifically prompted to poke holes in your theory. Because otherwise the human and the agent will just agree with each other whilst the server burns.

Here's the point. If your business is betting on AI to make your software team faster, you need the prerequisites first.

Documentation that actually captures how things work. Seniors who can architect, not just code. And a system for preserving institutional knowledge before the AI makes everyone forget how things actually work.

The Graphics Card Analogy

So here's what I've learned running a dev team in the age of AI agents. The work isn't disappearing. It's moving from execution to supervision.

Think about graphics programming in 1992. Engineers hand-coded the maths to draw a single polygon on the screen. Calculating exact pixel positions. By 1994, the GPU arrived. Hardware did the polygons.

If you insisted on hand-coding polygons in 1995, you weren't a specialist. You were obsolete.

The engineers who survived became lighting engineers, animators, physics programmers. They weren't telling the computer how to draw a triangle. They were telling it how light reflects off a wet street.

Nobody hand-codes polygons anymore. We all work in game engines.

Software engineering is hitting that exact moment right now.

What to Look for When Hiring

So if you're hiring developers, here's what to look for. Not coding skills. Architectural thinking. Judgement under uncertainty.

Can they write a specification tight enough that an AI can't misinterpret it?

Can they design a test suite that catches hallucinations before production?

Can they debug a system they didn't personally write?

At We UC, that's what we hire for now.

The Cognitive Debt Problem

And here's what keeps me up at night. For decades, code review wasn't just about catching bugs. It was how developers learned the system. If agents write all the code and your team stops reading it, they become strangers in their own codebase.

When something breaks at 3am, they're staring at code written by a machine, trying to reverse-engineer the logic whilst your customers are screaming.

We're building tools for what we call continuous comprehension. AI that summarises architectural changes. Weekly sessions where the team architects together even though agents write the code.

Because you have to schedule time to understand your own software now. It won't happen naturally anymore. The speed of AI demands it.

What This Means If Software Is Built Anywhere in Your Business

So look, if software is being built anywhere in your business - or you are thinking about starting - the ground is shifting.

Your seniors are drowning in review. Your juniors are thriving with AI. Your mid-levels don't know which way to jump.

The companies that win will be the ones that see this shift coming and retrain before it's too late.

I'm not pretending I have all the answers. We're figuring this out in real time at We UC. Making mistakes. Adjusting. Learning what works and what doesn't when you're leading a dev team through this transition.

But one thing is clear: the best founders I know aren't panicking. They're adapting.

Be one of them.

If running a business through the AI transition is on your plate, I wrote The CEO Operating System - the framework I use to run multiple companies without burning out. It is free. axelmolist.com/ceo-os

I am in Spain right now, spending a few days with the family. And when I get time like this - away from the day-to-day, away from the noise - I tend to reflect.

I thought I would put together a list of my fundamentals. The guiding principles I use for business and life in general. Not because I have it all figured out. I definitely do not. But because I think there is value in hearing how other people think about these things. Maybe some of it resonates. Maybe it helps you put into words something you already felt but had not formalised yet.

A bit of context if this is your first time here. My name is Axel Molist Cordina. I am originally from Spain, and I have been living in the UK since 2008. I founded a telecoms services company called circle.cloud - built it from scratch to about 140 people - and I now run a telecoms software company called We UC, which we are in the process of launching as a SaaS product. So I have been building for over a decade. Everything I am about to share comes from that experience.

These principles are not for everyone. They are what works for me. But if the rationale behind any of them feels right, then perhaps they will be useful for you too.

1. Love What You Do

This is the foundation for everything else.

I genuinely believe the only way to do great work is to love what you do. Building something - a company, a product, anything worthwhile - is incredibly hard. There are countless moments where a rational person would simply walk away.

The only people who push through are the ones who actually love the work itself. Not the money. Not the status. The work.

Steve Jobs put it well in his 2005 Stanford commencement speech: "The only way to do great work is to love what you do." He also said that only the people crazy enough to think they can change the world are the ones who actually do. I think he was right. You have to be obsessive. You have to love it.

And if you do great work, money follows. Not immediately. Not always on your timeline. But it follows. The mistake is chasing money first and hoping quality comes later. It does not work that way.

2. Keep Your Word

There is a line from Scarface that has always stuck with me: "All I have in this world is my balls and my word, and I don't break 'em for no one." It resonated because there is genuine truth in it.

You have to keep your word. If you say you are going to do something, do it. It does not matter how small the commitment seems. If you said you would call on Tuesday, call on Tuesday. People remember when you follow through. And they remember even more clearly when you do not.

I stay true to my word. Always. It is not negotiable. Your reputation is built one kept promise at a time.

3. Do the Right Thing

This one sounds obvious until the moment arrives when the right thing is also the harder thing. The slower thing. The less profitable thing in the short term.

I have watched people cut corners because they could see a quick win. But that quick win sometimes meant hurting someone, or doing something ethically grey, or going down a path that bypassed lessons they actually needed to learn.

Do not take the shortcut. Even if doing the right thing takes three times longer to get you where you are going, you will arrive with your integrity intact. And that matters more than speed.

4. Be Patient but Relentlessly Persistent

There is an old saying that a woodpecker does not peck a thousand trees once - it pecks one tree a thousand times and gets dinner. I love that because it is exactly how building a business works. You pick a thing. You commit to it. And you keep going.

Most things take longer than you expect. That is fine. The people who stay the course - who do not jump to the next idea every time things get hard - are the ones who eventually break through.

5. Ask for the Order

Do not be shy. Ask for what you want.

I have lost deals simply because I did not ask for the order. I was waiting for the customer to say yes. They did not. Sales is not just about building relationships. At some point you have to say, "Let's do this." That is it. Assume you have the order. That is the part most salespeople avoid.

It is the same outside of sales. If you want something - a meeting, a favour, an introduction - ask. If you do not ask, you do not get. It really is that simple.

6. Mueve el Culo (Move Your Arse)

This one is related but different. Do not wait for things to come to you.

Some companies build their entire model on referrals and word of mouth. That is fine. But I believe you also need to go and get the business. Pick up the phone. Show up. Speak to people. Meet new people. Move. Be proactive.

The phone is not going to ring itself. And opportunities do not land on your lap. You have to go out and create them.

7. Set Unrealistic Deadlines

I set myself deadlines for everything, and I make them optimistic on purpose.

When you give yourself a tight amount of time, you fill that time with focused work. Give yourself two weeks, it takes two weeks. Give yourself five days, you find a way. That is Parkinson's Law in action.

Many of my projects have overrun their original timeline. That is fine. The deadline is not there to punish me. It is there to create urgency. Without a deadline, things drift. And drifting is what kills most projects.

8. Think Ten X

However big you are thinking, think bigger.

Whenever I come up with a goal or an idea, I ask myself: can we do ten times this? Can we make it bigger, better, bolder? That does not mean every idea needs to be massive. It means you should test the ceiling before accepting the floor.

Most people set goals based on what feels safe. Safe goals produce safe results. Push the number. You can always scale back. If the idea does not scare you a little, you are probably not pushing far enough.

9. Get Out of Your Comfort Zone

Your comfort zone is your limiting zone.

Every significant thing I have done - the first cold call, hiring my first employee, stepping back from the company I built, making videos like this one - felt uncomfortable at the time. That discomfort was not a warning. It was a signal that it mattered.

If you are not regularly doing things that make you uncomfortable, you are not growing. It is that simple. Push yourself out of the comfortable space. That is where progress lives.

10. Action Trumps Inaction

Move. Act. Stop thinking about it.

Overthinking kills more progress than bad decisions ever will. There is a real cost to inaction. A wrong decision gives you information - you learn, you correct, you move forward. No decision gives you nothing. You are just stuck.

I would rather make a move and get it wrong than sit and analyse until the moment passes. If you got it wrong, you will figure it out. But you have to move first.

11. Follow Your Gut

They say your gut is your second brain. There is real science behind it - neurons exist in your gut, and that is what people call the "gut feeling."

I think it is how you connect your conscious mind to your subconscious. In so many decisions I have made in business and life, I have made them when the decision felt right - not when the spreadsheet told me to act.

Our brains are far more powerful than we give them credit for. I believe your gut is your gateway to that deeper level of intelligence. Your intuition. I trust my gut on every major decision, and so far it has served me well.

12. Don't Trust No One

My father always told me something his mother used to say.

"No et fiis ni de la teva mare." That is Catalan. It means "do not trust even your mother."

It sounds extreme - and it is extreme - but the principle behind it is sound. Be careful with people. Especially when money is involved. I have seen people do surprising things when the stakes are high. People I thought were solid.

Trust with limits. Do not trust anyone entirely.

13. Hire Based on Attitude

When hiring, attitude beats skills. Every time.

Skills can be taught. You can teach someone a system, a tool, a process. But attitude - which is based on their perspective on life - determines how they show up, how they handle pressure, whether they actually care. All of that is rooted in how they see the world. And you cannot teach that. It is who they are.

I have learned this the hard way. I have hired people with incredible CVs who simply did not have the right attitude. And I have hired people with very little experience who turned out to be brilliant because they genuinely wanted to learn and improve.

Find people who care. Teach them the rest.

14. Learn to Delegate

This one is hard. Genuinely hard.

I founded circle.cloud. Built it from nothing. Did the telemarketing, the sales, the installations, the billing, the support - all of it. But in order to grow the business, I had to step back. I hired an operations manager, an engineering manager, a sales manager, and eventually a board of directors and a CEO. I moved to chairman. The business operates without me day to day now.

For a founder, letting go feels like losing control. But it is the opposite. It is gaining freedom.

And I believe your leadership team needs to be genuinely invested. The only way I have found to make the key people in your business feel like owners is through equity. Give them a minority stake. Something that aligns their incentives with the long-term success of the business, not just a salary. Never give away control. But give them something to care about.

15. Empathy Is Your Superpower

This one is underrated.

Being able to see things from someone else's perspective - understanding how they actually feel in a situation, not how you think they should feel - gives you a genuine edge. It changes how you lead, how you sell, how you handle conflict. Everything.

Most people listen to respond. Very few people listen to understand. There is a massive difference.

16. Make Time to Think

I have a policy: no meetings before 11 AM, unless completely necessary.

The morning is when my brain is sharpest. That is when I think, plan, and work on the hardest problems. Most people fill their mornings with meetings and emails - other people's agendas - and by lunchtime they have spent their best cognitive hours on things that could have waited.

I use my mornings to putter. To think about business direction, company structure, whatever the biggest challenges are. Sometimes I do not produce anything visible. But that thinking compounds over time.

Spend time alone. Ruminate. Let your mind work through the hard problems before the day takes over.

17. One Thing at a Time

When your to-do list is a mile long and everything feels urgent, the worst thing you can do is try to deal with it all at once.

One thing at a time. Give your full attention to the thing in front of you. Finish it, or get it to a point where you can move on, and then - and only then - shift to the next thing.

This is not about productivity. It is about preventing overwhelm. When you try to hold ten problems in your head at once, your stress rises and your output drops. Deal with one. Then the next. It sounds too simple to work, but it does.

18. Focus on the Signal

Every day there is noise. Emails, messages, requests, small fires. Most of it does not matter.

The signal is the one or two things that actually move you forward. Everything else is noise. And the hard part is not ignoring the things you do not want to do - it is ignoring the things you do want to do.

There is a story about Steve Jobs. Jony Ive said Steve used to ask him how many things he had said no to. And when Jony listed a few, Steve was not impressed, because Jony did not want to do those things anyway. That is not focus. Focus is saying no to the things you want to do with every fibre of your body - because the signal matters more.

Increase the signal-to-noise ratio. Say no to everything that is not the main thing. And do the main thing until it is done.

19. The 80/20 Rule

When deciding what to work on, do the work that will produce the majority of the results first.

That is the Pareto Principle - roughly 80% of your results come from 20% of your effort. So when prioritising, ask yourself: what is the thing that will get me the biggest result in the least amount of time?

Start there. Because that early progress gives you momentum. It gives you a feeling of accomplishment that you can carry forward - either onto the next task or to keep pushing on the one you are on.

Most people spread their effort evenly across everything. Do not. Find the 20% that produces 80% of the output. Hit that first. Then reassess.

20. Prioritise Sleep

I think sleep is the most underrated performance tool there is.

I aim for seven and a half hours every night. I do not always hit it, but I know the difference it makes. Everything deteriorates when you are under-slept. Your decisions, your mood, your patience, your clarity, your ability to handle stress. Everything.

And the data supports it. Sleep deprivation has been shown to impair cognitive function to the same degree as having a few drinks. That is not a small thing.

I have learned to treat sleep as infrastructure. Not a reward for finishing work. Not something to sacrifice to get more done. It is the thing that makes everything else possible.

21. Eat Well

This one is straightforward. Eat good food. Cut out the processed stuff. Do not overeat - that is one I still struggle with.

And do not eat within four hours of bed. That has been massive for me. Eating late wrecks sleep quality, and then everything cascades from there.

I am not extreme about diet. I do not follow any particular plan. I just try to eat real food, eat reasonable amounts, and give my body time to digest before sleeping. It is simple, but the impact on how I feel day to day has been enormous.

22. Train Every Day

I try to train at least five days per week. Weights. Ideally I would do something every single day, even if it is just a lighter session.

I am not perfect at this. Travel disrupts my routine. Bad sleep undermines my motivation. But I am working on making it non-negotiable. Because when I am consistent with training, everything else improves - my energy, my focus, my resilience, my mood and my sleep.

Your body is the engine for everything else. If the engine is not looked after, nothing else runs properly.

23. Ditch the Alcohol Trap

Alcohol is a trap. And I say that from experience.

A few years ago I read a book called This Naked Mind and it made me think about something simple. We were all happy as kids. No alcohol. Perfectly content. So why do we believe we need it as adults? We do not. We are habituated to it.

I stopped drinking for over a year. I felt amazing. Then on holiday, my wife suggested I have a beer. And I thought, well, I will just have one. Within a few months I was back to drinking almost daily.

January of this year I stopped again. Currently just over two months in. I feel great. No plans to go back.

Not drinking has improved my sleep, my clarity, my productivity, my mood - everything. If there is one thing on this list that has made the biggest difference for me recently, it is probably this one.

24. Practise Gratitude

I have a lot already. More than I sometimes realise. More than I ever imagined as a kid. And I take it for granted more than I should.

But when I actually stop and remind myself of what I have - where I am, who I am with, what I have built - I feel genuinely happy. Not in a forced way. In a real way.

It is easy to always be chasing the next thing. Gratitude is the counterbalance. It is what stops ambition from becoming a treadmill.

25. Embrace Being Different and Stop Caring What Others Think

Last one.

Everyone is different. Embrace what makes you different. There is nobody out there like you, or like me. Which makes it pointless to compare your life to someone else's.

I think we have fallen into this trap because of social media. We see other people's highlight reels and believe we are falling behind. But you are not behind. You are on your own path.

And the freedom that comes with genuinely accepting this is enormous. Stop caring so much about what other people think. We are only here for a short amount of time. Everyone is busy with their own lives. They are not thinking about you anywhere near as much as you imagine.

I used to care a lot more than I do now. And that freedom has changed how I make decisions, how I work, and how I live.

Final Thought

Those are my guiding principles. Twenty-five things I come back to, especially when I need to make a decision or when things get complicated.

I am not perfect at all of them. Some I have followed for years. Some I am still working on. But having them clear in my head helps. And I hope putting them into words helps someone else too.

If you want to go deeper into how I structure my days and my decision-making, I have put together something called the CEO Operating System. You can find it at axelmolist.com/ceo-os.

Last week I attended the Cavell Summit Europe in central London - a one-day conference that brings together the major telecoms providers, carriers, and product builders across the UK and Europe. The room was full of founders, CEOs, and market analysts. The day was packed with talks, panel discussions, and live audience polling.

I went in expecting a conversation about the state of the telecoms industry. I came out thinking about something much bigger. Five themes kept surfacing throughout the day - and they tell you a lot about where this industry is heading.

1. Data Sovereignty is No Longer Optional

Sovereignty was one of the headline topics of the conference, and rightly so.

The concept is straightforward: data should stay within the country or region it originates from. But in practice, particularly in telecoms, it gets complicated quickly.

If you are running a voice service and your session border controllers sit in the public cloud - Amazon Web Services in the US, for example - it is entirely possible that a phone call made by your customer in London traverses the Atlantic before coming back. The call itself may be encrypted, so eavesdropping is unlikely. But the moment you introduce AI into the equation - transcription, call analysis, sentiment scoring - the data starts moving. A call recording might be sent to OpenAI for transcription. That transcription might then be processed by another service for analysis. Each hop is a potential sovereignty issue.

And the risk is not just theoretical. A US-based AI provider could receive a subpoena from the Department of Justice, and suddenly the contents of a business phone call are in the public domain. That is not a far-fetched scenario - it is a legal reality of hosting data in another jurisdiction.

The large carriers are responding by establishing physical data centres in every country they operate in. They guarantee to customers that their data does not leave that geography. When it does, the customer is told explicitly. Google announced a partnership with Mistral, a French AI company, to deliver a sovereign AI product for the European market. If a company the size of Google is partnering with a French company specifically to address European sovereignty concerns, something significant is happening. There is regulation being implemented over the coming months that will make this even more prominent.

For anyone running voice services to businesses - enterprise or SME - the question "where does my data go?" is no longer theoretical. Customers are asking it. They understand enough about the cloud to know that "the cloud" is not one place. They want specifics. And they are right to ask.

We self-host our infrastructure at We UC. Our servers sit in the UK. We run data centres in London and on the South Coast, and we even run our own AI service on our own infrastructure. All the call recording transcription, analysis, and summarisation happens locally. You do not need the most powerful models in the world to do transcription and summarisation - that is a common misnomer. We have managed to do this on our own infrastructure, keeping all data within the UK. It is one of the decisions we made early on, and watching this conversation unfold at the conference reinforced that it was the right one.

2. AI is Not a Feature - It is the New Electricity

There was a lot of talk at the conference about how AI is going to disrupt the workplace. How AI will impact telecoms. How businesses should plan for AI.

It struck me that the conversation is framed incorrectly.

AI is not a feature you bolt on. It is not a module you activate. It is closer to electricity - so fundamental, so omnipresent, that discussing "how electricity will impact our business" would sound absurd. Yet that is essentially how parts of the telecoms industry are still treating AI. As something new. Something to plan for. Something to discuss at conferences.

The reality is that AI has already changed how most knowledge workers operate. It has already rewritten the economics of software development, customer service, content production, and data analysis. Treating it as an upcoming disruption misses the point. It is the new baseline.

I think this reflects a divide that has been growing for years - between traditional telecoms companies and modern software companies.

Traditional telecoms providers are, by nature, infrastructure businesses. They operate on BSS and OSS systems that were built decades ago. Their software development practices prioritise stability and basic functionality over innovation. The interfaces are over-complicated. The architecture is legacy. The appetite for rapid change is low - not because the people are not smart, but because the systems and culture were built for a different era.

On the other side, you have companies like ElevenLabs. Born in the modern era. Running on Kubernetes. Advanced CI/CD workflows. AI woven into every part of how they build and ship. They care about design, about user experience, about craft. They do not have twenty years of technical debt weighing them down. They move at a completely different speed.

The telecoms industry is full of companies operating like it is still 2010. Meanwhile, modern software companies are building products that interact with the same customers, solve the same problems, and move ten times faster. That creates a gap - and it is widening.

3. Voice AI Was the Real Story

The conference organisers positioned sovereignty as the main theme. And it was well covered. But the topic the audience actually wanted to discuss - overwhelmingly, based on a live poll at the start of the day - was voice AI.

It is not hard to see why.

One of the demonstrations came from Bandwidth, an international carrier with a strong presence in Europe. They partnered with a hotel chain and implemented a voice AI solution that handles the front desk. Guest calls about room service orders, booking modifications, general enquiries - all handled by AI with access to the hotel's booking system. The problem it solved was simple: during busy periods, the hotel did not have enough staff to answer every call. Guests were left waiting. With voice AI, the constraint disappears. You can have thousands of agents handling calls simultaneously, freeing human staff to focus on face-to-face interactions.

Another example: a restaurant chain facing the same problem. At peak hours, waiters cannot answer the phone. Customers calling to book a table, modify a reservation, or ask about the menu are left on hold or unanswered. A voice AI solution with access to the restaurant's systems solves this immediately.

These are not theoretical use cases. They are live deployments.

The interesting tension in this space is between two camps. On one side, tech startups are building voice AI solutions rapidly but often know nothing about telecoms. They do not understand session border controllers, call switches, or quality of service at the network level. They route calls through an API to something like Twilio so they can make and receive phone calls, and they ship the product. They know the customer. They win the deal. But the quality of service cannot be as good as if they owned the whole stack. If these startups understood how a soft switch works, how to route calls on-premise, how to run phone calls at scale on their own network - the call quality would be better, the troubleshooting faster, and the whole thing cheaper and more stable long-term.

On the other side, traditional telecoms providers understand the infrastructure deeply but are too slow to build these solutions themselves. They provide the telecom services but not the value-added solutions on top. Meanwhile, the startups are putting voice AI products in front of the telco solution and extracting margin from providers who should be delivering it themselves.

There is a gap between the two. And I believe We UC sits in that gap. We have the software skills and the pace of a modern company. We also have the telecoms experience - the soft switch experience, the network we are running ourselves. We are positioned at the intersection of a modern software company and a traditional telco. That middle ground is where the opportunity is. It is also where we are building Ringup, our voice AI product that will be built directly into We UC.

4. Voice is Going to Zero

A recurring message at the conference: the traditional telephony pricing model is dying.

The argument is straightforward. Services like WhatsApp have normalised free communication. A WhatsApp call costs nothing because it does not touch the public telephone network - both endpoints are controlled by the same company within a closed environment. But that creates a perception that all voice communication should be free. The ten or fifteen pounds per user per month model, with bundled minutes and a standard feature set, is gradually losing its value.

Businesses still have phone numbers. That is still the universal method for communicating with businesses through voice. But the pricing pressure is real.

So how do telecoms companies remain profitable?

The answer that emerged clearly from the conference: value-added services.

What does that mean in practice? Three things stood out.

First, data analytics and reporting. Connecting a customer's CRM, financial system, and phone platform so that data appears in one place - dashboards and scheduled reports that cover not just call activity but business performance.

Second, voice AI. Tools like Ringup, which we are building into We UC, that give businesses the ability to implement AI agents within their phone system. Not just agents that answer calls and take voicemails, but agents that can perform actions - booking appointments, modifying reservations, updating records - because they plug into the CRM integrations already in place.

Third, integrations themselves. Most businesses run a CRM or a financial system or some kind of platform to manage their operations. Integrating into these platforms allows a productivity boost, an efficiency boost, and allows customers to do their best work by having access to the best technology for their business.

The core voice licence becomes the entry point. The real margin lives in the solutions built on top of it.

For anyone building in the telecoms space, the message was clear: the commodity is the phone line. The value is everything you build around it.

5. Specialisation is the Only Way to Stand Out

The final theme that stayed with me is about focus.

We are preparing to sell We UC as a software-as-a-service product. In a crowded market - and unified communications is a very crowded market - having a product that solves many problems for many people is not a differentiation strategy. It is a path to invisibility.

I remember a marketing brochure from about ten years ago, when "cloud" was the buzzword. The headline was: "How do you stand out from the cloud?" It was a clever line then. It is even more relevant now, because the market is noisier than it has ever been.

The approach we are evaluating is straightforward: specialise.

In order to stand out, you need to understand the customer and understand their workflow. You need to know how they operate day to day and know what problems they have so well that you can create a solution that removes friction - so they can solve those problems faster and better with your product. The only way to do that at scale is to specialise.

Either you verticalise - specialise in a particular industry and solve a problem that industry has, because you understand it deeply enough to solve it well. Or you specialise in a particular solution that applies across multiple industries, but you solve the problem within that solution extremely well.

We are evaluating both paths right now. But the principle is clear: in a noisy market, the businesses that succeed are the ones that are laser-focused on solving one problem better than anyone else. Not something generic. Not "we do everything for everyone." Something specific for one specific type of customer - and being the best in the world at it.

That is what we are going to focus on with We UC. Once we have made the decision on which segment, every piece of marketing and every product decision will be shaped by it.

What I Took Away

The Cavell Summit condensed a lot of the themes I have been thinking about into a single day. Sovereignty is real and getting more urgent. AI is not a feature - it is the foundation. Voice AI is the most immediate disruption in telecoms. Traditional pricing models are eroding. And the only way to build something visible in a crowded market is to be specific about what you do and who you do it for.

None of these ideas exist in isolation. They overlap. The company that builds a communication platform with AI at its core, that handles data in a sovereign way, that is able to solve really specific problems better than anyone else, and that specialises in a particular vertical or solution - those are the companies that will win.

That is what we are building with We UC. And conferences like this one remind me that we are heading in the right direction.

If you want my operating framework for running at full capacity as a founder and CEO, it is free at axelmolist.com/ceo-os.

I have been fat. I have been thin. I have been somewhere in between. And the honest truth is that I have never stayed in one place for very long.

My weight has fluctuated my entire life - from childhood through my twenties, through building a business, through a wedding, through fatherhood - and it continues to fluctuate now. I am not writing this because I have solved it. I am writing this because I have not.

The Earliest Memory

The first time I remember being aware of my weight, I was about seven or eight years old. I did not feel fat. I only realised it when I compared myself to the other kids. Looking back, the explanation is straightforward: I was eating more than I was burning. That is always the explanation.

I do not believe genetics make weight loss impossible. Metabolism varies between people, and a smaller body burns fewer calories than a larger one - that is basic thermodynamics. But the principle is always the same. Calories in versus calories out.

The more interesting question is not why I was fat. It is why I was eating so much.

Food as Dopamine

Food is a dopamine release mechanism. Everyone knows this on some level, but not everyone experiences it the same way. For me, food has always been connected to pleasure in a way that goes beyond hunger. It is comfort, reward, and ritual.

As a child, I think I was chasing that dopamine without understanding what it was. My mother used to hide the biscuits around the house because I would find them and eat them all. She hid the mayonnaise for the same reason. At the same time, she would tell me to finish everything on my plate - food should not go to waste. That combination of abundance and obligation likely planted something deep.

This is not blame. It is observation. If my own son had the same tendencies, I would try to intervene, but I am not sure I could prevent it either.

The Obsessive Personality

I recognise something about myself that connects all of this: I am obsessive. When something gets into my head, I cannot shift it until I have either completed it, learned everything about it, or experienced everything I can about it. I am all in or not in at all.

This trait has served me well in business. It is the same quality that allowed me to build circle.cloud from nothing, working eighteen-hour days because I knew exactly what needed to be done.

But with food and weight management, it is more of a liability than an asset. The same intensity that drives productive obsession also drives destructive patterns. The dopamine chase that makes me relentless at work is the same one that makes me eat twelve hundred calories at half past ten at night when I know I do not need them.

The Alcohol Parallel

I stopped drinking alcohol a few months ago, and this is not the first time. A couple of years ago, I spent just over a year without drinking. It was a year of clarity - calm, collected, sharp thinking. I did not want or fancy alcohol in any form.

Then my wife suggested I have a beer with her at lunch on holiday. Just one. It would not hurt. And she was right - one beer did not hurt. But one beer became another, and another, and slowly I returned to the same patterns that made me want to stop in the first place.

Alcohol follows a predictable cycle. You have a drink and your mood lifts from baseline to somewhere above it. When the effect wears off, you do not return to where you started - you land slightly below baseline. So the next time you drink, you are starting from a lower point, and you need slightly more to reach the same feeling. Over time, the baseline keeps dropping.

I do not know anyone who has been drinking consistently for ten years and drinks the same amount today as they did at the start. The trajectory is always upward. Alcohol is a net negative to peace of mind, and I include it here because it operates on the exact same dopamine principle as food.

The Timeline

At fourteen, I decided I wanted to lose weight. I started skateboarding, running, swimming. I told my mother to give me less food. I made my own plates instead of having them served to me.

I remember walking downhill toward town one afternoon, probably around four o'clock, having skipped lunch. I was so hungry I felt like my body was consuming itself. That feeling has stayed with me. Every time I lose weight now, I remember it, and I think: this hunger means my body is burning fat. This is progress.

The problem is that this state is not sustainable. You cannot restrict yourself severely and expect the result to hold. Heavy restriction leads to heavy compensation later.

I fluctuated between sixty-five and seventy-five kilograms through my late teens and twenties - small ups and downs, nothing dramatic. Then I started my business, entered a long-term relationship, and stopped paying attention.

By 2017 or 2018, the weight started creeping up. Seventy-five. Eighty. Eighty-five. Ninety. At ninety, I essentially gave up. The business needed all my attention. I told myself I would deal with my body later.

Later arrived in late 2020 at a hundred and ten kilograms.

The Juicing Experiment

My son was two. My wedding celebration was coming up in October 2021. I watched a documentary about an Australian man who spent three months driving across America, consuming nothing but freshly juiced vegetables and fruit. He lost a tremendous amount of weight.

The approach appealed to my obsessive nature perfectly: extreme action, extreme results, clear rules, defined timeline. I bought a juicer and started.

After a couple of weeks, I found the process messy and time-consuming, so I discovered a London company called Prescription Juices that delivered freshly pressed juice frozen to my door each week. Their formulations were designed by dietitians and doctors - each day included juices with dates, nuts, celery, kale, oranges. Proteins, fats, carbohydrates, micronutrients. Around five hundred calories per day.

I juiced for ten weeks and went from a hundred and ten kilograms to sixty-seven. I felt on top of the world.

After the wedding, I hired a dietitian. That worked for three or four months. Then the old habits crept back in. Beer after work. Nuts with the beer. Wine with dinner. By 2023, I was back at eighty-five.

I hired a personal trainer, cut out most of the poor food choices, stopped drinking. Dropped to seventy-five. I have been fluctuating around that number since - down to seventy-two, up to seventy-eight, back to seventy-four.

Right now, I am at seventy-seven. My goal is sixty-five at around twelve percent body fat. I am currently at twenty-two percent. There is work to do.

Last Night

Here is where the self-awareness becomes both useful and frustrating.

Last night, I was at a boardroom event with a group of founders and CEOs. It ran from half six to half nine. I did not get back until half ten. I was not particularly hungry - I had eaten some snacks at the event - but I had not had dinner, and my brain decided that meant I deserved something.

I did not need a meal. I could have gone to bed. Instead, I walked to the shop and bought a wrap, peanuts, a yoghourt, a protein drink, and a chocolate bar. Instead of a hundred or two hundred calories, I consumed twelve hundred.

Why? Because my body wanted a small hit of dopamine before sleep. A comfort. A ritual to close the day. And I gave in.

This is the part that demoralises me. I am fully aware of what I am doing. I can describe the mechanism in detail. I know I am trading short-term pleasure for long-term progress. And I still do it.

Does this mean I do not care enough about the goal? Does it mean immediate gratification matters more to me than long-term results? I do not think so, not in the grand scheme. But something in the moment overrides what I know to be true.

I have not mastered this. I am still working on it.

The Types

One thing I have observed, and perhaps this is obvious but worth naming, is that people fall into distinct categories with weight:

1. You carry extra weight and struggle to lose it
2. You are thin and struggle to gain it
3. You fluctuate - a tendency toward one direction, interrupted by intense correction in the other

I am the third type. I have a tendency toward gaining weight because I have a tendency toward overeating. But I also have the capacity for extreme restriction - juicing for ten weeks, fasting for seven days, cutting out entire food groups overnight. The result is a life spent oscillating between states rather than settling into one.

Everybody is different. That is not a revelation. But naming the pattern you belong to is the first step toward working with it instead of against it.

Fasting as Clarity

The juicing journey introduced me to fasting, and fasting gave me something I did not expect. It was not the weight loss - although that helped. It was the mental clarity.

When I fast, I enter a state of enlightenment that I do not experience in normal life. There is peace in not having to think about food. There is a sharpness that arrives somewhere around the twenty-four-hour mark and intensifies at forty-eight hours.

This makes evolutionary sense. When our ancestors needed to hunt, they did so while hungry. The body adapted to be sharper when fasted - alertness was a survival advantage.

The longest fast I have done was seven days. Water and black coffee only, while working alone in Dubai. Physically, I felt incredible - like God, honestly. Mentally, every single day was harder than the last. Being surrounded by people eating in a hotel cafe while you are on day four of not eating takes a toll that is difficult to describe.

I broke the fast with a steak. It was probably the nicest tasting steak I have ever had, even though it was not a great steak. I followed it with a salted caramel iced coffee, which was so good I immediately had another one.

That experience was so intense it has actually put me off long fasts since. It was mentally draining in a way I was not expecting. But I will fast again. Fasting is no longer a weight loss tool for me - it is a reset. A way to achieve a temporary state of clarity and discipline that recalibrates everything.

If your doctor approves and you are healthy enough, I would recommend trying it. Start with a day. See how it feels. The sharpness alone is worth the discomfort.

Where I Am

I am at seventy-seven kilograms. I want to be at sixty-five. I have cut out alcohol again. I know what I need to do. I know the mechanisms that work against me. I know my obsessive personality will drive me to extreme measures and then pull me back toward excess.

I am closer to peace with this than I have ever been. Not because the battle is over, but because I finally understand the battlefield. The dopamine. The obsessiveness. The short-term override. The restriction-compensation cycle.

I do not have the answer yet. But I have the awareness. And I think awareness, honestly pursued, is the only foundation from which an answer can eventually come.

This is my journey. It is ongoing. And I suspect it always will be.

Everyone tells me the same thing. Just resell someone else's platform. It would be cheaper. It would be faster. It would make more business sense.

They are not wrong about any of that.

But they are wrong about what matters.

Selling Boxes Under Desks

My journey in telecoms started in 2012. I was working for a company that sold Siemens phone systems - physical boxes the size of three shoeboxes, plugged into walls underneath desks or shoved into corridors. On-premise PBXs for small businesses with five to ten users.

I could see that cloud was the future. It was obvious to me. I went to the owners and told them we needed to be selling cloud telephony. They disagreed - there was not enough money in it.

So I set up a company on the side. I got sacked for it. And that company became circle.cloud.

That decision - following my gut when the economics said otherwise - set a pattern I have repeated ever since.

The Search for the Right Platform

When I started circle.cloud, I needed a platform to resell. The obvious choice was Horizon by Gamma - solid, well-known, built on Broadsoft under the hood. But it was what everybody else was selling. I wanted something different.

I found a company called The Voice Factory, run by a man named Paul Harrison. Paul used to work at Broadsoft, and after he left he set up The Voice Factory and invested in his own Broadsoft platform. He believed in me at a time when I was just a person with a brand new company. Getting a reseller agreement with a telecoms carrier in 2015 was not as easy as it is today. You needed trading history, investment, industry connections. I had none of that. Paul took a chance on me anyway, and I have a tremendous amount of appreciation for that.

What drew me to Broadsoft was its architecture. The platform separated every service into its own cluster - one for the application layer, one for the database, one for media, and so on - all isolated, all horizontally scalable across multiple zones, meaning multiple data centres. You simply stack more servers in each zone when you need more capacity. It was the industry standard for good reason. Companies like Telefonica, Vodafone, and BT run their telephony on Broadsoft. You needed around four million pounds in capital to get a carrier-grade Broadsoft installation and licences, which was well beyond our reach at the time.

The initial years went well. We grew. But our billing costs grew too. We were spending around twenty thousand pounds a month on licence fees.

That made me start looking for alternatives.

The Outages That Changed Everything

I found a company called Bicom Systems that built their own cloud PBX on Asterisk. The licence fees were dramatically lower - charged per server rather than per user, with each server handling around 1,500 users. We made the switch.

At first, our software ran on Bicom's servers in their data centre. Then they had an outage in Milton Keynes. Two to three hours of no service for our customers. It made my blood boil. Their infrastructure standards were not where ours needed to be.

So we found our own data centre - a company called Netwise Hosting in central London, run by two founders who had built something remarkable. Small team, but the quality was extraordinary: diverse network paths, multiple carriers, Cisco routers in the core, multiple generators, multiple fuel contracts. We bought a quarter rack, installed our own servers, and ran the Bicom software on our hardware.

Then Netwise got hit with a DDoS attack. Not targeting us - targeting another customer. But because we shared the network, our service went down for three to four hours.

That was the moment I decided we would never again run our infrastructure on someone else's network. We invested in our own routers, our own switches, and established direct relationships with carriers for connectivity into our data centre.

Looking back, the evolution was a staircase:

1. First, we got our own software licences instead of paying per user per month
2. Then we hosted that software in a data centre we controlled
3. Then we ran it on our own network
4. Then we replaced the third-party software with our own

Step four is where the real story begins.

Finding Kazoo

I knew what I wanted: a platform with the scalability of Broadsoft but without the four-million-pound licence fee. Broadsoft had been acquired by Cisco by this point. I actually inquired heavily about obtaining a Broadworks platform, but the economics did not work.

The breakthrough came almost by accident. I was on a call with a telecoms consultancy from Argentina. Our requirements did not quite match what they could offer, but at the end of the conversation, one of them mentioned a small company in San Francisco called 2600 Hz that had built something called Kazoo. I had never heard of it. I made a note and moved on.

Months later, I hired a systems administrator named Konstantins - highly skilled, had built software products before. When I told him my goals, he said we could build something with one developer and have it in the market within six months. That turned out to be optimistic, to say the least.

What made Kazoo compelling was that it was architected as an open-source alternative to Broadsoft. Multiple application servers, multiple media servers, multiple SBCs, a distributed message bus - all capable of running across geographical zones. You could have a cluster in London and another in Amsterdam, failing over between them seamlessly. It was built for carriers and for scale. And it was open source, which meant no licence fees and full control.

We installed Kazoo, set it up in a distributed architecture, and started building.

Becoming a Software Company by Accident

The original plan was modest. Kazoo came with an open-source frontend called Monster UI, and we started by building a call recording application on top of it. That was meant to be the missing piece.

Within two months, Konstantins saw something bigger. Instead of bolting applications onto Monster UI, we should build our own platform from scratch - our own API, our own interface, our own product. One that talked to Kazoo for the PBX features but was entirely ours in terms of the user experience.

That decision changed everything.

We called it Circle UC at first. Then one day, the name We UC came to me. I was in the circle.cloud office and overheard Adam, one of the sales team, say, "I am just going to transfer this call to my director." Not our director. My director. We had grown fast - from ten employees to fifty or sixty in a few months - and somewhere in that growth, people had stopped thinking of the company as a team. It became "us and them."

The name "We" came from that realisation. It is inclusive. It promotes collaboration, not just communication. It makes people think of a company as a single force rather than separate departments. That is exactly what a unified communications platform should do. We paired it with UC - unified communications - and We UC was born.

What started as building a custom proposition for circle.cloud turned into something much bigger. We hired more developers. We set up sprints, CI/CD pipelines, infrastructure, DevOps processes. We registered We UC Ltd. We built native iOS and Android apps, a desktop app, a web app. We now have a team of over twenty people.

We became a software company almost by accident. And I love it.

What We UC Is

We UC is a modern business phone system. A unified communications platform that handles calls to telephone numbers via audio, internal calls via audio or video, messaging, meetings, call reports, and analytics - all in one application.

The basics are now solid. We are on par with our previous platform in terms of features and stability, and we are onboarding customers. One recruitment business is already running on We UC, with more to follow.

But the basics are just the foundation. What excites me is what comes next.

We are building customisable dashboards that do not just display telephony data but pull in information from CRMs, support systems, and accounting platforms - a small business BI tool that gives founders a 360-degree view of their operation in a single screen. We are building voice AI agents that sound human, connect to business systems via MCP servers, and can handle tasks like restaurant bookings or appointment scheduling. We are building omnichannel messaging that brings WhatsApp, email, Facebook Messenger, and Google My Business conversations into a single interface alongside internal chat.

These are not features for the sake of features. They are tools that will genuinely impact small businesses' efficiency and profitability.

Enterprise companies have had this technology for years - data warehouses, Power BI, AI assistants, omnichannel support. Small businesses are still logging into six different platforms every morning and lack a centralised view of their data and operations. I want to change that.

That is the real answer to why I built this. Not because someone asked. Because someone should have. As Steve Jobs put it: "People don't know what they want until you show them."

What I Have Learned

Five years of building something nobody asked for has taught me a few things.

Follow your gut, even when the economics say otherwise. Every major decision I have made - leaving my first job to start circle.cloud, moving off Broadsoft, investing in our own infrastructure, choosing to build from scratch on Kazoo - looked questionable on a spreadsheet. Every single one turned out to be right.

Control your stack. When something goes wrong and your service runs on someone else's network, on someone else's software, on someone else's servers, you cannot fix it. You can only wait. That is an unacceptable position. The buck has to stop with us.

Building it yourself takes longer but lasts longer. We could have hired consultancies to build everything and moved faster. Instead, we learned Kazoo ourselves, hired expertise in-house, built the knowledge internally. It took more time. But now we own every layer of understanding, not just every layer of technology.

Craft is not a luxury. We care about details nobody will ever see. The architecture of the codebase, the elegance of the API, the precision of the UX. That care comes through in the final product, even when the customer cannot point to exactly why it feels different.

You do not need permission to build what you believe in. Nobody asked for We UC. The market did not demand it. A consultant would have told me to keep reselling. But the best products are built by people who see something that does not exist yet and refuse to accept that gap.

Kazoo itself is open-source software, and we are actively contributing back to it - working alongside carriers from all over the world, maintaining a shared codebase. That is the beauty of open source. You build on something great and make it greater. But for us, Kazoo is just the PBX engine. On top of it sits everything from messaging to video calling, online meetings, call recording transcription and summarisation, and much more - all wrapped around a user experience that is entirely ours.

The Road Ahead

I have no plans to sell We UC. I want to build it and keep building it. That is what I enjoy doing.

We are launching in the UK first, then the US, Europe, and potentially Australia. We are selling through circle.cloud's existing sales engine and, soon, via a self-service SaaS model - which is entirely new territory for me and genuinely exciting.

I want We UC to become a recognised name in unified communications. Not because it is the biggest, but because it is built with more care, more craft, and more attention to detail than anything else in the market.

That is what five years of building something nobody asked for has given me. Not just a product, but a conviction: the things worth building are rarely the things that make obvious sense at the start. They are the things you cannot stop thinking about. The things that keep you working not because you have to, but because you genuinely want to.

And I have never wanted anything more.

We are told that beauty is subjective. In the eye of the beholder. That there is no right or wrong.

But is it? Because nature does not seem to think so.

Look at a shell. Look at the spiral on it. Now look at the spiral of a galaxy. They are the same shape. That is not a coincidence. What makes a face beautiful? Symmetry - one side mirrors the other. What makes a flower beautiful? The geometry, the way the petals are arranged. What makes great architecture? The way the shapes and the sizes complement each other.

These are mathematical patterns. And they keep showing up across nature, across history, across everything we find beautiful.

Beauty has structure. It is not random. And two things arrived in the same week that gave me the language for something I have felt my entire life but never quite managed to put into words.

The first was Paul Graham - the founder of Y Combinator, one of the sharpest minds in technology - resharing an essay he wrote in 2002 called Taste for Makers. I read it and sat quietly for a minute afterwards, because someone had articulated the idea that taste is not preference. It is real, it is identifiable, and it is a skill that can be developed.

The second was the Steve Jobs Archive publishing a collection called Letters to a Young Creator. Over thirty letters from the people who knew Steve, worked alongside him, were shaped by him. Released on what would have been his 71st birthday. And Jony Ive - the man who designed the iPhone, the iMac, the iPad alongside Jobs for fifteen years - wrote a letter about what it actually means to care about making something beautiful.

Together, they point at something I think is the most important conversation happening in technology right now. Not about tools. Not about speed. About what we believe the people who use our work actually deserve.

The Comfortable Lie

We are told from childhood that taste is personal, subjective, that there is no right or wrong.

It sounds generous. It sounds democratic. But it is a comfortable lie we tell each other to avoid conflict.

Graham opens his essay with a question that sounds almost naive: is there such a thing as good taste, or is taste just personal preference? And then he answers it in a way that stopped me cold. He says if taste were just preference, then everyone's taste is already perfect. There would be no way to get better at designing things. No direction to improve towards. But we all know that is not true. We know when we are looking at something genuinely beautiful versus something that has just been assembled. We feel it. We just lack the confidence to trust that feeling.

And then he goes further. He identifies the principles that keep appearing across every field - mathematics, architecture, painting, writing, engineering. Simplicity. Symmetry. Resemblance to nature. As if beauty is not subjective at all. As if there is a deeper truth to it that transcends medium and era and culture.

Steve Jobs believed it too. He famously said that Microsoft had no taste. People thought that was arrogant. But I do not think he was being cruel. He was being precise. He was saying: they do not ask whether something is good - they ask whether it works and whether it sells. Those are not the same question.

Taste is the ability to know the difference.

The Bull

For me, Picasso is the most powerful illustration of what simplicity actually means.

In 1945, he made a series of eleven lithographs called The Bull. He starts with a detailed, realistic bull - muscular, anatomically complex. The kind of drawing that makes you think: this person can really draw.

But then - over eleven iterations - he strips it. Removes muscle. Removes shadow. Removes everything that is not essential. Until at the end he has five or six lines. And those lines contain the entire essence of a bull - the power, the weight, the character - more completely than the detailed version ever could.

That process - that brutal, disciplined act of subtraction - is what decades of mastery actually earns you. Not the ability to add more. The ability to know what to take away. The confidence to take it away. And the skill to make what remains feel not sparse, but complete.

Graham makes the same observation across fields. In mathematics, a shorter proof is a better proof. In writing, say what you mean and say it briefly. In architecture, beauty depends on a few structural elements, not a profusion of decoration. Good design uses symmetry. Good design resembles nature. And good design looks easy - even though getting there is incredibly hard.

Most people think simplicity is the easy option. That minimalism is about doing less. It is the opposite. Simplicity is the hardest version of the thing - the version where there is nowhere to hide. Where every single element has to earn its place.

That is what Jobs did to the phone. That is what Ive did to every product they made together. And it is no coincidence that Ive's greatest influence was Dieter Rams - the German designer whose philosophy fits in three words: less, but better.

Protecting What Is Fragile

Ive's letter from the archive is not what you might expect. He does not talk about products. He barely mentions the iPhone or the Mac. He talks about how Steve thought. He says: "The way he thought was profoundly beautiful." He describes Jobs's curiosity as "ferocious, energetic and restless" - not limited by his knowledge, not casual or passive, but practiced with intention and rigor.

And then he writes something I keep coming back to: "Ideas are fragile. If they were resolved, they would not be ideas - they would be products. It takes determined effort not to be consumed by the problems of a new idea."

We live in a world obsessed with shipping. Validate fast. Move fast. Get feedback fast. There is wisdom in that. But there is also a kind of violence in it if applied too early.

There is a moment in the creative process where an idea is alive but not yet strong enough to survive scrutiny. It exists as a feeling, a direction, an instinct - before it has the language or form to defend itself. Expose it to criticism too soon and you kill it. Not because the criticism is wrong, but because the idea has not had time to become what it could be.

Jobs and Ive understood this. They spent their afternoons in what Ive calls "the sanctuary of the design studio." Protected space where ideas could evolve before they were tested.

I think about this in my own work building We UC. There is constant pressure to ship, to show progress, to validate early. That pressure is mostly healthy. But I have also killed ideas by letting the committee into the room before the thing had legs. The skill is knowing when something needs protecting and when it needs testing. I am still learning that.

Graham says great design is redesign. Leonardo's drawings often show five or six attempts at a single line. The Porsche 911 only emerged from the redesign of an awkward prototype. First answers are almost never the best answers.

Taste as Love for the Craft

Tim Cook's letter describes the moment he decided to join Apple. The company was struggling. Most people thought it would not survive. Then he heard Steve speak.

Cook writes that when Jobs spoke, "any trepidation I harboured instantly dissolved." Not because Steve had a perfect plan. Because he had complete clarity of purpose. Cook says he had never met someone with so much passion and vision. And he says he traded a job for a purpose the day he joined.

That distinction matters. A job is a set of tasks. A purpose is a reason. People will do extraordinary things in service of a genuine reason in a way they never will for a task list.

And I think that is what taste really is. It is not snobbery. It is love for the craft. It is caring so deeply about what you are making that you refuse to accept anything less than beautiful. Not because you want to show off. But because you believe the person on the other end deserves it. And because you want to apply your own style to it - to make it not just functional but uniquely, thoughtfully yours.

Ive understood this. He closes his letter with something I think is the most important line in all of this. He writes: "He truly believed that by making something useful, empowering and beautiful, we express our love for humanity." And then: "My sincere hope for you and for me is that we demonstrate our appreciation of our species by making something beautiful."

That is not a design philosophy. That is an ethical position. When you choose the good-enough option - the it-works-so-why-bother option - you are making a choice about how much you value the person on the other end.

Why This Matters Now

I do not think this is just a conversation about Apple or Picasso or Dieter Rams. I think it is the most urgent conversation in technology right now.

Because we are drowning in output. AI can generate volume. It can generate competence. What it cannot generate is taste - the love for the craft that makes someone obsess over getting something right. The intolerance for ugliness that comes from a person who has stared at their work long enough to hear the voice that says: there must be a better way.

That voice is the thing. Not the tools. Not the frameworks. Not the ability to produce faster and cheaper. The voice. The one that looks at something functional and says: this is not good enough.

Graham wrote his essay twenty-three years ago. Before the iPhone. Before AI could write code or generate images. Every word is more relevant today than when he wrote it. Because the cheaper it becomes to produce things, the more valuable taste becomes. When anyone can generate output, the differentiator is whether someone cared enough to make it right.

Nature's ratios. Simplicity. Symmetry. These are not trends. They are truths. Picasso's five-line bull took a lifetime to earn. Jobs spent decades obsessing over details most people would never notice. Dieter Rams designed products in the 1960s that still look contemporary because the principles underneath them are true.

The world does not need more output. It needs more people who refuse to accept that good enough is good enough. People who understand that simplicity is not the absence of effort but the highest expression of it. People whose taste comes not from judgement but from genuine love for what they are making and genuine respect for the people experiencing it.

I still get this wrong. I still ship things I know could be better. But I never stop hearing that voice. And the message I take from all of this - from Graham, from Ive, from Jobs - is: do not explain it away. Cultivate it. It is the most valuable thing you have.

I get some version of this question almost every week from founders and business owners: "What AI tool should I actually be using?"

Two years ago the answer was simple. ChatGPT. That was it. Start there.

Today the honest answer is: it depends what you are trying to do. Because the landscape has fractured into something much more interesting - and much more useful - than a single chatbot. There are now distinct layers to the AI world, each built for a different kind of work. Once you understand how those layers map together, the noise disappears and you can start making smart choices about where AI fits into your business.

Here is my attempt at a clear-headed overview of where everything stands in early 2026.

The Thinking Layer: Chat Models

These are the tools most people mean when they say "AI". You type something in, they respond. They can answer questions, draft documents, summarise information, help you think through a problem, translate, analyse, and much more.

The main ones worth knowing:

ChatGPT (OpenAI) - The one that started it all. Now on GPT-5. Still the default starting point for most people and for good reason - it is capable, versatile, and has the widest range of integrations. If you only use one tool, this is still a reasonable choice.

Claude (Anthropic) - My preferred tool for anything involving nuance, long documents, or careful reasoning. It handles large amounts of text particularly well and the responses tend to feel more considered. It is also the model that powers Claude Code, which is what I use for building software.

Gemini (Google) - Google's model, and it is genuinely excellent. Deep integration with Google Workspace means if your business runs on Google Docs and Gmail, Gemini is worth paying serious attention to. It will shortly become the engine behind a revamped Siri, following Apple and Google's recently announced partnership.

Grok (xAI) - Elon Musk's model. Good for current events, strong on real-time information if you are on X (Twitter). Useful if you want a less filtered perspective on things.

Perplexity (Sonar) - Less of a chatbot, more of a research engine. It searches the web, cites its sources, and gives you factual answers with references. If you need to research a topic quickly and trust the results, Perplexity is excellent.

The honest truth about all of these: the gap between them is narrowing. Two years ago ChatGPT was clearly ahead. Today they are all capable. The differences come down to specific strengths, interface preferences, and integrations. Do not spend weeks agonising over which is "best". Pick one, use it daily, and your instinct for when to try a different one will develop naturally.

There are also a handful of others worth being aware of - Llama (Meta's open-source model, free to use), Mistral (French company, good for European data privacy requirements), and DeepSeek (Chinese model, impressive capability at low cost) - but for most founders these are secondary considerations.

The Enterprise Layer

Beyond the consumer chat tools, several models are built specifically for businesses and platforms.

Microsoft Copilot is built directly into Microsoft 365 - Word, Excel, Outlook, Teams. If your business runs on Microsoft, it is worth exploring. In terms of raw capability it is largely built on OpenAI's technology, so the intelligence is familiar. The value is the integration.

Amazon Nova integrates natively into AWS. If you run applications on Amazon's cloud infrastructure and want AI capability inside those applications, Nova removes the need to call external APIs. For developers building on AWS, this matters.

Cohere builds models for businesses that need AI embedded into their own products - think a company that wants to search through its own internal documents intelligently. Their technology converts text into numerical patterns that a computer can search through by meaning, not just keywords. Relevant if you are building a product that needs that kind of capability.

Apple: The Interesting Exception

Apple's situation deserves its own section because it says something important about where AI is heading.

Apple entered the AI race with "Apple Intelligence" - an on-device model focused on privacy. The pitch was that your data stays on your device rather than travelling to a server somewhere. A good idea in principle.

The problem is the delivery mechanism: Siri. And Siri is, to put it plainly, not good. Compared to what Google Assistant or ChatGPT can do, the gap is significant. Apple has lost ground here, and recently confirmed it by announcing a partnership with Google to power the next generation of Apple Intelligence with Gemini models.

There are two ways to read this. Either Apple has been left behind and is outsourcing the hard problem. Or - and this is the argument I find more convincing - Apple is doing what Apple has always done: waiting for the market to mature, then using its advantage (the device, the interface, the integration, the trust) to deliver a superior experience on top of a commoditised engine.

The second argument points to something true about where AI is heading. The model itself is becoming less important. The experience around the model is what will matter.

The Building Layer: Coding Tools

This is the area I have personal experience with and it has moved faster than almost anything else in AI.

I remember using GPT-3.5 for code. It was rough. Useful for small problems, unreliable for anything serious. GPT-4 was a meaningful step forward. Then something shifted.

When I switched to Claude Code - Anthropic's purpose-built coding tool - the quality of the code being generated was, in my experience, roughly five to ten times better. Not a small improvement. A fundamental change. The reasoning was more accurate. The code actually worked. The back-and-forth felt more like working with a capable developer than prompting a machine.

There are now two broad paths for founders who want to build something with AI:

Purpose-built tools (Bolt, Replit, Lovable, V0 and others): You go to a website, describe what you want, and start building immediately. No server setup. No technical knowledge required. These are excellent for getting an idea off the ground quickly. The limitation is cost - serious usage burns through credits fast - and control. If you want to build something substantial and scalable, you will hit ceilings.

Raw coding tools (Claude Code, Cursor, Codex): You write and edit code directly, with AI assisting the process. More setup required. You need to think about where your code lives and how it gets deployed. But the control is orders of magnitude greater and the long-term economics are much better.

OpenAI also has a tool called Codex worth knowing about. I ran an experiment: I gave the same detailed product specification to both Codex and Claude Code simultaneously. Claude Code came back within ten minutes with a base structure that needed significant further development. Codex spent three to four hours building - on its own, without any back-and-forth - and came back with something considerably more developed. I used Codex's output as the foundation and then continued building with Claude Code for day-to-day development.

If you are building a serious application, my recommendation is Claude Code or Cursor for ongoing work. Codex is worth knowing about for the initial heavy lift.

Tools like Devin and Manus operate at a higher level still - they are AI agents specifically built for engineering tasks. Devin is particularly good at structured, clearly defined work. Manus is more of a generalist agent that can handle a wider range of knowledge tasks beyond just coding. Both are impressive. Neither has yet achieved the mainstream adoption of Claude Code for day-to-day use.

The Doing Layer: Agents

This is where things get genuinely interesting - and where most founders are underestimating what is coming.

An AI agent is not a chatbot. A chatbot responds to questions. An agent does things. You give it a goal, it breaks that goal into smaller tasks, executes them - often in parallel, often across multiple tools - and delivers a finished output.

The clearest practical example: Claude Cowork, launched in January 2026, lets you give Claude access to a folder on your computer and describe an outcome in plain English. It then reads files, creates documents, organises folders, cross-references information, and delivers finished work. Not a draft. Actual finished work. In a test, it reorganised a 500-file Google Drive, created logical folder structures, renamed files consistently, and flagged duplicates in under ten minutes. A task that would have taken several hours manually.

ChatGPT's equivalent, Agent Mode, launched four days later. Its approach is different - rather than working with local files, it gives ChatGPT access to a virtual computer in the cloud where it can browse the web, fill in forms, book things, and execute tasks across multiple websites.

The practical distinction: if your work involves files and documents, Claude Cowork is ahead. If your work involves web-based tasks, ChatGPT Agent Mode is stronger.

Google's version, called Project Mariner, runs as a browser extension and can handle multiple tasks simultaneously. One distinctive feature - you can demonstrate a workflow to it once and it learns to repeat it. Useful for recurring tasks.

Underlying all of this is an open standard called MCP (Model Context Protocol), introduced by Anthropic in late 2024. Think of it as a universal connector - like USB-C, but for AI. It allows any AI model to connect to any external tool (your calendar, your CRM, your database, your files) without custom coding for every connection. This is the infrastructure layer that makes agents genuinely useful rather than isolated demos.

The shift from "AI answers questions" to "AI does work" is not incremental. It is a different category of tool.

The Creative Layer

A brief tour through the areas beyond text and code:

Images: Image generation has matured significantly. All the major chat models now generate images competently from a good prompt. Specialist tools like Midjourney remain strong for high-quality creative work, but the barrier to entry for business use cases is essentially gone.

Voice: This is moving quickly. Companies like ElevenLabs, Vapi, and Cartesia are building voice AI that sounds increasingly human. The combination of voice AI with tool connections (via MCP) means you can now have a spoken conversation with an AI that can take real actions - booking appointments, updating records, managing calls. This is why we are building Ringup into We UC: a voice AI layer that allows our customers to create call flows combining human agents and AI agents, without stitching together third-party systems.

Music: Suno has been the category leader for AI music generation. ElevenLabs, primarily a voice AI company, has entered the space and the quality of what they produce is genuinely impressive. AI-generated music is already appearing at scale on YouTube and Spotify. Artists are using AI to produce music in styles and genres they would not typically work in.

Video: Consumer video generation has arrived. Sora 2 (OpenAI) generates up to 20-second clips and can incorporate your own face and likeness. Google's Veo 3 is similarly capable. Tools like Kling and Pika do strong image-to-video animation. For more professional work, Runway offers editorial control and character consistency. For production-level work, tools like ComfyUI (used by VFX studios), Autodesk Flow Studio, and Topaz Video AI handle the complex tasks. About 70% of films now involve AI tools at some stage of production.

What This Means

The picture that emerges is not chaos. It is a stack.

At the base: thinking tools (chat models) for reasoning, drafting, analysis.
Above that: building tools (coding AI) for creating software and automations.
Above that: doing tools (agents) for executing multi-step work autonomously.
Alongside all of it: creative tools for images, voice, music, and video.

The question is not "which AI tool should I use?" The question is "which layer of work am I trying to accelerate?" Once you frame it that way, the right tool usually becomes obvious.

The founders who understand this map will make better decisions faster than those who are still treating AI as a single thing. That gap is widening every month.

If you want my framework for running a founder and CEO business at full capacity, it is free at axelmolist.com/ceo-os.

There is a question I keep circling back to as a parent. What kind of childhood produces a driven adult? Is it one where things are lacking - where the hunger to achieve is born from scarcity? Or is it one where everything is available - where the child can focus on meaning rather than survival?

I do not have the answer. But I have two data points. My childhood, and my son's.

Christmas in Spain

I was born in 1988 and grew up in Lloret de Mar. My childhood was the 90s - Cartoon Network, the children's channel on satellite, and a house where technology was something you admired from a distance.

I remember one Christmas - I must have been five or six. There was a big box under the tree. I had been asking my parents for months to get our satellite connection back. We had lost access to the children's channel when our borrowed Sky viewing card expired. A friend of my parents in the UK had lent them one, and it only worked for a few months.

I was certain this box was a satellite receiver. I kept saying it. "It's the children's channel. It's the children's channel."

It was not the children's channel.

It was a music system - one of those integrated units. Cassette deck at the bottom. Tuner in the middle. Vinyl record player on top. Two speakers at either side. A proper piece of equipment for a five-year-old to receive.

The initial disappointment lasted about ten minutes. Then something else took over.

The Speakers

I became obsessed with that music system. I wanted to understand how it worked. I wanted to connect more speakers to it. My parents had old speakers lying around the house - mismatched, dusty, left over from other devices. I grabbed them all and wired them up.

My logic was simple: more speakers, more volume. Double the speakers, double the sound.

My father told me it does not work like that. I asked why.

That question - why - sent me down a path that lasted years. By the time I was nine or ten, I had taught myself about resistance levels. 4 ohms versus 8 ohms. What happens when you chain speakers together. The fact that you need an amplifier to drive them. The wattage dictates the power. It does not matter how many speakers you connect to the same amplifier - the power stays the same.

I did not know it at the time, but that one gift was an early education in electronics, in power, in how things work. It opened a door that led to everything I built afterwards.

By twelve or thirteen, I had constructed a mini disco in my bedroom. Coloured light bulbs screwed onto a pole. A relay system that controlled the lights. I programmed the relay to accept audio input from an old Yamaha keyboard with a built-in drum machine. The frequency of the signal pulsated the lights. I had a light show running off a keyboard and a relay system.

I got electrocuted a few times. It was worth it.

Two Childhoods

My son turns eight next week. His childhood looks nothing like mine.

He got his first iPhone when he was two - not to watch YouTube, but to play games and learn how the device worked. It was an old phone of mine that happened to still have an active SIM card. That SIM is now his number.

He started on YouTube Kids, which provides safeguarded content for younger children. Around six, when he got into Roblox, he and his friends started watching gaming videos on the main YouTube app. He asked if he could switch. I agreed, with boundaries: mostly long-form content, and he should try to learn something from what he watches rather than consuming it purely for entertainment.

The problem I now face is that the YouTube algorithm pushes shorts relentlessly. You cannot use the app without being served short-form content. I have not found a way to disable it. And he is watching more shorts than I would like.

I am aware of what is coming. Instagram. TikTok. Platforms that make YouTube shorts look restrained. I cannot police what he watches every minute of the day. All I can do is hope that the framework I have given him - the ability to distinguish between content that teaches and content that numbs - holds when I am not in the room.

The Content Problem

When I was a child, brain rot was the children's channel. That was it. The internet did not exist. If I wanted to learn something, I had to open the physical encyclopaedia and hope the entry covered what I needed.

Now, brain rot is infinite. YouTube shorts. TikTok. Split-screen videos where one side shows facts and the other side shows someone cutting wood - two entirely separate topics designed to double the retention factor. The people creating these videos are not interested in providing value. They are interested in attention. Attention is the currency. YouTube pays for it. The incentive is retention, not education.

This means the content my son is exposed to is not vetted for quality. It is optimised for dopamine. And the quantity of it in production right now compared to what existed in the 90s is staggering.

The AI Question

And then there is AI. My son uses ChatGPT almost as much as I do. He asks it questions about everything. He gets answers immediately - articulate, confident, detailed answers.

This raises a question I think about often. If the answer to everything is a prompt away, what happens to the work ethic of learning? Is there a need to retain information? Is there a need to know what the capital of Uganda is when you can ask a machine and get the answer in a second?

I think there is. Knowing things - geography, history, how the world works - gives you a lens to view the world through. Your own lens. Not one filtered through an AI that assembles an answer from patterns in data. The danger is subtle: kids do not know that AI makes mistakes. The answers sound confident. Confident-sounding answers feel correct. But ask ChatGPT how many Rs are in "strawberry" and you will see that machines make errors humans do not.

On the other hand, if ChatGPT and YouTube had existed when I was a child, I cannot imagine what I would have done with it. The access to information. The ability to learn anything, immediately. The sheer volume of opportunity. I would have tried different things, explored different ideas, possibly built different things entirely. Or maybe I would have just asked the AI to build it for me, and never learned how anything worked. It is an interesting conundrum.

The Money Question

The final piece I keep turning over is money.

I grew up in an environment of slight scarcity. We were not in need, but we were not well off. I remember my father picking me up from school in a 1988 Volkswagen Golf when it was 2002 or 2003. A fifteen-year-old car. My friends at school called it a coffee machine. I was a little embarrassed, but my dad was proud of it. Deep down, I thought it was a good car. Old, but good.

When it was finally time to replace it, my father looked at an Audi A3. Too expensive. He went with a secondhand Seat Leon instead. He still has that car today, twenty years later.

My family never splashed money. We were conservative. Maybe it is the Catalan in him - there is a custom, rightly or wrongly attributed, of Catalans being careful with money. Or maybe it was simply that abundance was never available.

The one time my father did spend freely was in 2008, when his business had a strong year. I had always wanted a recording studio. We spent maybe fifteen or twenty thousand euros converting the top floor of our house - soundproofing, equipment, the lot. The timing was imperfect because I moved to the UK that same year. But the studio got built.

My parents never bought me a Game Boy. Never bought me a game console. I never asked twice because I was already occupied - connecting speakers, building light shows, experimenting with electronics.

And that brings me to the question that sits underneath all of this.

Hunger

If you are brought up in an environment where nothing is lacking, does it make you hungry? Does it drive you to achieve? Or does it make you comfortable - content with what is available because effort was never required to obtain it?

I have seen both outcomes. Friends whose parents had money but did not give enough attention. Those friends have not achieved much with their lives. They are not worried about it either. That is the part that concerns me.

We are here to make an impact. To leave something behind that mattered. If we do not achieve that - if we do not improve the lives of the people around us in some meaningful way - what was the point?

That is what gives me meaning. But will my son share it? Will the presence or absence of financial pressure shape whether he develops the drive to build something of his own?

I do not know. Nobody does.

What I know is that a five-year-old boy opened a music system on Christmas morning and spent the next decade learning how sound, electricity, and engineering worked - not because anyone told him to, but because the curiosity was there and the constraints forced him to figure it out.

The question I carry as a parent is whether curiosity still ignites in a world where the answers arrive before the questions are fully formed.

There is a theory that the cost of almost everything is heading toward zero. Energy. Goods. Services. Software. And I think there is truth to it.

Not that things will literally be free. But that we are entering a period of such abundance that the cost of creating, delivering, and consuming drops so dramatically it changes everything. We are already living in an abundant world. What is coming is excessive abundance - where anything you need is available to you at any moment.

And I have seen enough over the past few years to believe this is not far off.

The Energy Equation

Start with energy. If energy gets cheap enough, it changes the cost structure of everything downstream.

Nuclear fusion - the safer, cleaner version of nuclear power that does not produce long-lived radioactive waste - is making genuine progress. Unlike fission, which is what current nuclear power plants use and comes with the risks of chain reactions and waste storage, fusion is inherently safe. The reaction cannot run away. It simply stops when conditions are not right.

Combine that with solar. Not just panels on rooftops, but solar panels in space. Japan has already demonstrated the concept - generating electricity in orbit and beaming it back to Earth using lasers and microwaves. Companies like Aetherflux and StarCatcher are planning commercial demonstrations this year.

Space-based solar captures sunlight 24 hours a day with no weather interference. If you can transmit that power efficiently to ground stations, you unlock a fundamentally different energy equation.

When energy becomes cheap and abundant, the cost of manufacturing drops. The cost of transport drops. The cost of computing drops. Everything sits on top of energy.

The Physical World Catches Up

Think about where we are right now with delivery and convenience. If you live in a city and need something - a shaver, a phone charger, anything - you can open an app and have it at your door in under an hour. I have experienced this in Dubai, where the service is a step more evolved. Delivery comes to the door of your flat, through your apartment block, straight to you.

We consider this impressive now. But fast forward five years.

Drone deliveries. Self-driving vehicles. And robots - which sounds science fiction, but the technology is already here.

Physical AI is what this is called. Robots that use artificial intelligence to navigate the real world. They see through cameras. They process their environment in real time. They make decisions the way a human would, but faster and without fatigue.

I was recently in Miami and had my first experience in a self-driving car. The car was parked on a busy road. The driver - or rather the person in the driver's seat - entered the address. And the car manoeuvred out of the parking space, joined the main road, and navigated itself for twenty minutes through busy streets and highways.

It handled everything. A cyclist - moved around it smoothly. A bus pulling in - indicated and overtook. A car ahead going slowly with no indication of what they were doing - the self-driving car waited, assessed the situation, then safely changed lanes and continued.

It was impressive. Not in a gimmicky way. In a genuinely functional, this-is-the-future way.

The Camera Question

There is a debate in autonomous driving that I find fascinating. Tesla has bet everything on cameras and software - no lidar, no radar sensors. Their approach is to make the car see the way a human does, using neural networks to interpret visual data.

Other manufacturers like Waymo have gone with cameras plus sensors - lidar, radar, and other hardware. A belt and braces approach.

I understand the logic of the software-only bet. If you write great software with strong neural networks, you have an advantage. The cost of manufacturing is lower with cameras only. And in theory, if humans can drive with just vision, machines should be able to as well.

But there is a practical concern I keep coming back to. Visibility.

In rain, snow, or mud - what happens? Humans can wipe their eyes. We can put the windscreen wipers on. We maintain our own visibility. But a camera covered in water droplets or mud cannot do that by itself. Tesla has heat pads around cameras to melt snow, but heavy rainfall or mud is a different challenge.

Maybe nanotechnology solves this. Maybe self-cleaning coatings become standard. But until then, I suspect self-driving will require clean cameras to engage - and getting out to wipe your cameras down is not exactly the seamless future we are imagining.

These are solvable problems. But they need solving before autonomous driving becomes truly ubiquitous.

The AI Revolution I Have Lived

What excites me more than any single technology is artificial intelligence. Because I have experienced its impact firsthand.

In November 2022, when ChatGPT launched, something unlocked for me. I had always been the person who wanted to figure things out. When our phone system at circle.cloud lacked a built-in dashboard, I wanted to build one. I knew we had shell access to the MySQL database. I spent hours on Stack Overflow learning how to write queries to extract the data I needed.

But I did not have a tool where I could simply describe what I wanted and receive the exact query in response. That tool did not exist.

When GPT arrived, it gave me exactly that capability. I could describe what I needed in plain text and get back working code. It was a breakthrough.

That led to writing shell scripts - something I had always wanted to do but never properly learned. Which led to something bigger.

We had a longstanding problem in our business. Our telemarketing team books appointments for field sales people, and those appointments need to be logistically viable - no more than an hour's drive between meetings. With seven field sales people, managing this manually was becoming unworkable.

So I built The Scheduler. I started by writing a script that used the Google Maps API to calculate drive times between postcodes. When that worked, I thought: can I turn this into an actual application?

Using ChatGPT and later Claude, I built it into a fully fledged app. Tens of thousands of lines of code. User management. Appointment workflows. Stripe integration for payments. A self-service website at scheduler.so where customers can sign up, start a free trial, and be operational in minutes.

I did not write a single line of code myself. I cannot write code. I can read it, understand it, but my syntax would be wrong if I tried to write it from scratch.

The application was submitted to the Zoho CRM Marketplace. They spent two months reviewing it. They approved it. A fully vibe-coded application, built entirely with AI, accepted into a major CRM marketplace.

That is the moment I realised the scale of what is happening.

What This Means for Software

If a non-technical founder can build a production application from scratch using AI, others will do the same. People with ideas who previously lacked the funds or technical ability to implement them now have the capacity to create.

This is both exciting and disruptive.

I think the era of generic SaaS is ending. Software will become incredibly specific rather than broad. Purpose-built applications for precise use cases, rather than bloated platforms trying to serve everyone.

I was speaking to someone recently who wants to build a gym tracking app with a social network component. He did some market research before building anything and found someone had already built almost the exact same application with the exact same name he had planned to use.

That is not coincidence. It is a pattern. People who have carried ideas for years can now execute them. The flood of micro-applications is coming.

Tools like Salesforce will struggle in this new world. Not because they are bad, but because the economics of purpose-built software are fundamentally different when AI removes the development barrier.

And looking further ahead, I think applications could eventually be created on demand. Not immediately. But in the semi-near future, you might describe what you need and have a purpose-built tool generated for you.

The Convergence

What makes this moment unique is not any single technology in isolation. It is the convergence.

Cheap energy makes computing cheaper. Cheaper computing makes AI more powerful. More powerful AI makes software creation accessible. Accessible software creation drives an explosion of tools. Physical AI brings intelligence into the real world. Self-driving, robotics, and drone delivery reshape logistics.

Each of these feeds into the others. The compounding effect is what drives costs toward zero and abundance toward excess.

I am not claiming to have all the answers about where this leads. Nobody does. But I have built a production application without writing code. I have sat in a self-driving car that navigated city streets better than most human drivers. I have watched energy technology make progress that seemed impossible a decade ago.

The future is not something we are waiting for. It is something we are already living in.

The question is not whether these changes are coming. It is whether you are paying attention.

I went to a crypto conference in Miami and came back thinking about silver.

That was not the plan.

A friend from my Hampton group mentioned he was considering attending a gathering put together by Real Vision - a community and training programme run by Raoul Pal. I had been seeing Raoul's videos pop up on YouTube for years while researching Bitcoin. Long videos, but insightful commentary. I would put them on during workouts. When I learned he was behind this conference, I thought it was worth attending.

Miami was also somewhere I had wanted to visit for a long time. I had heard it was full of Latin culture, similar to Cuba - which I loved when I visited. When I arrived, everyone was speaking Spanish to me. It felt familiar in an unexpected way.

The conference ran for three days. Thursday afternoon through Saturday. Talks throughout about what is happening in the markets - crypto, macro trends, where things are heading.

I walked in interested in Bitcoin and alt-coins. I walked out thinking I need to invest in silver.

What I Expected to Hear

The conference started with what Raoul called the "drinks with Raoul Pal" session. He spoke about the state of crypto, interviewed people, discussed why alt-coins have underperformed this cycle.

The consensus was clear: Bitcoin is going up long-term. I believe that too. It is a store of value with limited supply. A hedge against inflation. The fact that it has no functionality beyond being a store of value used to concern me slightly - but then again, what functionality does gold have other than people wearing it around their necks?

But here is what caught my attention. Alt-coins have not had their peak this cycle. The money that normally flows from Bitcoin into alt-coins went somewhere else - into precious metals and tech stocks. That is unusual. Previous cycles saw that rotation happen like clockwork.

This year, Bitcoin peaked, crashed back to around $80,000, recovered to $90,000 - roughly where it started the year. The explosive alt-coin season everyone expected never arrived.

The question became: where did that money go instead?

The Silver Thesis

The biggest takeaway from the conference was not about crypto at all. It was about silver.

The argument is straightforward: the technologies shaping our future - solar energy, electric vehicles, artificial intelligence, 5G networks - all require silver. Not as a nice-to-have, but as an essential component. And supply cannot keep up with demand.

Let me break this down in terms that made sense to me as someone who builds software, not someone who trades commodities.

The Supply Problem

Silver has been in deficit for five consecutive years. More silver is being consumed than produced. The total shortfall from 2021 to 2025 is approximately 820 million ounces - roughly equivalent to an entire year of global mine production.

Here is why this cannot be easily fixed:

Seventy percent of silver production is a byproduct. Silver mostly comes out of the ground alongside copper, lead, and zinc. Mining companies make decisions based on those metals, not silver. Even if silver prices double, copper mine operators do not suddenly produce more silver. It is like trying to increase your website's database capacity by buying more office chairs - the two are connected operationally but not causally.

New mines take seven to ten years to develop. From discovery to commercial production, assuming everything goes smoothly with regulations and financing. There is no quick fix. You cannot spin up silver production the way you would spin up more cloud servers.

Ore grades are declining. The easy silver has already been extracted. Mining companies now process larger volumes of rock to get the same amount of metal. Costs rise. Marginal deposits become uneconomical.

The Demand Explosion

Industrial demand reached a record 680 million ounces in 2024. That was the fourth consecutive annual high. And it is accelerating.

Solar panels consume approximately 197 million ounces annually. Each panel needs 15-20 grams of silver in conductive paste. Global installed solar capacity is projected to more than triple by 2030 - from 2.2 terawatts to over 7 terawatts. The maths is simple: more panels, more silver.

Electric vehicles use 25-50 grams of silver per car - roughly double what traditional vehicles require. Battery management systems, power electronics, sensors. EV adoption is still in early stages globally.

AI infrastructure requires data centres with 2-3 times the silver content of traditional facilities. Higher power density, more complex cooling, more interconnections. Every percentage point of growth in computing demand translates to more silver.

Your smartphone contains 200-300 milligrams of silver. A laptop has 750 milligrams. Billions of devices manufactured annually, each containing small amounts that add up to significant demand.

The critical point: silver represents such a small fraction of the total cost of these products - typically 0.5-2% of a solar panel, for example - that manufacturers will pay whatever it takes to secure supply. A doubling in silver price barely moves the needle on installed system cost. This is price inelasticity. Demand does not decrease meaningfully even when prices rise.

Why Not Gold or Bitcoin?

Gold is a store of value. Central banks buy it. Investors hold it during uncertainty. But gold lacks the industrial demand driver that silver has. There is no exponential growth curve for gold consumption tied to technological transformation.

Bitcoin is speculative. I believe in it long-term as a store of value, but it has no physical utility. Its value rests entirely on network effects and adoption - reflexive dynamics where price appreciation attracts capital which drives further appreciation. That is a different kind of bet.

Silver sits at the intersection: a store of value with monetary history, plus irreplaceable industrial applications in the technologies defining our future. That combination is what makes the thesis compelling.

The Honest Counterargument

I would not be giving you the full picture without addressing substitution. This is where I spent additional time researching after the conference, because the bullish case seemed almost too clean.

Copper is already replacing silver in solar cells. China's Longi, the world's largest solar manufacturer, announced plans to mass-produce copper-metallised cells in 2026. Copper-based paste can reduce silver content by 50-90% while maintaining performance. Australian researchers have developed copper plating with protective silver or tin caps that prevents the oxidation problems that previously made copper unreliable.

Carbon-based materials are emerging in electronics. Graphene can carry nearly 1,000 times more current than copper. Carbon nanotube films are already manufactured at scale. Conductive polymers combined with minimal metal content achieve comparable performance for certain applications.

Thrifting works. Between the 1990s and 2017, the electronics industry reduced silver content in capacitors from 7 million ounces annually to 0.5 million ounces - a 93% reduction - while device production exploded. Engineers find solutions when economic incentives align.

This creates what I think of as a ceiling on silver prices. Above $75-100 per ounce sustained, substitution accelerates dramatically. Manufacturers who were content to pay silver premiums suddenly have compelling economic reasons to switch. Research programmes get funded. Alternative materials reach commercial scale faster.

The realistic view, incorporating substitution pressure: silver likely appreciates 2-4x from current levels over the next five years. Not the 10-15x scenarios some bulls project. Those projections require assuming substitution is impossible - and the evidence suggests it is merely difficult and time-consuming.

My Position

I attended this conference without any interest in precious metals. I was there for crypto insights. I left thinking silver deserves a place in my portfolio before additional Bitcoin or gold.

The thesis is not about getting rich quickly. It is about a structural supply-demand imbalance that takes years to resolve. New mines cannot be developed fast enough. Substitution is real but slow. Industrial demand is locked in by technology adoption curves that are already in motion.

I am not a financial advisor. This is what I learned, what I found compelling, and what I am personally considering. Do your own research. Understand the risks.

But if you are looking at where to allocate capital for the next five to ten years, and you care about tangible assets with genuine utility in the technologies shaping our future - silver is worth understanding.

I went to Miami for a crypto conference. I came back thinking about the metal inside every solar panel, every electric vehicle, every smartphone, every data centre powering the AI applications we are all building toward.

Sometimes the most valuable insights come from where you least expect them.

I have put together a simplified research document covering the silver investment thesis - the supply constraints, demand drivers, substitution risks, and key data points. If you want to understand this deeper, you can download it free at axelmolist.com/silver-cheat-sheet.

There is a gap in business that nobody talks about. On one side, brilliant engineers who can build anything but cannot hold a meeting without interrupting everyone. On the other, business people who sell technology they do not understand. Very few people bridge both worlds. I have spent the last decade learning to stand in the middle.

My name is Axel Molist Cordina. I grew up in a small tourist town in Spain called Lloret de Mar. I built a recording studio as a teenager, sold suits to nightclub bouncers at sixteen, moved to the UK for university, and ended up building a telecoms company from nothing to over a hundred people and nearly twenty million in revenue. No outside investment. No playbook. No safety net for most of it.

This is who I am and what I am here to do.

The Break

In 2012, I was working at a telecoms company in Southampton. They sold on-premise phone systems - big boxes that plug into walls, hardware that needs a comms room. But their customers were dentist surgeries, car garages, small solicitor firms. These businesses did not have comms rooms. The phone system ended up under a desk or bolted to a wall on the way to the toilet.

The problem was simple. Leasing companies wanted hardware. More equipment meant more finance, more commission. So the company kept selling the wrong solution because it made the most money.

I believe in selling the right solution to the customer, even if it makes you less money.

I found the answer. Cloud-based phone systems. No hardware. No comms room. Just internet. In 2012, that was not mainstream, but the technology was clearly better for these small businesses.

I went to the owners and said we need to sell cloud. They said no. Cannot lease it. Will not make as much money.

So I started building my own company behind their backs. Website planning, supplier conversations, all while still employed. But one of the suppliers I approached told my employer. They called me on my way home. Come back to the office. We know about it. We are very hurt. You have to go.

I regret doing it that way. I should have been upfront. But if I had told them, they would have probably got me to run the new company with them as shareholders. And I needed to steer the ship myself.

So I was out. No job. No salary. No safety net.

But I had a DJ set on Tuesday night.

Building Between Tracks

I DJ'd three nights a week. Tuesday, Friday, Saturday. Eight till three in the morning. Four hundred and fifty quid a week. Enough for rent, food, and maybe a meal out once a month.

When the club was not busy, I had my laptop open behind the decks. Playing a track on Serato, switching to the browser to build the website, switching to Excel to build the quoting workbook, switching to Google Docs to write the terms and conditions. Then back to Serato to play the next song before anyone noticed.

During the day, I sat in my spare room. A desk, a laptop, and a phone. Two hundred cold calls a day. I am not a natural salesperson. I had to learn it. I downloaded every sales audiobook I could find and listened to them driving to appointments. I sold with enthusiasm and technical knowledge, and people responded to that more than any technique.

A friend called Dan Woodham let me use his office in exchange for consulting on his business. Having somewhere else to make calls from was valuable. Being in an office with other people dialling out, a busy environment - that is much better than cold-calling alone from your spare room every day.

Appointments turned into deals. I closed around two hundred in the first three and a half years. At the beginning, I did all the telemarketing, selling, installing, billing, and supporting. After some time, I started hiring people.

You Cannot Buy Talent. You Grow It.

The real challenge is scaling without a budget. Everyone says hire people better than you. That is great advice if you can afford them. People who are better than you normally come with a price tag you cannot afford when you are starting with scraps.

So here is what I learned. Hire people based on attitude. Determination. Intelligence. Willingness to learn. Can you work with them? Can they do a good job? If yes - hire them, train them, show them everything you know, and ask them to go learn further.

Sometimes it works. Sometimes it does not. You identify when it does not and you move on. But sometimes you hit the jackpot.

Jordan, our Commercial Director, started with us as a telemarketer. He was meant to build a telemarketing team. Then he became a manager of managers. Now he is a board member. Katie started in customer service. Now she runs it and is right-hand to our Operations Director.

These people came in at entry level and grew with the company. That is the path when you are bootstrapped. You cannot buy talent. You grow it. And those early people - the ones who join because they believe in what you are trying to do - they are the ones who matter most. It becomes their business as much as yours.

The Gap Between Technology and Business

Through all of this, I started noticing something.

I have worked with brilliant engineers who cannot hold a meeting without interrupting everybody and not letting anyone finish their point. I have worked with business people who do not understand the technology they are selling - or do not know enough about technology to build a technology business. The owners of the company that sacked me would have kept selling the wrong solution forever if nobody technical had pushed back.

You also get founders who can build but cannot lead. Or founders who can lead but do not understand technology. The companies that succeed are the ones where someone in the founding team bridges that gap. Or somebody at a really senior level comes in early enough to be truly invested.

I sit at the intersection of technology and business. I can walk into a room of developers and understand exactly what they are telling me. I can also stand in front of a customer and explain why it matters. I have found that is not common. Most people are either on one side or the other.

That bridge is not a skill you acquire. It is a perspective you earn by doing every job in the company yourself. Telemarketing. Sales. Installations. Billing. Support. Hiring. Leading. Building software. Each one adds a layer of understanding that you cannot get from a book or a course.

What I Am Building Now

The company I built over the last decade is called circle.cloud. It is a telecoms solutions provider. We now employ over a hundred people. In 2019, I hired Graham - a great salesperson who pretty much single-handedly grew our turnover significantly that year. He is now circle.cloud's CEO. He runs the day-to-day.

I did that so I could focus on building software. We UC is a telecoms platform I am building with a team of twenty. From scratch. We are also building a suite of business productivity products around it. I believe in vertical integration - the more you control, the better the experience for the customer. I read the Steve Jobs biography, then Elon Musk's. Both obsessed with owning every part of the product. That really resonated with me.

But I will be honest. We UC is not where I want it to be yet. We have a long way to go. Is the product ready for market? Is it as good as I think it is, or is it just special to me? I do not have the answer yet.

But I keep building. Because the alternative is standing still or giving up. I do neither. My plan is not to sell these businesses. I want to make an impact over the long term with the technology and services we provide.

Why I Am Doing This

When we provide a solution to a customer and it genuinely improves their business - their efficiency, their bottom line, the way their team works - I get a feeling I find hard to describe. Something like satisfaction and determination and motivation all at once.

I want this content to create the same thing. If something I share helps you see a problem differently, or motivates you to take action, or helps your business run better - that is the whole point.

So why am I doing this personal brand thing? Same reason I am doing circle.cloud and We UC. To make an impact. Just in a different format. Through stories, through mistakes, through what I am working through right now.

This is for founders building from zero. Self-funded builders who chose the hard path. Technical people who can build but need to learn to lead. Business people who can sell but need to understand technology.

Creating software gives me the same feeling as when I used to make music as a kid. The same feeling as when we install a system that makes a customer's business run better. From making music to cold-calling contacts to building software to hiring a team of twenty to build more of it - the instinct has never changed.

See a problem. Create something to fix it.

That is the thread through everything I do. And that is what this content will be about.