Automations are wonderful and slightly thankless. Each one solves a specific problem for a specific team, it works beautifully, and then it is done — quietly running somewhere, saving somebody an afternoon a week, generating no further momentum.
Products are the opposite. Harder, slower to pay off, and the only thing that compounds: build it once and the hundredth user costs you almost nothing extra.
So we are building one. This is the first note in a series about it, written while it is still small enough to be embarrassing.
What we are building
The short version: an AI toolkit for the operational busywork that small teams drown in — the same category of work we automate for clients, packaged so that a team can run it themselves.
We are deliberately not naming it yet, and not committing to a feature list, because we have watched other people do that and then spend six months defending a promise they made before they understood the problem.
What we will commit to is the shape of the problem. A small team has a handful of repeating jobs: intake that needs sorting, documents that need reading, updates that need writing, follow-ups that need remembering. These jobs are individually too small to justify software, and collectively they eat a person.
Why build in the open
Two reasons, one of them selfish.
The selfish one: writing about what we are doing forces clarity. A decision that seemed obvious in a conversation turns out to have three unexamined assumptions when you try to explain it in a paragraph. We catch those in the writing, which is cheaper than catching them in the code.
The other reason is that most product writing is written backwards — after the decision, polished until it looks inevitable. That version is useless to anyone in the middle of the same problem, which is exactly where we are. So we will publish the parts that are normally edited out: what we tried first, what we threw away, and the numbers we are willing to share.
A launch post tells you what somebody wants you to think. A build log tells you what is actually true.
The rules we set before writing code
- One job, done properly. The product should do a single thing well enough that people describe it in one sentence without adding “sort of”.
- Ship before it is comfortable. A rough version in front of ten real users beats a polished version in front of nobody. We would rather have something live in days and improve it in public than announce a date we cannot defend.
- Charge from day one. Free betas attract people who like trying things, not people with the problem. A small price is the cheapest honest signal we know of.
- No roadmap promises. We will tell you what we are working on, not what will exist in March.
- If a client problem keeps appearing, that is the roadmap. Our client work is the best research we have. When three teams ask for the same thing, the product should already be doing it.
What we are not doing
We are not raising money. We are not hiring. We are not building a platform, an ecosystem, or anything with a marketplace in it. Every one of those is a way to spend a year on something other than the product.
The plan is smaller and more boring than that: find the sharpest version of the problem, build it with the two of us, put it in front of people, and let what happens next decide the next step.
Following along
New posts land on the blog and in the RSS feed — no newsletter, no popup, no tracking pixel. Posts about the product will be tagged Products, and when there is something you can actually use, it will be the loudest thing on this site.