From annoyance to shipped: how a CraftlyKit project actually gets built

Most descriptions of how software gets made skip the part where ideas die. That is the most important part, because a one-person studio has exactly one real constraint, and it is not skill or tools — it is that finishing anything means not doing four other things.

So this is the actual process, including the stage that kills most of it.

Stage one: notice it twice

Nothing starts as an idea. It starts as an irritation that happens more than once.

The rule is deliberately simple: if something annoys me, I ignore it. If the same thing annoys me again, and I notice that it is the same thing, I write it down. Not a spec — one line in a running list. "Reformatting that pasted list again. Third time this week."

The list is long and most of it never becomes anything. That is fine; the list is not a backlog. It is a record of frequency, and frequency is the only signal at this stage that means anything. A single sharp annoyance is not evidence of a problem worth solving. A dull annoyance appearing on the list four times over two weeks is.

This is the same discipline as the friction sentence, applied to my own days rather than recommended to someone else's.

Stage two: the week of doing nothing

When something reaches the list several times, nothing happens for about a week.

This is not procrastination dressed up as method — it is the cheapest filter available. Enthusiasm for a new idea is at its highest in the first hours, and enthusiasm is a terrible predictor of whether a thing is worth building. A week later, roughly two thirds of ideas are visibly not worth it. The annoyance was real but rare, or the solution would be more work than the problem, or the problem was actually a symptom of something else I should fix instead.

The ideas that survive a week are not the exciting ones. They are usually the boring ones I keep coming back to because the underlying task has not stopped happening.

Stage three: decide the shape

Only now does it become a question of what to build, and this is where most of the important decisions get made.

The options, roughly in order of weight:

• Nothing — change a habit or use a keyboard shortcut that already exists.
• A single web page that does one job.
• A browser extension.
• Something larger.

The bias is hard toward the top of that list. An extension carries permissions, an update mechanism, a store review process, and a cost on every page load for as long as it is installed. A web page carries none of that. If a task can be done by pasting something into a page and getting something back, that is what it should be, and no extension should exist for it.

TabVault is one of the few that genuinely cleared this bar. Reading a page's scroll position and a video's timestamp requires being on the page at the moment you save it — a separate tab cannot see any of that — and reopening a saved set has to happen from the toolbar rather than from somewhere you would have to navigate to first.

The test for going up a level is whether the task genuinely needs to happen on the page you are already looking at, or often enough that opening a tab is itself the friction. That is a real threshold and it is not met often — most ideas that felt like extensions are web pages wearing a costume.

Games go through a parallel version of this, where the question is whether the idea survives the same constraints — small, fast on a phone, understandable in ten seconds. Plenty of good game ideas do not, and those constraints exist for a reason.

Stage four: the ugliest possible version

The first build is deliberately bad-looking and takes a day or less.

No styling beyond browser defaults. No settings. No edge cases. No name. Just the core transformation, working once, on the input I actually have.

The purpose is not speed for its own sake — it is to answer one question honestly: does this actually remove the annoyance? Surprisingly often the answer is no, and it is only obvious once the thing exists. The task turns out to have had a decision in it that the tool cannot make. Or the tool works but invoking it takes as long as doing the task did. Or the output needs checking every time, so nothing was really saved.

Projects killed at this stage are the cheapest useful failures available, and there have been a lot of them. A day spent proving an idea does not work is a good day.

Stage five: use it for two weeks before touching the design

If the ugly version survives, it goes into daily use exactly as it is. No polish yet.

Two weeks of real use produces a specific kind of information that no amount of planning does. The things that turn out to matter are almost never the things I expected:

• The default is wrong, and I change it manually every single time.
• One edge case I dismissed as rare happens constantly.
• A feature I was sure was essential has not been used once.
• The thing needs to remember one small piece of state between uses.

Building the polished version first means encoding all of those wrong guesses in code that is now expensive to change. Building the ugly version first means the polished version gets built once, correctly, against evidence.

This stage also weeds out the tools that were fun to build and are not actually useful. If I have stopped reaching for it after two weeks, it does not get shipped, no matter how much work is already in it. That is a hard rule and it hurts every time.

Stage six: build it properly

Only now does the real version get built, and the requirements are fixed:

• The narrowest permissions the feature genuinely needs, for an extension.
• Work done locally in the browser wherever the task allows it.
• No account required for the core function.
• Settings stored on the device rather than on a server.
• Works on a phone, not just on a laptop.
• Keyboard accessible, with visible focus, and respects reduced-motion preferences.

These are not negotiated per project. They are the floor, and a project that cannot meet them does not ship — which has happened, and is a better outcome than shipping something that quietly compromises on the third or fourth item.

The polish stage is also where the microcopy gets written properly: buttons that name their action, empty states that say what to do next, and errors that explain what went wrong and how to fix it rather than apologising decoratively.

Stage seven: publish, then leave it alone

Publishing is a short stage: a listing, a page on this site describing what it does and what it can see, and an entry on the projects page.

Then comes the part that is genuinely difficult, which is not adding to it.

A tool that does one thing well has a strong pull toward becoming a tool that does six things adequately. Every additional feature has a plausible case, and each one makes the thing slower, larger, and harder to understand for someone arriving new. The default answer to a feature request is no, and the bar for yes is that the feature serves the same single job the tool already does — not a nearby job that a different tool should do.

The exception is the maintenance nobody sees: browser API changes, permission model updates, a bug someone reports. That work is not optional and it is most of what a published project costs over its life.

Why this is slow, on purpose

This process produces few projects. A single idea can take two months of elapsed time to travel from the list to a store listing, and most of that time is deliberate waiting.

The alternative — building everything that seems promising — produces a lot of half-finished things and nothing anyone can rely on. A short list where each item genuinely works is worth considerably more than a long list where most items are abandoned, both to the person using them and to the person maintaining them.

If you have an annoyance that has appeared on your own list more than twice, I would genuinely like to hear it. It is the most useful kind of message this studio gets, and several things on the list started as someone else's repeated irritation. The about page has more on why this studio exists at all.