Metro Bank had a good run.
Open on Sundays. Free tea. Dog treats. Staff who actually looked up when you walked in. For once, a UK bank didn’t feel like a punishment.
Then in 2025, I couldn’t link my Amex card 💀.
Turns out, they’d built a feel-good brand… but forgot to build a functioning bank.
And the second expectations weren’t met, people (like me) bolted.
So, if you’re building anything people rely on – payments, health, logistics – this is your lesson in what NOT to do.
Today, you’ll learn:
How Metro went from lovable to liability
Why surface-level wins won’t save a shaky stack
Scaling lessons every founder should be stealing
How invisible systems shape trust
Solid infrastructure > free dog biscuit
Firstly, I want to give credit where it’s due.
Metro genuinely brought something new to the table back in 2010.
They launched the first new high‑street bank in the UK in over 100 years – with seven-day opening hours, free coin-counting machines and real humans on the phone within three rings. Metro even hosted community events and kids’ money‑learning workshops, all while legacy banks cut staff and automated systems away.
But innovation never ages well. You have to keep building.
As the industry moved online, Metro poured cash into opening more branches and doubling down on in-person perks.
Ultimately, this was a big mistake:
2023 → £325m emergency rescue
2024 → £600m refinancing
2025 → takeover talks with Pollen Street Capital
They bet the bank on experience, not execution.
And when you can’t even carry out a basic function like linking an Amex, do you really think people are willing to stick around for the free dog biscuits??
💡 If you’re a business owner/operator, be warned: what sets you apart today won’t protect you tomorrow. Charm fades. Infrastructure scales. Invest in the parts no one sees, because that’s where trust is won (and lost).
Other banks didn’t care if your dog felt welcome…
Metro kept perfecting the customer service playbook. But the real challengers were focused on fixing the foundations.
Revolut built its infrastructure from scratch across Google Cloud and AWS. Every service – currency exchange, crypto, stocks – was designed to run independently, so the team could ship fast, test often and recover instantly.
Monzo took a similar route. From the start, it was cloud-native and API-driven. Its backend runs on 150+ micro-services, each one deployable on its own. That means faster updates, fewer outages and minimal reliance on manual processes.
Starling went even leaner. Their real-time ledger syncs everything instantly: balances, transactions, notifications. Support response times average under five minutes, and they run one ops person per 10,000 customers.
Dog treats may win over your Labrador, but not investors – and these three banks got that early and raised accordingly.
You don’t need a huge team to do the same. But if you’re designing a product people rely on, the backend is the product. Start there.
The backend is the brand… eventually
We see this all the time.
But under the surface? Systems that aren’t built to scale. It’s a pattern that’s played out again and again:
Fast burned through $120m chasing one-click checkout, but couldn’t keep the product working
Zilingo collapsed under governance issues and chaotic infrastructure after raising nearly $300m
Bulb became the UK’s biggest energy startup, then folded when it couldn’t handle market volatility or scale its systems fast enough
Each one raised millions. Each one fell apart when the backend buckled.
💡 If your backend can’t keep up, your growth will expose it. And when things start breaking, customers won’t wait around. They’ll move to someone who built it right the first time.
Too good to gate keep
While writing this, I thought of a book I read years ago: The Phoenix Project.
It’s a novel about IT and DevOps. Doesn’t exactly sound like a page-turner, I know… but it’s surprisingly gripping.
It also nails a hard truth: infrastructure issues aren’t just technical. They drag down everything – growth, support, delivery, trust.
Basically, Metro’s entire postmortem in 300 pages. Worth a read before the cracks start showing in your own ops.
If you do one thing this week, do this:
Ask whoever’s in charge of your infrastructure: What are the three riskiest dependencies in our stack?
If they don’t know, you’ve got a blind spot. And blind spots break businesses. It’s the kind of question I ask my CTO early (and often) at FundOnion.
You’ve scrolled this far, might as well see it through
I’ve built fast and broken things. Now I help others avoid the same mess.
If you’re raising, scaling or just tired of firefighting – I can share with you what actually works.
Share the knowledge and send these stories to anyone in your network who might benefit. Knowledge hoarded is knowledge wasted.
Reach me directly at [email protected].
Or just hit reply.
Till next time,
James