Twelve years as CTO. Then, one day, I wasn't.
Not because things went badly — they didn't. FP Oy, the logistics company in Finland where I led engineering, was stable, growing, and technically solid by the time I left. I left because I wanted to build things again. Not manage the people who build things. Build things myself.
That was roughly a year ago. What followed has been clarifying in ways I didn't expect. About work, about clients, about what I'm actually good at — and what I'm not.
This is the honest version.
What I Thought Would Be Hard (And What Actually Was)
When you spend 12 years making technical decisions for a company, you forget what it's like to not have a team. You forget because you're always surrounded by people who handle parts of the problem you're not looking at. A developer asks about the database schema. Another is debugging an integration. A third is demoing something to a client. You're coordinating, unblocking, deciding.
When you go independent, that infrastructure disappears overnight.
I expected the sales part to be uncomfortable. Cold outreach, positioning, writing about myself — none of that comes naturally to someone who spent a decade in an internal leadership role. I was right; it was uncomfortable. But it was learnable. You figure out your pitch by talking to enough people and watching what resonates.
What I didn't expect was the silence. Not the bad kind — just the absence of the constant hum of a team operating around you. No one pings you with a problem at 9am. No one asks for a code review. You sit down, open your editor, and it's just you and the problem. I found I liked it more than I anticipated.
The instability is real. There's no salary arriving on the 15th regardless of whether you found a client this month. The first time a project ends and the next one isn't immediately lined up, you feel it. This part doesn't get comfortable — you just get better at managing the gap.
How 12 Years of CTO Work Changed How I Freelance
Here's what I didn't fully appreciate until I was on the other side: being a CTO doesn't teach you to be a better developer. It teaches you to think like the person who has to live with the consequences of the technical decisions.
When a client tells me they need a feature, my first question is never "how do I build this?" It's "why do they need this, and is this actually the right solution to the underlying problem?" That sounds like a small distinction. In practice it changes almost every conversation.
I've had clients come to me with a precise technical specification — down to which library to use — when the real problem was something two levels above the code. A developer who's seen enough of these situations learns to gently redirect: "I can build exactly what you described, but let me tell you what I'd actually recommend and why." Sometimes they want what they originally asked for anyway. That's fine. But at least they've heard it.
The other thing 12 years of leadership gives you is the ability to say no constructively. Not just "no, that's wrong" — but "no, because X, and here's what I'd do instead, and here's the tradeoff." That framing is the difference between being useful and being difficult. Clients need someone who can push back. But they need it done in a way that moves things forward, not sideways.
The architecture perspective matters too. When I come into a project, I'm not thinking about my slice of the work in isolation. I'm thinking about how this fits into the system, what the data model implies for six months from now, where this will break under load, and whether the abstraction we're building today will become the technical debt someone hates in two years. You can't un-develop that way of seeing things.
The Clients Who Work, and the Ones Who Don't
I'll be direct here, because I think being vague about this wastes everyone's time.
The projects I do my best work on share a few characteristics. The client has a clear, specific problem — not a vague aspiration, but something concrete. They care about quality and correctness more than they care about getting something shipped in the minimum possible time. They're building something real for real users, not an internal proof-of-concept that will be thrown away. And they communicate directly: when something changes, they tell me; when they're not sure, they ask.
When I built — an e-commerce platform for 30 languages across 35 countries — I had to be this way by necessity. The scope was large, the integrations were complex (Stripe, Zoho CRM, Airtable, PostNord, Netvisor, Mailgun), and the automation pipeline had to go from payment to invoice in under two minutes with zero manual steps. That kind of system doesn't get built through ad-hoc iteration. It gets built through deliberate, incremental construction with clear milestones.
MVP in days, not weeks. I mean this literally. When I built . I work with a small number of clients at a time, on projects where the problem is interesting and the quality bar is high.
I'm available for freelance engagements and longer-term contracts.
SOCIAL SHARE CARD GENERATOR