Why we build products we're willing to run for years
Most software is judged on launch day. We think the better test is whether you still want to maintain it in year three.
Most software is judged on launch day: the first screenshot, the announcement, the first week of downloads. We think the more honest test comes later. Do you still want to maintain the thing in year three?
Start with who will carry it
Every product we start at BitKettle has the same unglamorous constraint: we operate it ourselves. There is no handoff to another team and no statement of work that ends at release. That changes decisions early. You pick the boring dependency over the clever one. You write the logging before you need it. You think about what the support inbox will look like while you're still drawing the first screen.
Own it end to end
Research, design, engineering, and operation live under one roof. Feedback loops stay short because the person who designed a confusing screen and the person who can fix it are often one conversation apart. Nobody can say "that's in the other team's backlog", because there is no other team.
Let each product be itself
A habits app and a mobile game shouldn't feel alike. Our products keep their own names, looks, and voices, and BitKettle provides the craft behind them: the engineering standards, the design care, and the way we run things after release. The common thread is the quality of the work, not a shared logo on every screen.
What this costs us
- We say no more often. An idea has to be worth years of attention, not just a quarter of it.
- We ship fewer things. We would rather stand behind a small set of products than maintain a long list we've quietly stopped caring about.
- We move carefully early. Decisions that are cheap to make on day one are expensive to unwind on day one thousand.
What it buys
Products that are easier to improve, because we understand them all the way down. Fewer surprises after launch. And a team that's still proud of the work long after the announcement is forgotten.