What I write down before I build

Code makes an idea look more certain than it is. Before I build, I write down the parts that can still change the shape of the project.

The user and the repeated job

I start with one person and one job they repeat. “A tool for developers” is too broad. “A tool that shows a frontend engineer which component caused a slow render” is specific enough to test.

The job also sets the boundary. If the user can finish it with a shell command or a browser feature, the new product needs a better reason to exist.

The source of truth

Every important value needs one owner. A cache can copy data, but it cannot quietly become the authoritative version. The same rule applies to configuration, UI state, and generated files.

When two systems both appear to own a value, I write down which one wins after a retry, a partial failure, or an old client reconnecting.

The failure that changes the design

Some failures only need an error message. Others change the architecture.

If a failed write can lose money, corrupt data, or trigger the same external action twice, the operation needs a durable identity and a safe retry path. That decision belongs near the start, not in a cleanup pass.

What I am deliberately not building

A short exclusion list is useful. It prevents a small tool from collecting accounts, dashboards, plugins, and collaboration features before the core job works.

The list is not permanent. It records what the current version does not need to prove.