Everything I've written
On product, engineering, hiring, and the decisions founders can't afford to get wrong.
What ten years of founding taught me that no course can
There are things you only learn by building something over a long time, with your own money and reputation on the line. After roughly a decade of it, here is what none of the courses or books ever quite conveyed.
What a fractional CTO actually does in the first 30 days
Founders expect me to start by writing code or drawing an architecture diagram. I do neither in the first month. The fastest way to do damage is to start solving before you know what is broken.
Why I keep my client roster small
A fractional CTO spread across a dozen clients is not a fractional CTO. It is a very expensive email address. Here is why the work only works when the roster stays small.
When not to use AI at all
Most problems do not need AI, and reaching for it when you do not need it makes your product worse, slower, and more expensive. Knowing when not to use AI is more valuable right now than knowing how to use it.
Turning messy business logic into clean software
A lot of software work is not really about software. It is about taking a messy human process that lives in someone's head or a chaotic spreadsheet and turning it into something a computer can run reliably.
What breaks when an AI feature meets real users
The moment an AI feature meets real users is the moment you discover what you actually built. Everything that felt solid in testing gets pressed on by people who do not behave the way you assumed. It breaks in a predictable order, and knowing that order is the whole advantage.
RAG in a demo vs. RAG in production
A RAG demo is trivially easy and a RAG system that works in production is genuinely hard. The gap between the two is where a lot of AI projects quietly die.
The real cost of the wrong architecture decision
A wrong architecture decision does not break anything the day you make it. That is exactly the problem. It sits in the foundation and quietly charges interest, for years, until the bill is too large to ignore.
The hidden costs of building on top of LLMs
Building on a large language model looks cheap and fast at the start. A few API calls and you have something that works. The costs that matter show up later, after you have already committed.
What founders get wrong about technical debt
Technical debt gets talked about as if it is always bad, something to be ashamed of and eliminated. That framing is wrong, and it leads founders to make worse decisions, not better ones. The skill is not avoiding it but knowing exactly what you borrowed and what it costs.
Your AI demo is not a product
An AI demo and an AI product look almost identical in a screen recording. They are completely different things, and the gap between them is where most founders are stuck right now. The demo was the easy ninety percent. The last ten percent is the actual product.
Designing systems that survive the next funding round
The raise is supposed to be the good news. It is also the moment two pressures arrive at once: growth you now have to serve fast, and strangers looking under the hood. The architecture that got you here is about to be asked to become something else, in public, at the worst possible time to be caught short.
Hiring is easy. Firing is the skill no one teaches.
Hiring gets all the attention. But the decisions that taught me the most were the ones where I had to let someone go, and no one ever teaches you how to do that part well.
Building a team that can run without you
Being needed feels like proof of your value. It is actually a ceiling. The strongest thing a founder can build is a team that runs without them, and getting there means giving away the exact things that make you feel important.
Build vs. buy without lying to yourself
Build versus buy looks like a technical decision. It is really a decision about where your company's limited time and focus should go, and founders get it wrong in both directions for the same reason: they lie to themselves about the true cost.
Your tech stack matters less than you think
Founders and engineers pour enormous energy into choosing which technologies to build on, as if the choice will make or break the company. It almost never does. The stack is the easiest thing in the room to argue about, which is exactly why it absorbs the energy the hard questions deserve.
No single feature will make you a millionaire
Founders fall in love with the one feature they are sure will change everything, the thing that finally makes the product take off. After a decade of building, I can tell you it almost never moves the number you hoped, and believing it will is a reliable way to waste months.
The architecture decisions that get expensive to undo
Some technical decisions are cheap to change later and some lock the door behind you. Most of your care is wasted on the first kind. This is the short list that actually earns it, and what makes each one so hard to take back.