Shipping BatchTone: 25 commits, three days

What this is

Every other post here about building alone is a how-to. This one is a receipt.

Day one: six hours to a working thing

The first commit is called LUTFlow prototype: batch LUT with per-file strength. That name is worth noting twice: once because it is not the product's name, and once because the per-file strength was in the very first commit rather than added later. It was the reason to build it at all.

The second commit adds pixel tests for the shader. That is unusual for a prototype and it paid for itself immediately: a colour transform that is subtly wrong looks plausible, and without a test you find out from a customer.

Then, within 33 minutes:

19:11  Add a persistent LUT library with a preview grid
19:20  Fix the freeze when importing a real LUT pack
19:34  Fix the LUT grid freezing the app when opened
19:44  Stop previews vanishing: own the image handles you keep

Three bugs in half an hour, all the same kind: the thing worked on one file and fell over on a real folder. That is what real data does to a prototype, and it is the argument for pointing it at real data on the first evening rather than the first week.

By midnight, video was in and the encoder question was settled: prefer the operating system's hardware encoder over a software one, because a card of footage should not be an overnight job.

So: a working product in an evening. This is the part people mean when they say a small tool can be built in a day, and they are right. They are also describing about a quarter of the work.

Where it stopped being about the code

Commit 12, roughly two-thirds of the way through day two:

Licensing, packaging and the legal paperwork for selling

Before the icon. Before the name. Before any of the things that feel like finishing a product. Then:

01:39  One product, one price: 7 days of the whole app, then a licence
02:10  Rename to BatchTone, and write down what the brand is

The price was decided before the name. That order is not an accident and it is the opposite of how most side projects go. People name the thing in hour one, design a logo in hour two, and discover in month three that they never decided what it costs or who buys it.

Deciding the commercial shape first meant the name had something to describe. LUTFlow described a mechanism; BatchTone describes what it does for you.

The last mile is longer than it looks

Day three is almost entirely distribution:

Keep signing credentials out of the repository
Build ffmpeg for macOS 12 on Apple Silicon, not for this machine
Cover, thumbnail, and a packaging run that actually completes
One command to cut a release, and a way for the app to notice
Sign the disk image, not just the app inside it

Two of those are worth pulling out.

"Not for this machine" is the works-on-my-machine trap, caught before release rather than after. A dependency built against whatever your laptop happens to have will refuse to start on a customer's older OS, and you will hear about it as a refund.

"Sign the disk image, not just the app inside it" was found on release day. Signing the app is the step everybody knows about; the container it arrives in is a separate signature, and macOS will complain about the one you forgot.

Neither of those is interesting. Both of them are release day.

What it cost, honestly

That ratio is the whole point, and it is the same claim how long it takes to build an app alone makes in the abstract: that the feature is about a third and the rest is the unglamorous machinery. Here is one instance of it with timestamps.

What made three days possible

Not speed. Three decisions, all of them subtractive:

1. One job, one kind of person. A LUT, across a folder, on a Mac. No library, no catalogue, no cloud, no accounts. Scoping an MVP you can finish is that cut, and the version here was brutal.
2. A price, not a plan. One product, one payment, a seven-day trial of the whole thing. No tiers to design, no metering to build, no upgrade path to reason about, which removed days of work that a subscription would have demanded. Pricing for solo founders covers why that is a product decision and not a marketing one.
3. The boring work early. Licensing at commit 12 rather than commit 24. Doing it early meant the release was a release, not a discovery.

What it does not prove

It would be dishonest to leave this as a three-day success story, so:

Three days is the build, not the business. A shipped product with no users is a shipped product with no users, and the distribution work starts now, which is the slower half and the one the Income Loop is actually about.

It is short because it is small. One job, one platform, no accounts, no server. Anything with users, sync or a backend is a different order of work; that is most of what building a SaaS alone covers and almost none of it applied here.

Fifteen years of doing this made the six hours possible. Someone learning Flutter and code signing at the same time is not slow; they are doing two things.

The transferable part is not the speed. It is the order: real data on day one, the commercial shape before the name, and the unglamorous work before the icon.

You can try BatchTone for seven days, and the build is being written up as it goes the same way everything else here is.