Zhou Yi'an's blog

Year three of going indie: I deleted 60% of my features

Sun, 02 Aug 2026 00:00:00 GMT

This summer I did something that felt wrong: I deleted 60% of Beacon's features.

How it started

One night I exported a year of usage logs and counted clicks per feature. The result was quiet. The bottom 60% of features, added together, made up less than 5% of all usage. I had spent a week or two building each of them, and every one was quietly eating maintenance time.

How I cut them

Deleting is harder than adding, so I set three rules:

Hide the entry point first, keep the code. If nobody asks about it for two weeks, then I touch the code.
Old users can always export their data. Removing a feature should never make someone feel abandoned.
Write one sentence explaining each removal. If I can't explain why, I haven't thought it through, so it stays for now.

What happened next

Pages loaded twice as fast, support email dropped by a third, and the surprise was that renewals went up by two points. My theory is that the product finally looked like it was doing one thing.

There were regrets too. One customer wrote in asking where a small feature had gone, so I brought it back, just for him. That's fine. The nice thing about being independent is that you're allowed to change your mind for a single person.

Offline natural-language bookkeeping in a WeChat mini program

Thu, 09 Apr 2026 00:00:00 GMT

The most loved feature in Shiguang Ledger is one-sentence bookkeeping: type "taxi 35 yesterday" and it figures out the date, category and amount. Plenty of people assume a large language model is behind it. It isn't. It's a rule-based parser of about 200 lines that runs on the phone, fully offline.

Why not an LLM

Logging an expense is frequent and low-stakes. If a call takes half a second longer, costs a fraction of a cent, or needs a connection, people get annoyed. Financial notes are also sensitive, so I'd rather they never leave the device.

Three layers

Amount. Find the number that looks most like a price, and cope with forms like "28.5", "twenty-eight" written out, or "two hundred bucks".
Date. Turn "yesterday", "last Friday" or "the night before last" into a real date, defaulting to today.
Category. A word list of just over 300 entries, matched longest-first. Anything unmatched goes under "Other", and the parser remembers how the user files it later.

export function parse(input: string, now = new Date()) {
  const amount = extractAmount(input);
  const date = extractDate(input, now);
  const category = matchCategory(input) ?? learned.get(input) ?? "Other";
  return { amount, date, category, note: input.trim() };
}

The biggest lesson

Learning matters more than recognizing. Once someone corrects a category, the same phrase is right the next time. After three months accuracy went from 82% to 94%, and the credit goes to users' own habits rather than a cleverer algorithm.

Mini programs have strict package size limits, and the whole parser minifies to under 8KB. For me that is its best feature.

SQLite is enough: notes on single-file deployment

Thu, 26 Feb 2026 00:00:00 GMT

The goal for Yehang was simple: let someone run an RSS reader on the cheapest server they can find, with one command. No Redis, no Postgres, no message queue. So from day one I chose SQLite.

A few settings you should always turn on

SQLite's defaults aren't made for web services. These lines are close to mandatory:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA busy_timeout = 5000;
PRAGMA foreign_keys = ON;

WAL mode lets readers and writers stay out of each other's way. That is what lets Yehang fetch feeds in the background while you read in the foreground.

Backups are easy

People worry that a single file is unsafe. Yehang runs a scheduled job that uses VACUUM INTO to write a consistent backup every day and keeps the last seven. Restoring means copying a file back. Compared with running a database server, there is far less that can go wrong.

Where it stops

I drew a line for myself: one user, or a small group of a few dozen, with low write concurrency. If someone ever needs to scale out across instances, Yehang will have become a different product, and I can switch then.

It has run in under 40MB of memory for a year without a single data problem. For a side project, that's enough.

Taking tidemark's build from 38 seconds to 4

Fri, 18 Sep 2026 00:00:00 GMT

tidemark is a small tool I maintain that turns Markdown into HTML you can paste straight into WeChat articles. There isn't much code, but the build took 38 seconds in CI, and even a one-line theme tweak meant waiting over ten seconds locally. For a tool whose whole job is tweaking styles, that feedback loop is fatal.

Measure first

I didn't reach for a new bundler. I put timestamps around each stage first:

time pnpm build --reporter=verbose

The result was humbling. Actual compilation took only 6 seconds. The rest went to two things: re-parsing the CSS for all 12 themes on every run, and bundling test snapshots into the output.

Three fixes

Precompile the themes. Theme CSS is compiled to JSON before publishing, and at runtime it's only read. That saved 19 seconds.
Stop bundling what doesn't belong. Snapshots and fixtures were removed from the build entry, and the output shrank by 70%.
Incremental caching. The cache key is a hash of file contents, so unchanged themes are reused, and local hot reload dropped to around 300 milliseconds.

A small lesson

Looking back, the biggest win came from doing less rather than doing things faster. Most slow builds repeat work that never needed repeating. Next time a build feels slow, don't swap tools yet. Look at the timestamps first.

CI now holds steady at about 4 seconds, and I can finally finish tweaking a theme before my coffee goes cold.

Five gotchas from running multi-region probes on Workers

Sun, 21 Jun 2026 00:00:00 GMT

Beacon needs to check customers' endpoints from several regions at once, and Workers is a natural fit: deploy once, get nodes everywhere. But a natural fit isn't the same as a smooth one.

Gotcha one: probes get blocked as bots

Many customers have a WAF in front of their API. We now send probes with a fixed User-Agent and link to a public page listing our IP ranges, so customers can allowlist us in one click.

Gotcha two: CPU time is not wall-clock time

A probe may wait 8 seconds for a response, but that wait doesn't count as CPU time. Parsing a large response body does. So we only read the headers and the first 4KB, which is plenty to judge the status.

Gotcha three: don't trust local clocks

When results from several regions are merged, node clocks drift slightly. We sort by the time the central node received each result, and use node timestamps only to compute durations.

Gotcha four: retries need a cap and a delay

const delays = [0, 1500, 4000];
for (const delay of delays) {
  await sleep(delay);
  const res = await probe(target);
  if (res.ok) return res;
}

Three failures in a row count as a real outage. Otherwise a single network blip wakes a customer at 3 a.m.

Gotcha five: alert fatigue

If you notify about the same incident every minute, people mute you quickly. Now it's one message when an incident starts, one reminder after 30 minutes, and one when it's resolved. That's all.

The biggest lesson from building a monitoring product: bothering users less is harder than detecting more problems.