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 vatnode.dev — a SaaS for EU VAT validation — the requirements were precise from the start: Redis caching, rate limiting by API key, Stripe billing, a VIES integration that degrades gracefully when the EU's SOAP API has one of its frequent bad days. Clear problem, clear constraints, clear measure of success. That's the kind of engagement where I can actually deliver something good.
The projects that go badly have a recognizable pattern. The brief is "we need an app, here's the general idea, we'll figure out the details as we go." Or there's a mismatch between urgency and budget. Or the client doesn't have a technical background and responds to every recommendation with "but can't you just..." — not because they're trying to be difficult, but because they don't have the context to evaluate the recommendation and don't trust that you do either.
I don't take those projects anymore. Not because I'm precious about it, but because they reliably produce bad outcomes for both sides. The client doesn't get what they needed, I don't produce work I'm proud of, and everyone ends up frustrated.
This is a filter, not a criticism. Some developers work very well with ambiguous briefs and lots of iteration. That's a skill. It's just not my best mode.
How I Actually Work
I'm based in Finland. I have a family. I value efficiency because I don't have unlimited time to throw at a problem, and because I've seen too many projects where hours were confused with progress.
My working pattern is tight, focused sprints. I prefer to receive a clear problem, disappear for a defined period, and resurface with something working. I over-communicate status and blockers — not because I was told to, but because I've been on the other side enough times to know how much ambiguity costs. If something is going to be late, you'll know before it is. If I'm blocked, I say so immediately, with a proposed path forward.
I come to every engagement having read the specs. This sounds obvious. You'd be surprised how often it isn't. Before the first call, I've read whatever documentation exists, formed questions, and often formed an early opinion about the approach. I'd rather spend 30 minutes preparing for a meeting than 90 minutes in a meeting that could have been 30.
Building pikkuna.fi — 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 htpbe.tech — a SaaS for PDF forensic analysis — the first working version of the 5-layer forensics analysis was running in a few days. It wasn't polished. But the core logic worked and we could test it against real documents. That's the unit of progress that matters early on: something real that can be evaluated.
The One Thing I'd Tell a Company Hiring a Senior Freelancer
Don't hire me for routine work.
I don't mean that dismissively. Routine work is perfectly valid work, and there are plenty of developers who do it well and enjoy doing it. But routine work — tickets, incremental features, maintaining a stable codebase — is not where someone with a CTO background and 25 years of development adds disproportionate value.
Where I add disproportionate value is the complex problem that doesn't have a clear solution. The integration that keeps failing in production for reasons nobody can explain. The architecture decision that will constrain everything for the next three years. The system that needs to work across 35 EU markets with compliant VAT handling and zero manual intervention. The checkout flow that has to be reliable enough that a failed webhook at 2am doesn't cost you a customer.
These are problems that need someone who can own the outcome, not just complete the task. A task executor builds what they're told and hands it over. An owner thinks about what happens when it breaks at 2am, what the next engineer who touches this code will understand, whether the abstractions will hold as requirements change.
If you're building something complex for the EU market — a SaaS with real compliance requirements, an e-commerce platform that needs to actually work across multiple countries, an automation pipeline that replaces manual work — those are the problems I want to work on.
On the Transition Itself
One thing I wasn't prepared for: how much of my professional identity was wrapped up in the title. CTO is a legible signal. It means something to other people immediately. "Senior Full-Stack Developer, freelance" takes longer to explain and requires more demonstration.
What I've found is that the demonstration is the thing. Writing about what I've actually built — the VAT validation service, the multilingual e-commerce platform, the PDF forensics tool — is more useful than any title. The work explains itself better than the biography does.
I don't miss the management. I miss having a team to think through hard problems with. I've found partial substitutes — other independent developers I talk to regularly, communities online — but it's not the same. If you work alone, you have to be more deliberate about getting external perspective on your thinking.
Would I go back? Honestly, I don't know. I know I wanted this, and I know I'm doing work now that I find more directly satisfying than the last few years of the CTO role. That's enough for the moment.
If you're building something complex for the EU market and you're looking for someone who can own the technical outcome rather than just execute tasks — get in touch. 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.