16 Tools in One Day: The Pipeline That Made a Tool-Site Sprint Boring

My tool site had five product lines planned across ten days of work: an AI-crawler robots builder, a suite of Chinese national-format validators, a Chinese-text toolkit, and an international line ending in a passport MRZ parser. I shipped all sixteen tools in one day.

This post is not "look how fast I am." It's the opposite: the speed came from making the work boring — research finished before coding started, and a registration pipeline so mechanical that each tool stopped being a project and became a data point.

The math that made it compress

The first tool took 40 minutes. The last took 15. Same person, same day, same quality bar (every tool shipped with bilingual docs and tests). The difference is marginal cost: tools in a product line share everything.

Each tool is the same six-step assembly:

1. Pure logic module — checksum algorithms, parsers, generators. Zero framework code, zero network
2. Round-trip tests — generators feed validators; validators must accept every generated sample and reject every tampered one
3. One UI component — mostly a shared shell with a format parameter
4. Five registration points — tool registry, category map, summaries, guides, i18n strings
5. Bilingual deep guide — algorithm explainer, capability boundary, red lines
6. Deploy + verify — both locales return 200, feature phrases in the SSR HTML, sitemap entry present

Steps 1-3 are where the thinking lives, and thinking is per-product-line, not per-tool. Once the Chinese-format library had ID cards (weights table, MOD 11-2), credit codes and plates were 20-minute variations on a tested pattern.

Research as a decision-elimination device

The unsung half: five rounds of market research happened before any code, and they ended not with ideas but with a module-level spec. For every tool: the national standard it implements, the exact checksum algorithm, what it will refuse to do (a red-lines section per tool), batch order, and a "verify before building" list.

The rule that mattered: if a research item still says "to be confirmed," it is a gate, not a suggestion. One batch stayed unbuilt until the plate-number standard's new-energy position rules were pinned down. That felt slow on day one and saved the whole batch on execution day — zero decisions remained to make while coding.

Research also killed duplicates before they cost anything: a grep of the tool registry showed a generic robots.txt editor already existed, so the AI-crawler tool was scoped as a decision layer on top (12 crawlers with purpose notes) rather than a rebuild.

The round-trip test pattern

Every generator ships with the same loop: generate → validate → tamper → reject. Generate N samples, assert the validator accepts all of them, flip one digit, assert rejection. This pattern caught real bugs that code review missed:

• The new-energy plate generator produced serials containing a second D/F — legal-looking, spec-illegal; the validator was right, the generator was wrong
• The IMEI generator borrowed the EAN checksum weights instead of Luhn — every generated number was subtly invalid

Both surfaced within minutes of writing the loop. A "generate and eyeball" workflow would have shipped both.

The honest costs

Three things bit during the day, all fixable but worth pricing in:

• String-escape landmines in data files. A literal \u inside a single-quoted TS data file is a valid Unicode escape — my static-site generator parsed that file with new Function and the build died. Same family: MDX treats <10 as JSX and silently drops the post. Static pipelines fail silently; verify artifacts, not builds.
• Registration is five places, not one. I have tests that fail when a tool is missing from the category map, which is the only reason a tool didn't ship 404-ing. Checklists beat memory at 2am.
• The verify step must be per-locale. English pages render differently (different guides, different feature phrases); one locale passing proves nothing about the other.

What "done" means for a tool here

A tool isn't shipped when the code works. It's shipped when: both locales serve 200 with the guide rendered in the SSR HTML; a sitemap entry exists; the round-trip tests are green; and the guide states what the tool won't do — format validation is never identity verification, generated numbers belong to no real person, and a passport MRZ parsing cleanly doesn't mean the passport is genuine. That last one is a legal boundary, and writing it into every guide is part of the pipeline, not an afterthought.

Try it

Shipped tools are live on ToolVault — the robots.txt generator (AI crawler preset included) and the China test-data generator are good starting points; round-trip the generator against validators such as the ID card validator. The international line shipped too: a passport MRZ parser, a China plate validator, and an llms.txt builder.

If you're building a multi-instance product (validators, converters, formatters): write the research until it's a spec, make registration a checklist, and let round-trip tests carry the quality bar. The sprint stops being heroic and starts being boring — which is exactly what you want.

(Part of a series on running a 100%-local tool site solo — the previous post covered a 24-article content sprint and its three-day feedback lag.)