Profitable, Pragmatic, and Still Standing

I was supposed to give this talk at the Talent Arena during MWC Barcelona 2026, but personal reasons made it impossible at the last minute. A big thank you to the organizers for their understanding. I still want to share this content and hope to give the talk at a future edition. In the meantime, here’s the written version.

The Contrarian Weirdo

I’ve always been the contrarian weirdo.

When everyone loved soccer, I loved basketball. When it was Barça or Madrid, I followed Joventut Badalona. When everyone listened to commercial music, I went alternative. When everyone used Windows, I ran Linux.

And I actually liked it. Not in a “look at me being different” way. More like: the popular choice never felt right, and the unpopular one always seemed more interesting. I didn’t set out to be contrarian. I just kept ending up there.

Then I grew up and started building software. Same pattern.

When everyone wrote spaghetti code, I got into Ruby and design patterns. When microservices became the religion, I stuck with monoliths. When startups chased VC money to burn through, I preferred bootstrapping. When people declared Rails dead every six months, I thought Rails was perfect for what we needed.

Then I found a company that thought the same way. SeQura. A fintech in Barcelona that was quietly building a real business while everyone else was building decks for investors.

And for a long time, that contrarian instinct is exactly why we won.

The Rebellion

The Architecture Rebellion

Around 2016-2018, microservices were the religion. Every conference talk, every blog post, every “modern architecture” diagram had the same message: break your monolith into services. If you’re not doing microservices, you’re doing it wrong.

We kept our monolith. One Rails app. Ruby.

Why? Because we had five teams and one codebase, and that was a feature, not a bug. The alternative was five teams, twenty-five repos, twenty-five deploy pipelines, and distributed transactions to debug. We had real value to ship. The complexity of our domain was already high enough without adding network boundaries and eventual consistency between every business capability.

The microservices pitch always assumed you had the team size and operational maturity to justify the overhead. We didn’t. And honestly, most companies that adopted microservices early didn’t either. They just ended up with a distributed monolith and all the downsides of both architectures.

A monolith with clear internal boundaries gave us the speed of deploying one thing, the simplicity of one database, and enough modularity to keep teams from stepping on each other. It wasn’t sexy. It worked.

Profitable from Day One

The VC playbook in fintech was straightforward: raise money, burn it acquiring users, figure out unit economics later, raise more money. Growth at all costs.

We did none of that. Zero VC burn rate. No subsidized acquisition. No “we’ll figure out monetization later.”

This wasn’t some philosophical stance against venture capital. It was a practical constraint that became an advantage. When you’re not burning someone else’s money, you have to find product-market fit for real. Not “users are growing” fit. Not “engagement is up” fit. The kind where people actually pay you money because what you built is worth it. That’s a harder test, and it forces better decisions earlier.

The result became clear when the market turned. We survived when competitors with €90M in the bank didn’t. They had runway. We had revenue. Turns out, a business that makes money is more resilient than a business that spends money. Who knew.

Small Teams, High Trust, No Bullshit

At our peak efficiency, we had about 10 people at a table. Everyone knew everything. Context flowed naturally because you could literally overhear what the person next to you was working on.

Zero sprints. Zero story points. No ceremonies. The process was simple: here’s the problem, go solve it. If you needed help, you turned to the person next to you and asked. If you needed a decision, you walked to the person who could make it.

Seven engineers shipped a full product suite in 18 months. Not because they were superhuman, but because there was zero coordination overhead. No ticket grooming. No sprint planning. No standup theater. Just people solving problems.

This felt like a superpower. While other companies our size were debating Scrum vs Kanban and hiring Agile coaches, we were shipping. The lack of process wasn’t chaos. It was trust. We hired good people, gave them context, and got out of the way.

And It Worked

Revenue tells the story. €3M in 2017. €15M in 2019. Then it accelerated: €31M, €39M, €60M, €91M, €131M by 2025, and we are tracking toward €192M for 2026. All while staying profitable. All while growing the engineering team to over 125 people.

We thought we’d cracked the code. Monolith, small teams, no process, profitability. The contrarian playbook was winning.

Turns out, we’d just gotten lucky with our constraints. When you’re small, many things work by accident. Information flows because everyone’s in the same room. Decisions are fast because there’s only a few people to consult. Quality stays high because the person who wrote the code is sitting right there.

And luck doesn’t scale.

Then things stopped working.

The Reckoning

Somewhere between 60 and 100 people, the things that made us fast started making us slow. Not all at once. It was gradual. By the time we noticed, some of the damage was already done.

Some of what broke was inevitable growing pains. Some was us clinging to what worked at 20 people long after we’d outgrown it.

Communication Stopped Scaling

At 20 people, everyone sat at one table. Information was osmosis. You didn’t need meetings because you heard everything naturally. Someone mentioned a problem, someone else had the context, and by afternoon it was solved. No ticket. No Slack thread. No meeting.

Then we started hiring remotely. Then COVID made everyone remote. The osmosis didn’t just thin out, it vanished overnight.

At 100 people spread across different cities, the magic evaporated. Teams lived in silos. Different channels, different contexts, different priorities. No one knew exactly what we were building as a whole. Requirements got lost in translation. People going in different directions. Cross-functional stuff without ownership. Uncertainty was everywhere.

The worst part: we didn’t see it happening. We kept telling ourselves “we’re still small, we still talk to each other.” But the math doesn’t lie. At 10 people you have 45 potential communication channels. At 100 you have 4,950. You can’t brute-force communication at that scale. You need systems.

We didn’t have systems. We had nostalgia for when we were small.

(At 200 people? Ask me in two years.)

Management Theater Was Actually Necessary

Early on, we were proud of it. No unnecessary meetings. No status updates for the sake of it. No management theater. We’d built something lean and we wanted to keep it that way.

We did invest in process and communication. We weren’t naive. As we grew, we added the structures you’d expect: team leads, planning sessions, cross-team syncs. We tried to scale what we had.

But it wasn’t landing. The structures were there, the impact wasn’t. Some of it was growth outpacing what we’d built. Some of it was the profiles we’d hired: people who thrived in the early stage but struggled to operate in a larger org. And some of it was us, leadership, stuck between two bad options: wait for things to solidify and trust people to figure it out, or step in and risk killing the autonomy we’d worked hard to build.

Turns out, some of what we’d dismissed as “theater” is actually context-setting. When you’re 10 people at a table, everyone absorbs the strategy through proximity. When you’re 100 people across multiple teams, they need someone to stand up and say: “This is where we’re going. This is why. This is what matters this quarter.”

We did say those things. But too vague, too abstract, with too many open questions left in the room. Direction without clarity isn’t direction. It’s just noise with good intentions.

When the context is half-baked, 100 smart people still pull in 100 different directions. Not because they’re bad at their jobs, but because they don’t have what they need to make aligned decisions. The problem wasn’t that we had no process. It was that we couldn’t make it work, and that bled straight into how we thought about culture.

The Culture Trap

We prided ourselves on empowerment. We gave people the vision. Training budgets. A handbook. 10% time for personal projects. 20% of time to tackle tech debt. Autonomy to make decisions.

Then we expected them to fill in every gap on their own.

That’s not empowerment, that’s wishful thinking.

Real empowerment requires more than freedom. It requires context, boundaries, and support. We gave people autonomy without the scaffolding to use it well. Some thrived because they were naturally high agency and could navigate ambiguity. Many others felt lost.

We built for the people we wished to be. Not for the people we actually were. We imagined a company of autonomous, fully-aligned individuals who’d self-organize into perfect teams. That company exists in blog posts and conference talks. In reality, most people need more direction than we were providing. Not because they’re incapable, but because ambiguity is expensive and stressful.

That’s not a culture. That’s wishful thinking at scale. A small group setting expectations based on how they operate, then wondering why most people can’t meet them.

The fix wasn’t less autonomy. It was more clarity about what autonomy actually requires.

Pragmatism or Denial?

Our motto was basically: “It works. Ship it. We’ll fix it later.”

This is a reasonable approach when you’re small and moving fast. Speed matters. Perfect is the enemy of good. Get it in front of users, learn, iterate.

And honestly, it’s the right instinct. If you don’t ship, you’re not going to be around tomorrow to fix anything. A startup that spends six months perfecting its architecture before launching is a startup that runs out of money. We shipped, and that’s why we survived.

The problem isn’t shipping fast. The problem is never going back.

The quick fix that saved us a week in 2019 was still there in 2022, now buried under three layers of workarounds. The “temporary” solution became permanent. The module boundaries we never enforced got crossed so many times that no one knew where anything belonged.

Three years later, we had a monolith that was still one deployable unit (good) but had become an internal mess (bad). Not because the monolith architecture was wrong, but because we’d confused “pragmatic” with “undisciplined” in how we managed our codebase.

The monolith was right. Being pragmatic was right. But “pragmatic” doesn’t mean “no boundaries.” It means knowing which engineering trade-offs you can afford and which ones compound against you. We’d been making the wrong trade-offs and calling it pragmatism.

Some shortcuts were becoming anchors.

So We Changed

Not everything. That’s the important part.

We didn’t throw out the monolith. We didn’t hire an army of Agile coaches. We didn’t become a process-heavy corporate drone. We didn’t adopt whatever framework was trending on Hacker News that week.

But we had to learn something harder than being contrarian: when to stop.

Being contrarian is easy. It’s reactive. Someone says “do X” and you do the opposite. It feels good because you get to be the rebel. The one who sees what others don’t. The one who zigs when everyone zags.

But sometimes everyone zags because that’s where the road goes. And being the person who zigs off a cliff isn’t contrarian. It’s just dumb.

We had to admit that some of the “corporate” stuff we’d been mocking actually existed for good reasons. Not all of it. A lot of corporate process is genuinely wasteful theater. But communication structures, clear boundaries, explicit alignment, those aren’t bureaucracy. They’re how organizations of 100+ people function.

The hard part was figuring out which parts of our rebellion to keep and which to let go. That required something we hadn’t needed before: nuance.

The Reality

Here’s what I’ve come to believe after watching this play out over nearly a decade.

Don’t be contrarian for the sake of it. That’s just ego wearing a different hat. The person who automatically does the opposite of whatever’s popular isn’t thinking any more clearly than the person who follows every trend. Both are outsourcing their judgment.

And don’t follow the mainstream either. “Spotify does squads, so should we. Netflix does microservices, so should we. Google does OKRs, so should we.” That’s cargo culting. Copying the ritual without understanding the context.

Do Stop Cargo Culting

It’s tempting because it feels safe. Nobody gets challenged for adopting what Google does. It’s a shortcut past the hard thinking: instead of understanding your own problem, you import someone else’s solution and hope the context transfers. It rarely does.

Spotify’s squad model worked for Spotify’s specific challenges at Spotify’s specific scale with Spotify’s specific culture. Adopting it because “Spotify does it” is like wearing Michael Jordan’s shoes and expecting to dunk. The shoes aren’t the reason.

Critical thinking asks different questions: What problem does this actually solve? Is that our problem? What are our actual constraints? What worked about this for them, and do those conditions exist here?

Understanding the why before copying the what. That’s the difference between learning from others and cargo culting.

Before You Follow or Break Any Rule, Ask:

What game am I actually playing? Context is everything. Fintech vs consumer social vs B2B SaaS are different games with different rules. The right architecture for a social media app is probably wrong for a regulated financial institution. The right team structure for a 1,000-person company is probably wrong for a 50-person startup. Context matters more than principles.

What are my real constraints? Not what I wish they were. Not what Netflix’s are. Netflix can afford to let engineers choose any technology because they have the operational infrastructure to support it. You probably can’t. Be honest about where you actually are, not where you aspire to be.

Is this smart or just clever? Clever feels good. You get to show off your reasoning. “We don’t need tests because we hire good engineers.” “We don’t need documentation because the code is self-documenting.” Clever. Not smart. Smart is boring. Smart is doing the thing that works even when it doesn’t make for a good conference talk.

What’s the cost of being wrong? This is the one that matters most in fintech. In consumer social, if you ship a bad feature, you roll it back. In fintech, the stakes are higher. The cost of being wrong should determine how much you invest in being right. We had to learn that speed and rigor aren’t opposites, and that moving fast in a regulated industry means being disciplined about where you take risks.

Still Contrarian. With Scar Tissue.

So where did we land?

Still a monolith, but with proper boundaries. Packwerk enforces module boundaries now, and we actually care about them. The architecture is the same. The discipline is different.

Still small teams, but with better communication. We do the “theater” now. All-hands, roadmap reviews, cross-team syncs. Not because we love meetings, but because 100+ people can’t operate on osmosis. The meetings have a purpose, and we’re intentional about keeping them useful.

Still profitable, but investing in the platform. We’re not cutting corners on infrastructure anymore. Paying down debt is part of the plan, not something we’ll “get to later.” We wrote down what we actually believe about building products. Not a deck for investors. A shared operating system for how we make decisions.

Still high-agency, but with the direction people actually need. Autonomy with context. Freedom with boundaries. High agency works when people know what game they’re playing. Without that context, it’s just people running in different directions feeling empowered while the company drifts.

Same DNA. Better scars.

The Point

The real game isn’t being a rebel or a conformist. It’s having your own critical thinking.

Question everything. The hype cycle, the “best practices,” the conference talks, the blog posts (including this one). But also question your own instincts. Especially the ones that feel good.

My contrarian instinct served me well for years. It also blinded me to things I should have seen earlier. The answer isn’t to stop being contrarian. It’s to be contrarian about your own contrarianism. To hold your beliefs strongly enough to act on them, but loosely enough to change them when the evidence says you’re wrong.

And when you get it wrong, and you will, be smart enough to admit it and change. Not dramatically. Not by swinging to the opposite extreme. Just by adjusting, learning, and moving forward with a little more nuance than before.

In an age where you can ask an AI “should I follow best practices or think for myself?” and get back a cheerful “You’re absolutely right! Critical thinking is so important. You should definitely always think for yourself!” … having your own critical thinking matters more than ever.

And now here I am. The guy who thought conference talks were for people who’d stopped building. Preparing a conference talk.

€192M in revenue for 2026. €25M in EBT. 125+ people in engineering. Still standing. Not because we were contrarian. Because we learned to think.

We are still wrong about something today. We just don’t know what it is yet.