Notes from building software

Everything here comes out of building and maintaining my own applications — performance, product decisions, AI tooling and the work in between.

• Five browser games, and what each one is for — We did not plan a genre spread. We built five games one at a time, and only afterwards noticed what they had become: not a difficulty ladder, but five different questions about what a player is good at. Here is what a small catalogue has to get right, and what we got wrong on the way. (Games, 2026-08-10)
• Scroll-driven animation with no JavaScript at all — We rebuilt our site's scroll animation on CSS scroll timelines and deleted every scroll listener, every animation library call and roughly forty JavaScript observers. Here is what the technique actually replaces, the fallback you still have to write, and the three things that caught us out. (Technology, 2026-08-04)
• What a leaderboard does to a casual game — We added leaderboards after the games were built, not before, and it changed how people played rather than how many played. Here is what a scoreboard actually does to a casual game, who it helps, who it quietly pushes away, and why we still think it was the right call. (Games, 2026-07-28)
• Agentic AI and the shape of small-team work — When a model can take actions rather than only produce text, the thing you hand over stops being a question and becomes a task. That sounds like a capability story. In practice it is a specification and verification story, and the bottleneck moves to the person doing the checking. (AI, 2026-07-19)
• A practical Core Web Vitals checklist for small product teams — Most Core Web Vitals advice is written for teams with a performance engineer. This is the checklist we actually work through on a small studio's sites — what the three metrics mean, the specific fixes that move each one, and the two mistakes that make good numbers lie. (Technology, 2026-07-12)
• Knowing when a game is finished — An endless arcade game has no end state, which means it has no natural moment where the work stops. We have hit that problem five times. Here is what "finished" turned out to mean, and why the answer applies to a lot more than games. (Games, 2026-07-02)
• SEO for product sites: structure beats volume — Search now often resolves without a click, and generated answers cite two or three sources rather than listing ten. Being the fourth-best page used to earn traffic; it now earns nothing. Here is what actually still works for a small product site, and what to measure when the click never happens. (Search & Tooling, 2026-06-28)
• What 26 small tools taught us about scope — Smart Tools Today is twenty-six utilities that each do exactly one thing, run entirely in your browser, and ask nothing of you. Here is what that constraint rules out, why "runs in your browser" is a promise worth checking, and what we learned about deciding a thing is worth building. (Technology, 2026-06-24)
• Running a network of small sites from one studio — ESPYCRUX publishes five properties — some on subdomains, one on its own domain, one unfinished. It also holds sixteen hostnames, and the gap between those two numbers is the actual subject of this article: what a subdomain costs you that a separate domain does not, and the part nobody warns you about, which is that starting is free and finishing is not. (Business, 2026-06-09)
• Where AI actually helps a small team, and where it quietly hurts — The useful test is not whether a model can do the task. It is whether checking the output costs less than doing the work yourself. That one question sorts almost every AI use case into genuinely helpful or quietly expensive. (AI, 2026-06-09)
• Pricing your first product without a finance team — Most first prices are set by finding a competitor and picking a number nearby. That method quietly imports someone else's costs and someone else's customers. Here is how to arrive at a number from what you actually deliver, why the first one is a guess, and the mechanics of changing it later. (Business, 2026-05-21)
• Security for a small team shipping to the public web — Security advice is mostly written for organisations with a security team. This is the version for a studio of a few people running a handful of public sites: what to protect first, why the domain registrar outranks the server, and what a small team realistically cannot do. (Technology, 2026-05-19)
• Choosing tools when you are five people — Tool comparisons usually score features. For a small team the features are rarely what decides it — the deciding factors are who has to live in the tool, what it costs when you succeed, and whether anyone opens it in week three. Here are the criteria that have held up across four categories of tooling. (Search & Tooling, 2026-05-05)
• AI governance for people who ship, not policy people — Governance reads like a word for other people's meetings. For a small team it is a handful of engineering decisions: knowing what you actually run, knowing what leaves your machines, and keeping a person in the loop where consequences are real. Most of it is work you would want to do anyway. (AI, 2026-04-28)