Hello, this is Kikoman

I work full-stack and touch whatever a project needs: frontend, backend, mobile, desktop, AI. After enough of them, the valuable thing is rarely a specific implementation — it’s a reusable sense of judgment: what to buy, what to fork, what to build from scratch. This blog is where I keep track of that judgment, not a running log of what shipped.

Three questions, not three options

When a new requirement lands, I rarely open an editor first. I ask three things: is there a mature, off-the-shelf way to get this capability? If there is, how much cheaper is adapting it than rewriting it? If there isn’t, is what’s missing the capability itself, or just a coat of paint to match my system?

The three questions map to three paths, but they aren’t parallel choices — they’re a funnel:

Buy: the capability is generic, and someone else has already hit the edge cases. Font-subsetting tools, browser-automation frameworks, payment gateways — I use the off-the-shelf version for all of these. Writing my own would just mean re-hitting bugs someone already fixed.
Fork: the kernel has already been proven somewhere else, and only the shell — brand, content, some local logic — needs to change. This is the most underrated path, because it doesn’t look like “your own work,” but it’s the highest-leverage one.
Build: no existing option meets the constraints, or the thing itself is the capability I’m delivering. This is the most expensive path, and it should only be taken once the first two are ruled out.

A real example: from Langfu to Kikoman

Langfu is an energy-efficiency company, and its site came with specific constraints: bilingual Chinese/English, a dark “instrument”-style design system, a first screen built on a bespoke generative effect instead of a templated one. Nothing off-the-shelf in the open-source world met that brief, so that project was built from scratch, top to bottom — color, type, copy and components all defined single-source, dark/light as one token flip, visual regressions caught automatically by a Playwright pipeline.

The site you’re reading didn’t repeat that process. Kikoman is a fork of that same kernel: everything that needed proving had already been proven — the single-source architecture, the bilingual routing, the visual-QA pipeline. What changed was the brand color and the content — phosphor purple replaced the original orange signal system, and the copy became mine. If I’d treated Kikoman as a new build from scratch, the extra time wouldn’t have bought a better site — it would only have re-proven what Langfu already proved.

The judgment is the asset

A specific implementation goes stale — frameworks get swapped, taste shifts, requirements iterate. But the standard for when to buy, when to fork, and when to build holds across ten different projects. That’s what this blog tracks — that judgment, and the times I got it wrong.

I won’t post often, but I’ll try to only post things with signal.