On Minimal Tooling

There is a version of minimal tooling that is ascetic for its own sake — a refusal of complexity as a philosophical position. This is not that argument. The case for minimal tooling is pragmatic. Every tool in a stack is a dependency, and every dependency has a cost that compounds over time.

The cost takes several forms. Maintenance: dependencies release new versions, introduce breaking changes, and eventually reach end of life. Security: dependencies have vulnerability histories that require monitoring and patching. Cognitive: each tool has a mental model, a configuration surface, and failure modes that the operator must understand. Operational: each tool is a potential point of failure in the build or deployment pipeline.

These costs are often invisible when a stack is new. The tools work, the versions are current, the mental models are fresh. They become visible over time. A publishing system built in 2020 with ten dependencies will, by 2026, have deprecated packages, security advisories, and configuration patterns that no longer match current documentation. The maintenance debt is the accumulated cost of dependency.

Minimal tooling is not zero tooling. It is deliberate selection — choosing dependencies whose value clearly exceeds their maintenance cost, and declining dependencies whose value is marginal. For a publishing system, the non-negotiable dependencies are a Markdown renderer and a deployment tool. Everything else is optional.

Flatpack's dependency list is two packages: marked and wrangler. Marked converts Markdown to HTML. Wrangler deploys to Cloudflare. Every other feature — frontmatter parsing, pagination, RSS generation, sitemap generation, HTML templating — is implemented in plain JavaScript with no external dependencies.

This is a deliberate constraint. The cost of adding a dependency is visible. The benefit must be proportionate.