"We're a Tech Company" — With Zero Developers

"We're a tech company."

I've heard this from companies with zero developers more than a few times. It used to be a slightly awkward claim. The service had been outsourced, and after delivery nobody could touch it.

Things are different now. Even without a developer, the thing gets built. Tell an AI what you want and screens appear, features work. So the claim doesn't sound awkward anymore. It sounds fairly plausible.

The problem is that shipping something and being able to keep it alive are two different stories.

Building and maintaining are different jobs

Building happens once. Maintaining is continuous.

• When it breaks. You get a call at 2am: payments are failing. Someone has to find the cause, and nobody in the company understands that code. You can ask an AI, but the AI doesn't know what state your service is actually in right now. Diagnosing from a screenshot alone is hard for a human and hard for an AI.
• When you need to change it six months later. Building was fast, but nobody knows why it was built that way. Touch it and something else might break, so nobody touches it. Changing one feature ends up taking longer than building the whole thing did.
• When something goes wrong. Customer data leaks, or a payment double-charges. That isn't a "just fix it" problem, it's a liability problem. Someone has to determine what got exposed and how far.

These three share something. They all happen after you build, and they all require judgment. That's a different capability from an AI writing good code.

"I can build it" doesn't mean "I understand it"

This is the most common illusion of the AI era. Something got produced, so it feels understood. But produced and understood are not the same.

Honestly, this applies to developers too. If I don't actually read the code an AI wrote for me, I'll be just as lost six months later. The only difference is that I can read it. Having nobody in the company who can read it, versus having someone who can but didn't, are different sizes of risk.

So the real test of "we're a tech company" isn't whether you employ a developer. It's this: when something goes wrong, is there someone, somewhere, who can make the call?

That's not a pitch to go hire a developer

Telling a solo operator or a five-person company to "hire a developer" isn't realistic. Salary aside, there isn't enough work to keep one busy full-time. So the advice gets ignored, and ignoring it is the rational move.

My answer is different. Technical judgment can be bought. Not as a full-time hire, but at the specific points where judgment is actually needed. And there aren't many of those points.

• Before building — what will this structure block you from doing later
• On delivery — is this really working, or does it just demo well
• When something breaks — how far does the problem actually reach

Clear those three and you don't need a developer for the rest. Miss all three and you'll hit the same incident with ten developers on staff.

---

There's nothing wrong with a company without developers calling itself a tech company. These days you really can build the thing.

But what comes after building is much longer. If nobody can make a call during that long stretch, that isn't a tech company. It's a company hoping to stay lucky.

If you're running a company on your own, I'd be glad to talk at mvpit.dev.