The weight you’re carrying
You started this company because you understand a problem better than almost anyone. You know the customers by name, you know what they’ll pay for, and you know what the product has to do next quarter. That knowledge and that drive are the reason there’s a company at all.
But every technical decision lands on you too. Which developer to hire, and whether their code is any good. Whether the quote from the agency is fair. Whether the app is secure enough for the customer who just sent a security questionnaire. Whether “we need to rewrite it” is true or just what a new developer always says. You’re making those calls without a way to check them, and it keeps you up at night.
A full-time CTO is expensive and hard to find this early. A technical cofounder means giving away a large slice of the company, often to someone you met a month ago. There’s a third shape that fits many companies better.
What a technical partner does
I take ownership of the technical side, part time and ongoing, the way a CTO would. You stay responsible for the business and the customers. I stay responsible for the technology being sound, safe and pointed at what the business needs.
In practice that covers:
- Architecture. How the system is put together, what it should be built on, and when something genuinely needs rebuilding versus when it just needs care.
- Security and data. Who can see what, how secrets are stored, backups that are actually tested, and straight answers for customer security questionnaires.
- Vendors and spend. Which services you pay for, whether the hosting bill makes sense, and whether an agency quote is fair. I read contracts and proposals with you before you sign.
- Hiring and reviewing developers. Writing the job description, running the technical interview, and reviewing the code your developers or freelancers ship, so you know the work is good without having to read it yourself.
- A roadmap you can trust. Turning what you want the product to do into a sequence of work with honest estimates, and telling you early when something will take longer.
- Being the person you call. When the site is down, when a big customer asks a hard technical question, when an investor wants to talk to “your technical person”.
Where the experience comes from
I spent seven years as a senior engineer on a multi-tenant B2B SaaS product while it grew from about four million to thirteen million dollars in annual revenue. I ran its production Postgres database, around a terabyte of it, and cut its AWS bill by six figures a year. I’ve also built and run a live product on my own, which means I’ve done every technical job a small company has, from the database to the deploys to the support inbox.
That mix matters for a founder. I know what a growing SaaS company runs into at each stage, and I know what it’s like to be the only technical person in the room.
Documentation, so the company keeps the knowledge
The risk with any single technical person, a cofounder, an employee or me, is that the knowledge lives in their head. I write it down as I go, because it belongs to your company:
- A plain-language system overview a new developer or an investor’s technical reviewer can read in an afternoon.
- Runbooks for deploys, outages, restoring backups, rotating keys and onboarding a developer.
- Decision notes on every significant choice: what we picked, what we rejected and why.
- Performance and cost numbers, measured, with the date they were taken.
- Instructions for AI assistants, so developers using AI tools on your code get good help.
You own all of it, along with the code, the accounts and the hosting. If you hire a full-time CTO later, they start from a complete picture instead of a guessing game. That handover is a success, not a loss.
Take a business like this one
The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.
Picture a founder who spent fifteen years in commercial insurance and started a company selling a claims-tracking product to small brokerages. Two freelancers built the first version. There are thirty paying customers, a larger brokerage wants a pilot, and that brokerage has sent a forty-question security review. One freelancer has gone quiet. The other says the app needs a rewrite before it can handle the pilot.
What I’d do for a company shaped like this:
- First month: get the full picture. Read the code, the hosting and the accounts. Write a short report: what’s solid, what’s risky, and whether the rewrite is actually needed. Usually the honest answer is that a few parts need serious work and most don’t.
- Answer the security review truthfully, and fix the gaps it exposes, in order of risk.
- Make sure the company holds every key. Code, hosting, domain and payment accounts in the company’s name, not a freelancer’s.
- Hire well. Write the role, interview the candidates technically and review their first weeks of code.
- A roadmap for the next two quarters, built around the pilot and what the founder hears from customers.
- Then the steady rhythm: a weekly check-in, code review on everything that ships, and someone on call when it matters.
The founder spends their time where it counts: with brokers, on the pilot, and on the next round of customers.
What it costs
It starts with a fixed-price technical assessment: a written read of your code, hosting, security and team, with clear recommendations. If we keep working together after that, it’s a monthly retainer scoped to the hours and responsibilities you need, reviewed every quarter. No equity, no long lock-in, and you can step it up or down as the company changes.
What I need from you
Access to the code, the hosting and the vendor accounts. An honest picture of where the business is: customers, revenue, runway and what you’re promising people. A regular slot in your week. And for you to keep telling me what customers say, because the technical priorities follow from that.