← All notes

Note

Architecture for small tools

1 min read architecture, tools, workflow

How I keep small internal tools simple enough to maintain.

For small tools, I optimize for the shortest path to a durable result.

The default shape is:

  1. Keep the domain model small.
  2. Push complexity to the edges.
  3. Store the minimum state needed to recover from failure.
  4. Prefer boring deployment and explicit documentation.

That means I avoid abstracting too early. If a tool only has one or two workflows, the best architecture is usually a thin route layer, a few focused modules, and a clear data boundary.

The test I use is simple: can another person read the code in ten minutes and understand where to change it without tracing through a framework maze?

If the answer is yes, the architecture is good enough.