The platform is the product when you have fifteen engineers.

There's a moment, somewhere between five and twenty engineers, when every team rebuilds the same set of internal tools. A logging service. A deploy pipeline. A feature-flag system. A secrets manager. Each one starts as a weekend hack and graduates, over the course of a year, into a small product that the company is shipping to its only customer — itself.

I've seen this pattern at four companies now. It always feels rational while you're inside it. Logging is too expensive at scale, so we'll route it ourselves. The deploy pipeline is too slow, so we'll write our own. The build farm needs a babysitter, so we'll hire one. And so on.

The thing I missed

What I missed for most of those years is that the internal tools you build aren't free. The cost isn't the salary of the engineer maintaining them. It's the inability of every other engineer to reason about the system as a whole.

When the platform is also a product the company is shipping to itself, you have two roadmaps. You've doubled your meetings. You've halved your focus.

I started counting platform work as product work that wasn't getting done. The math got uncomfortable fast.

What changes at fifteen people

At fifteen engineers, the cost of running an internal platform team is two senior engineers, two junior engineers, and the meeting overhead of three product teams. That's a sixth of your headcount working on infrastructure your customers will never see.

The decision isn't whether internal tooling is valuable. It is. The decision is whether you're better at writing it than the people whose entire company is writing it.

At fifteen engineers, the answer is almost always no.

A reasonable rule

If your platform team is more than ten percent of your engineering headcount, ask what you'd ship next quarter if those people were on product. If the answer is "the things our customers actually asked for", you have the answer.