Lessons From Building Digital Creations

Across this site there are 301 tools, 90 games, 35 labs, 21 apps, 13 simulators and a handful of code libraries. Somewhere north of 460 small things, none of which took very long individually.

Building that many of anything teaches you less about the things and more about the process around them. These are the lessons that actually changed how I work, rather than the ones that sound good in a list.

Constraints are what make volume possible

The single most useful decision was made before the twentieth tool: no build step, no dependencies, nothing that leaves the browser. Plain HTML, CSS and JavaScript, served as written.

That sounds like a limitation and functions as a superpower. A tool written three years ago still works, because there is no toolchain under it to rot. No dependency has a security advisory. No lockfile drifts. When I open something I have not touched in two years, it runs.

The cost is real — no framework conveniences, no npm ecosystem, occasionally writing something by hand that a library would have given me. I have paid that cost hundreds of times and it is still the trade I would make. The alternative is 460 projects each carrying their own dependency tree, which is not a hobby, it is a job.

Pick your constraint early. Almost any coherent one beats none.

The tenth of anything is what matters

The first version of something teaches you whether it works. The tenth teaches you whether the process works.

My first few tools were each a bespoke page. By the tenth it was obvious that the ceremony around adding one — updating a list, wiring a route, adding it to the sitemap — was going to dominate the actual building. So the structure changed: each tool became a self-contained folder with a metadata file, and a scan turned the directory into the index.

tools/
  hash-generator/
    tool.json      name, description, category
    index.php      the tool itself

After that, adding a tool meant creating a folder. Nothing to register, nothing to forget, and no way for the listing to disagree with what exists.

If you are planning to build many of something, the question worth asking at item ten is not "is this one good" but "what happens when there are a hundred".

Patience is mostly about the size of the piece

Every piece of advice about persistence is true and useless. The version I actually use: if a task is frustrating for hours, it is usually too large, not too hard.

Hours lost to a bug are nearly always hours spent debugging something you have not narrowed down. The fix is not more determination, it is a smaller box: disable half the code, hard-code the value, reproduce it in isolation.

The corollary for building rather than debugging is the same. A tool I can finish in an evening gets finished. An ambitious one gets abandoned at 70% and sits in the folder as a reproach. Most of what is on this site exists because I made it small enough to complete in one sitting.

Testing, honestly

I skipped tests for a long time and I am not going to pretend that was a disaster — for a self-contained tool that transforms text in a browser, opening it and trying it is a reasonable test, and writing a suite for each of 301 would have meant building far fewer than 301.

Where it genuinely hurt was shared code. The moment several things depended on the same function, "I tried it and it looked right" stopped being adequate, because I was no longer checking one caller.

The rule I settled on: test the things other things depend on. A parser, a converter, anything called from more than one place. Leaf code that only affects its own page can be verified by looking at it.

That is not a principled position and I would not defend it in general. It is what has actually worked at this scale.

Feedback tells you what is confusing, not what to build

The useful feedback was never "please add X". It was watching people fail to use something I thought was obvious.

Tools that get used are the ones that do the obvious thing on load, with the controls that matter visible and nothing else. My early tools had settings panels and options I was proud of; they went unused, and the tools I stripped back got used more. The pattern was consistent enough that later tools started plain.

The other thing feedback taught me was naming. I started with clever names. Nobody searches for a clever name — they search for the thing they want to do, which is why the converters are now called things like "CSV to JSON Converter". That change did more for whether anything got found than any amount of polish.

The one I enforced far too late

Every one of these things needs a sentence explaining what it is. For a long time mine had a name and nothing else, which meant hundreds of pages with near-identical titles and no descriptions — invisible while building, extremely visible in how they performed.

Writing a real description for each one afterwards was tedious and mechanical and took a long evening. Writing it at the moment of building takes twenty seconds, and that is the only time you will ever know precisely what the thing does.

If you take one operational habit from this: write the description as you build, not in a batch later.

I wrote more about how that structure came together, and the constraints behind it, in creating 300+ free browser tools.

What it all adds up to

None of this is about talent or discipline. It is about lowering the cost of the next one until building becomes something you do on a Tuesday evening rather than something you schedule.

Settle a constraint, kill the ceremony around adding an item, keep each piece small enough to finish, test the shared parts, and describe things as you make them. The volume takes care of itself after that.