Common threads in my work
I started my career as a software developer and soon led teams and projects at software companies and startups, before founding a startup of my own. The places and products changed; four things kept coming back. They’re why clients bring me in, and why some stay for years.
Business and engineering, across time zones
Straight out of university in 2007, my first job was to make an outsourcing arrangement work. imbus, a German software testing company, sent me to lead its offshore development team at a partner company in Shanghai. The engineers were capable, but there was a constant gap between what Germany expected and what got built. The teams were far apart in time zone and working culture, nobody was available when a question came up, and the engineers didn’t know the people on the other end or what they expected. I became the bridge between the two sides: available when questions came up, helping each side understand the other’s expectations, and building the trust that made it work.
I’ve done the same ever since: between SiteOwl’s leadership in the US and its development team in India, and between TVT’s business and its development contractor in Vietnam. What makes it work is the right process and a shared understanding on every side. At SiteOwl the time difference even became an advantage: a problem reported during the US day was often fixed in India overnight, ready for the next US morning.
From engineer to founder: fluent in business and tech
At FriarTuck in Singapore I built the local development team and a new web and mobile product for small businesses. As the engineer, I was on the receiving end of changing requirements, but I didn’t always understand the business reasons behind them.
That changed in 2014, when I started my own company. I built the first prototype of a language-learning platform for schools myself, met about a dozen language schools, and found co-founders with expertise outside my own: education and business development. A training provider became our investor and first customer, I published a paper on language learning environments, and in 2016 the investor bought the company. Now I was the one writing and changing requirements, and I understood why.
Two lessons from that time shape my advice. Building is often the easy part; getting people to adopt a new product is the real job. And when customer needs change, the roadmap has to change with them, even if that means dropping work the team is proud of. Having seen both sides, I help them understand one another. Developers see what the business expects and why; the business learns what the team is up against and what it takes to deliver.
From duct tape to a scalable system
Many businesses I work with start with something that got the job done: spreadsheets, off-the-shelf tools, a website built by hand, and now often an app built with AI. It works until growth makes it fragile.
It started with an internship in 2004, at a language course agency in Spain whose founder had built every page of his booking site by hand. I rebuilt it so a change no longer had to be copied across dozens of pages. At TVT, the network of linguist contractors ran on a spreadsheet; we replaced it with a platform, and the network grew from 200 to 8,000 without adding coordinators. At an online language school, lessons ran on website plugins, Zoom links, and spreadsheets until we built an app that let students join a lesson with one tap.
None of these were mistakes. Duct tape is the right way to start; the skill is knowing when to replace it, and with what.
Building teams that last
I’ve hired people in almost every role I’ve had: about ten for the team in Shanghai, the whole Singapore team at FriarTuck, and the development studio for my own startup. Since then I’ve helped many clients find developers, testers, designers, and infrastructure engineers, individually or through agencies. The roles and companies differ, but the process remains: define what the team is missing, find and screen the right people, and onboard them so they’re set up to succeed.
Hiring is the start, but people only stay where they can grow. SiteOwl’s development team came through a contractor in India, but we treated it as our own: we invested in team building and supported each person’s growth. Members stayed close to four years on average, a long time for a contractor team.
When SiteOwl wanted a full-time CTO in the US, they offered me the role first. Since I chose to stay fractional, I defined the technical side of the role, interviewed the candidate to ensure the right fit, supported him through the handover, and stayed on as their engineering manager.
How I work
Remote, with a fixed rhythm
I work with clients in North America, Europe, and Asia, remotely and occasionally on site. Every engagement has a fixed rhythm, such as weekly calls, with time reserved for it. Response times are defined for each engagement, and when a team needs me, I help as soon as I’m free. I make sure decisions and the reasons behind them are documented, so everyone works from the same understanding.
Set up for what the client needs
Before proposing a structure, I want to understand what the client expects: an advisor, or someone who takes ownership. That isn’t always clear at the start, and it can change over time. We shape the engagement accordingly: enough time, the right touch points, and a clear understanding of where I get involved. A monthly summary shows what was done and which risks I see.
Independent advice
I don’t sell development and have no team of my own. Nothing makes me favor a technology or a vendor, or propose more work than the product needs. A founder who asks three vendors for a quote may get three different technologies, each the one that vendor’s team knows best. My recommendations are based only on what fits the product and the business. When a client needs a tech team, I’m happy to introduce people I’ve had good experiences with, and I take no referral fees.
How I use AI
I use AI every day: to research, to work through data, documents, and code, and to get immediate feedback on my work. I’ve built it into real products, such as an AI integration at TVT that drafts subtitles for professional subtitlers. I’ve also reviewed products built with it, so I know where it saves weeks and where it quietly creates problems. It speeds up the routine work, so more of my time goes into what creates value for my clients. The thinking, the decisions, and every deliverable stay mine.
