You Didn't Build a Product. You Adopted 40 Orphans.

I have a question I now ask in the first hour of every fractional CTO engagement, and it makes founders visibly uncomfortable.

Not "what are you building." Not "what's the roadmap."

List everything you own.

Every feature that has a login path to it. Every background job. Every internal dashboard. Every integration with a third party who can change their API next quarter. Every separate service someone spun up because it seemed cleaner at the time. Every database. Every admin tool. Every Zapier chain and cron job that something depends on.

The last founder I did this with, at a company of six people, stopped at 34 items and admitted he didn't know what four of them did. He wasn't careless. He was a very good operator who had raised real money and shipped fast. He just thought he had a product. What he actually had was 34 dependents, and about five of them were earning their keep.

Making things got cheap. Keeping them didn't

Steve Grosz wrote a piece a few days ago called AI is making us build too much, using Steve Yegge's Wheelhouse project as the example: agents that produce code and process and governance faster than anyone can absorb it, layering complexity on their own output until the production far outruns the value. It's worth reading, and I'd push it further than the engineering audience it was written for.

Here's the part that matters to you as a founder. AI has collapsed the cost of creating software by something like an order of magnitude. It has not touched the cost of owning software at all.

Ownership isn't a one-time payment. It's a subscription you pay in attention, forever, per thing. Every item on that list of 34 needs someone to notice when it breaks, decide whether it's worth fixing, patch it when a dependency goes end-of-life, migrate it when the database schema changes, explain it to the next engineer, and answer for it when a customer's data ends up somewhere it shouldn't be. None of that got cheaper. Some of it got more expensive, because now the code was written by something that doesn't remember writing it.

So the default outcome for a small team in 2026 is not an unfinished product. It's a finished-looking product with forty orphans in it: features, services and dashboards with no owner, no usage data, and no defensible reason to exist, all of which still show up on the bill.

What I actually paid for during 4 to 31

I scaled one engineering org from 4 to 31 people, past 10M monthly active users, on the way to $80M ARR. That's the number I put in a bio. Here's the number I don't.

A meaningful chunk of those years went to paying interest on code we wrote in a hurry. Not "technical debt" as an abstraction. Concrete things. A reward mechanic we shipped for one campaign in year two that nobody ever turned off, so every payments migration for the next four years had to keep it working. Two analytics pipelines that disagreed, which meant every metrics conversation started with fifteen minutes of arguing about which number was real. Internal tools built for an ops workflow that had been replaced twice since.

We could afford it, barely, because we had 31 engineers and revenue. The interest was survivable at that size.

At five people it is not survivable. If a third of your engineering attention goes to maintaining things nobody asked for, you don't have a slow team. You have a team that can no longer change direction, which for a startup is the same as being dead with extra steps.

And that's the thing AI made worse in a way that's easy to miss. Before, your build capacity was the constraint that protected you. You physically couldn't produce 34 things with six people, so you were forced to choose. That constraint is gone. Nothing replaced it. So the choosing has to become a deliberate job that someone does on purpose.

Stop measuring shipping. Start measuring maintained surface

Here's my actual position, and I'll defend it against the obvious objection in a second.

Measure your engineering function by what it maintains, not by what it ships. Velocity as a headline metric is now close to worthless, because with the current tools velocity is trivially inflatable. Anyone can show you a demo, a dashboard and three new features by Friday. What they can't fake is a small, well-understood, fully owned surface area that a person of ordinary skill can hold in their head.

The practical version, and this takes an afternoon:

• Write the ownership list. Every item, one line each, with a named human owner and the last date anyone can prove a customer used it.
• Anything with no owner or no proof of use gets a sunset date, not a maintenance plan.
• Deleting something counts as shipping. Put it in the changelog. Say it out loud in the all-hands.

The counter-argument I take seriously: sometimes you genuinely don't know which feature will land, and cheap exploration is now a real advantage. Agreed. Build the experiment. Then set the removal date when you build it, before you're emotionally invested. An experiment with no expiry isn't an experiment, it's a permanent liability you haven't priced yet.

What your first technical hire is for now

If you're a non-technical founder hiring your first senior technical person, you are going to be sold speed. Everyone's pitch this year is "we can build all of it now." That's true and it's the wrong offer.

The job of that person is to be the constraint that the tooling removed. Their most valuable output is a no, followed closely by a deletion. Interview for that. Ask a candidate what they killed at their last job and what it cost them politically. If they only have a list of things they built, you're hiring a producer of orphans, and producers of orphans are now abundant and cheap.

That's most of what I do inside a two-week fractional CTO sprint at $4,500: not adding, subtracting. Same instinct behind the $14,500 fixed-scope MVP being fixed-scope. The scope isn't a limitation I'm apologizing for. It's the product.

You do not have a building problem. You almost certainly have a custody problem.

Count what you own before you approve one more thing to own. If the number surprises you, that's the conversation to have.