18 years in engineering: from field sites to my own products
The short version: I'm good at taking apart complicated systems I didn't build, explaining them to people, and getting a product to the point where someone pays for it. The long version is below.
Field engineering, worldwide
Support engineer at Infinet Wireless, a manufacturer of wireless data transmission equipment. The Middle East, Asia, Europe, Russia: training customer engineers and getting real deployments working on site.
Two lessons from those years still pay my bills. The first: how to fix things you didn't design. On site there's no author to ask and no documentation, and the link has to be up today. That's exactly how I walk into someone else's codebase.
The second: how to explain something complicated so the person on the other end can repeat it without you. An engineer in another country, with another language and another background, has to be able to work alone after the training ends. That's the same job I do now when I bring AI tooling into someone else's team.
Count the money, not the lines
I spent several years running my own company. I know how the money gets counted, why a deadline beats elegant architecture, and exactly how it feels when a contractor goes quiet for a week.
It changed how I work: I don't propose the technically interesting solution when a cheaper, more boring one exists.
Projects at a digital agency
Project manager at a digital agency, leading website builds for the agency's enterprise clients — among them Huawei, Philips and Microsoft.
This is where I saw development from the business side: how a brief actually gets written, how work gets signed off, why projects slip, and what "no" sounds like from a client who was never told what he was paying for.
Engineering and my own products
From developer to iOS Team Lead running five engineers. Migrated a product from UIKit to SwiftUI, built code review and unit testing practice, fixed data races in real-time systems handling actual money, and took an app with 1.5 million daily users to a zero crash rate.
Alongside that I build my own products. Three apps in the stores, each with its own backend, analytics, subscriptions, release pipeline and paying users. Plus everything around them: price A/B tests, publishing automation, AI loops that generate the next hypothesis.
Your own products are the most honest school there is. There's no client to blame: if nobody buys the subscription, that's on you.
What I believe
The simple solution beats the clever one
If 50 lines will do instead of 200, it should be 50.
A working build every week
Not a progress report — something you can install and use.
An honest estimate over a pleasant one
Better to say "expensive and slow" up front than "almost done" three months running.
The client owns everything
Code, keys, credentials, infrastructure. Lock-in isn't a business model, it's hostage-taking.
Education
University degree (Specialist) — Mathematics and Mechanics, Computer Science.
Now
I work remotely with clients worldwide, and have done for eight years. I take on a limited number of projects at a time so each one moves instead of queuing.