Fractional CTO
I work with founders and leadership teams as a part-time CTO. I set the technology direction, build and lead the engineering team, and make sure what gets built is what the business needs.
The people who write to me are usually not engineers. They run a company that depends on software, and something about that software has become their problem. Four situations come up more than any other, most of them at pre-seed and seed stage.
Whatever state your software is in, I have seen worse. Nothing you send me gets judged. It gets read.
Situation one
"I built the whole app with Cursor and Claude. It works, we have paying users, and I have no idea what is inside it. It keeps me up at night."
You need someone to read it and tell you in plain words what matters, what can wait, and whether it needs a rewrite. It almost never does.
What I do first. Send me the repository or a screen recording. I read it and write down what I found: what is fine, what will break, what to fix this week. You usually have that within a week. Then we decide whether you keep building with the tools, hire someone, or both.
Situation two
"We have customers and an agency. I can't tell if what they build is any good, and I'm the one signing the invoices."
You need someone on your side of the table who can read the code, judge the agency and tell you what is worth paying for.
What I do first. I read what has been delivered so far and write down what it is worth. From then on the agency has a technical counterpart, the scope is written down, and invoices get compared to work. Most agencies improve quickly once someone reads what they deliver. The ones that don't, you find out early.
Situation three
"Our senior developer resigned. Nobody else knows how the system works, and a replacement takes months to find."
You need the system understood and written down, the team steadied, and the next hire made properly instead of in a panic.
What I do first. If the person is still working their notice, call me now. Two weeks of handover saves months later. I map the system while the knowledge is still in the building and get it into writing. Then we hire the replacement properly, with me in the interviews.
Situation four
"Every investor asks who is building this. I don't have an answer they believe."
You need a technical partner whose name and track record can go on the deck, who takes the technical questions on the call, and who answers the diligence in person.
What I do first. I read the product before I agree to anything, because my name goes on your company. If it holds up, I join as technical partner for the raise: on the deck, on the calls, through diligence, and into the first hires afterwards. I do this for a few companies at a time, with equity and a defined time commitment, so it holds up when investors check. Some investors will still want a full-time CTO on the team eventually. Part of the job is the plan for that hire, and I help make it.
A CTO's job is to connect the business plan to the technology, in both directions. Goals, budgets and deadlines go one way. Architecture, team and vendor decisions come back, explained in business terms.
A roadmap that follows the business plan. What to build, what to buy, what to postpone, and what it will cost.
Systems that can be changed later without a rewrite. After fifteen years of building them I know which shortcuts are cheap and which ones you pay for a year later.
Writing down what good looks like, hiring for it, and setting up the process so the team ships without me in the loop.
Reading outsourced work before it is paid for, holding vendors to their scope, and cutting spend nobody can explain.
I use AI tools every day to build real systems. I set teams up to get the speed without the codebase turning into something nobody understands.
A written read of a codebase, a team or a technical plan before you commit money to it.
Most companies sit next to data they never collect. Competitor prices, marketplace listings, supplier stock, public registries. It is all there on other people's websites, and it is usually far cheaper to collect than to buy.
I have spent years building systems that collect this kind of data reliably and at volume. Expensive scrapers render pages in a browser. Cheap, stable ones understand how the site actually works and talk to its own API. The collection is only half of it. The data is worth something once it is cleaned, stored properly and turned into a pricing decision, a stock signal or a report someone actually reads.
If your business would be better with data it does not have, this is usually the fastest place I can make a difference.
Most CTO titles are handed to the first engineer in the room. The job is different from engineering, and the qualification for it is judgement. Mine comes from four places.
I started writing code at fifteen and have spent every project since trying to write it better than the last one. The last codebase I handed over was a hundred thousand lines. The engineer who took it was working in it on their own after three days, and that was before AI tools existed. Structure does that. It is also where judgement about software comes from: fifteen years of placing bets on how a system will behave, and living with the results.
The products I shipped ran real operations. Pricing, orders, fulfilment. When a system like that is wrong, the company loses money the same day. I make technology decisions with that in mind and I explain them in the same terms.
I have hired engineers, advised founders on hiring their first CTO, and set up the processes that let a team ship every week without late nights. The hardest part of the CTO job is people, and you cannot judge engineers well unless you have been a good one.
You get my opinion on paper, including when the answer is that something should not be built. A CTO who cannot say that to the CEO is an expensive engineer.
Whatever the engagement, the first thing I set up is the way work reaches production. After that, three ways to engage.
Embedded in the leadership team. I own the technology direction, the engineering team and the vendor relationships, with a written scope and a review every quarter.
For founders who already have a team and want a senior second opinion on the decisions that matter, such as architecture, a key hire, or whether to build or buy.
A technical due diligence, an architecture review, or leading a build phase and handing it over to the people who will run it.
Marketplace software for resellers, built and operated end to end.
Automated price management for sellers on the largest marketplaces, driven by live listing data.
Order and fulfillment workflow software for e-commerce operations.
Collection pipelines that work with a site's own API rather than rendered pages, built to keep running when the site changes.
Plus many smaller products and internal tools over fifteen years.
I grew up in a village in Germany with a fascination for computers that started early and never went away. I wrote my first real code at fifteen, eighteen years ago, and started my first business at eighteen.
For the last fifteen years that has meant building software for businesses, most of it in e-commerce: a reseller platform, a marketplace repricer, a fulfillment tool, and the data platforms behind them. I built most of it myself, end to end, and kept it running for the businesses that depended on it.
Today I work with founders as a fractional CTO and technical partner. I take on a few companies at a time, read everything myself, and still build with AI tools every day, because that is where the judgement comes from.
Tell me what is going on in the business and where the technology is getting in the way. I read every message myself, and nothing you send is judged. Half-finished, messy, embarrassing, all fine. That is usually where the useful work starts.