Writing novels takes most of my working hours. But I also write code — and it turns out the two habits feed each other more than I expected when I started. Researching a series means learning just enough about a subject to write it convincingly; building a tool means learning enough to actually ship it. The tools below all started the same way the books do: a specific, annoying problem I ran into personally, followed by the decision to just fix it myself instead of waiting for someone else to.
Here's a real, current rundown of the three I've actually shipped and still personally maintain.
WhatSphere
WhatSphere is an audience analytics platform, and it exists because of a question that kept coming up every time I talked with other writers and a few people on the publishing side: who actually reads which genres, and why does everyone seem to be guessing instead of checking?
The usual answer to "who reads horror" or "who reads cozy mysteries" is a shrug and a stereotype. WhatSphere replaces the shrug with real demographic and psychographic data, broken down by genre and subgenre rather than lumped into one undifferentiated "readers" bucket. Writers use it to figure out where their actual audience overlaps with the audience they assumed they had. Publishers and studios use it for the same reason marketing teams anywhere want real data instead of gut feel — because gut feel is expensive when it's wrong.
The platform is built around what I'd call sphere scoring: a way of quantifying audience fit and overlap across properties without pretending that a single number can capture something as messy as taste. It is explicitly not a quality rating. Two properties can score similarly on audience fit while one is objectively better written than the other — the score describes who's likely to show up, not whether the thing deserves them. Keeping that distinction honest was one of the harder design decisions in the whole project, because "just give me one number" is a constant temptation and usually the wrong answer.
The platform surfaces its findings as data stories and insight write-ups rather than raw spreadsheets, because a chart nobody reads doesn't change anyone's marketing plan. The goal has always been data a person will actually act on, not just archive — a dashboard nobody opens twice has failed at its one job, no matter how accurate the numbers underneath it are.
DecodeGov
DecodeGov turns raw federal spending data into something a person can actually read without first learning what a CFDA code is. Enter a ZIP code and see where your tax dollars actually go. Compare your salary across two cities, adjusted for cost of living, using the Bureau of Labor Statistics' own wage data. Check local air quality using the EPA's monitoring network. All of it comes from public government APIs that are, technically, open to anyone — and practically unusable by anyone who hasn't spent a weekend reading undocumented query-parameter formats.
That gap between "technically public" and "actually usable" is the entire reason DecodeGov exists. The project currently runs eleven separate data adapters across six federal agencies and sources, translating each agency's particular flavor of bureaucratic API into a single consistent interface a normal visitor can just click through. I've written the full build story elsewhere — how DecodeGov actually came together, including the specific API quirks that ate an entire Saturday night — for anyone who wants the technical detail rather than the summary.
Swiss Army Dev
Swiss Army Dev is 37 developer utilities running on Cloudflare Workers — JSON formatters, JWT decoders, hash generators, the kind of small tool every developer needs a few times a week and usually finds by googling. Everything runs client-side or inside V8 isolates with no server-side logging, which sounds like a minor technical detail until you remember that a popular JSONFormatter tool once leaked roughly 80,000 files' worth of developer credentials because it quietly logged everything pasted into it. I wanted tools I could actually trust with real tokens and real data, and when I couldn't find enough of them, I built the rest.
No tracking, no cookies, no accounts, no ads — your input never touches a traditional server at all. I go through the full list, tool by tool, and which ones I personally reach for daily versus a couple of times a month, in 37 Developer Tools That Don't Spy on You.
Built the Same Way
All three share a few of the same instincts under the hood, even though they solve completely different problems. Each one leans hard toward the client side and the edge rather than a traditional server — Swiss Army Dev's tools run entirely in-browser or in Cloudflare's V8 isolates, DecodeGov's adapters are stateless translators sitting in front of government APIs rather than a data warehouse I'd have to maintain myself, and WhatSphere's analytics pipeline is built to answer a query in the time it takes to read the answer, not batch-process it overnight. None of that is an accident. Every one of these projects started because an existing tool was slow, invasive, or both, and the fastest way to prove a faster, less invasive version was possible was to actually build one.
Which One to Start With
If you only check out one of these, let the reason you clicked this post decide. If you write or publish and want real audience data instead of guesswork, start with WhatSphere. If a specific public dataset has ever fought you the way USAspending.gov fought me, DecodeGov is built to make exactly that kind of question painless. And if you're a developer who has ever pasted something sensitive into a random web tool and wondered where it actually went, Swiss Army Dev is the one to bookmark — you'll probably end up using more of the 37 tools than you expect.
Why These Exist Alongside the Books
None of these three started as a business plan. Each one started as me hitting a wall — a publishing question nobody could answer with real data, a government API that fought back for a weekend, a JWT decoder that wanted to phone home with my session tokens — and deciding the fastest path past the wall was to build my own door through it.
That's also, more or less, how the books get written. A question I can't stop turning over becomes a plot; a wall I keep hitting becomes a tool. The instinct underneath both is the same one: if the thing that should exist doesn't exist yet, go make it.
All three are live and free to use today. If any of them are useful to you, I mean that as more than a sign-off — I read the emails, and hearing what's actually useful shapes what gets built next. WhatSphere gets a new sphere score or dataset most months. DecodeGov picks up a new agency adapter whenever an interesting dataset turns out to be reachable. Swiss Army Dev's tool count keeps climbing for the same reason it started: someone, usually me, hits a wall a thirty-eighth tool would solve, builds it that weekend, and ships it the same way as the other thirty-seven.
Join the Discussion