Start with an outcome, not a stack

A framework is an answer. Before choosing one, make sure you have a question. The first useful artifact is often a paragraph, not a repository.

Write the change you want

Use this sentence:

For this person, make this activity easier, so this outcome becomes possible.

For a workshop site, that might be: “For a builder learning Hugo, make a working example easy to inspect, so they can adapt it without guessing how it works.” Notice what is absent: a CMS, a database, an AI agent, and a hosting provider. Those choices can wait.

Give the outcome a boundary

Write down three constraints before implementation:

• Ownership: what must the builder be able to take away?
• Effort: what can they reasonably maintain?
• Risk: what must the system never expose or destroy?

Constraints are not the enemy of creativity. They make architectural choices comparable. “The content must remain readable without our application” is more useful than “the system should be future-proof.”

Choose the smallest observable result

A result should be something you can inspect. For this example: a reader can find an article, run its example, and explain the important tradeoff.

Do not substitute an activity metric for that outcome. Ten published articles prove that ten articles were published, not that anyone understood them.

Make a one-page brief

Person:
Activity:
Desired change:
Constraints:
Smallest useful demonstration:
Evidence that would change our approach:

Fill it in with plain language. If an answer is unknown, say so. Keep the brief beside the work, and revise it when evidence changes your understanding.

Try it: write the brief for one thing you want to build. Remove every product or framework name. If the intention disappears, you may have started with a tool instead of a problem.