A project is not a product

This is the distinction I’ll argue about, and it’s the thing building a company has taught me most.

The difference starts before either one exists.

A project begins with you. You wanted to build the thing, so you built it. It’s answerable to your curiosity and nothing else, which is exactly what makes projects worth doing.

A product begins with somebody else. Someone has a problem, you can see a way through it, and from that moment the thing you’re building is answerable to them. Not to how interesting it is. Not to how clever the approach was. To whether it’s actually useful to a person who did not ask how it works.

Everything downstream follows from that one difference.

A project runs once, on your machine, under conditions you picked, with inputs you chose, and when it works you screenshot it and you’re done. Every demo you have ever seen is a project.

A product runs for people you have never met. Several of them at once. Under load you did not schedule, on hardware you do not control, at a latency they will absolutely notice, and it has to keep doing that at three in the morning on a Tuesday while you are asleep.

And it has to survive being used wrong. A project meets the inputs you designed for. A product meets whatever a real person does at eleven at night — the sideways video, the empty file, the button pressed twice, the thing you were certain nobody would try. Unexpected usage isn’t an edge case in a product. It is most of the usage.

The gap between those two sentences is where most of my last two years went.

The part nobody warns you about

Every model and every library you would reach for has a licence attached.

In a project this is invisible. You pip install the thing, you cite the paper if you’re feeling generous, and nobody is ever going to ask. In a company it is a real constraint with real consequences, and working out what you are actually permitted to ship — model weights, training data provenance, the transitive dependencies of a dependency — was an enormous, tedious education I did not expect to get.

I’d recommend it, in the way you’d recommend any unpleasant thing that turns out to matter.

Constraints are the interesting part

Here is what surprised me: the restrictions are where the engineering actually happens.

A library is excellent. It is also going to cost you more memory and more milliseconds than you have, or its licence means you can’t ship it, or it solves nine problems when you needed one. So you distil it. Or you read enough of it to understand what it’s really doing, and then you write the exact thing you needed and nothing else.

Almost everything I’m proud of started as something I wasn’t allowed to use, or couldn’t afford to run. Which means the constraint sends you back to first principles whether you wanted to go or not — you cannot write a smaller version of a thing you have never taken apart.

Which is an odd thing to be grateful for. In a project you reach for the best available tool and you’re finished. In a product the best available tool is frequently unavailable, and you have to understand the problem well enough to build a smaller answer to it. That forces a kind of understanding that reading never gave me.

Why it matters

A lot of engineers can build the project. Far fewer have had to make the thing survive contact with strangers, and it is a different skill that mostly gets learned the hard way.

If you are trying to decide what to work on next, and you have a shelf of projects that all ran once and worked: pick one and make it survive a hundred people. You will learn more in that month than in the previous six.