From everyday friction to your first build

Start with a moment, not a technology

Imagine a teaching fellow spending Friday afternoon reconciling a fictional teaching rota. The useful problem is not “we need an AI app”. It is “I want to see which teaching sessions still need a facilitator”. State who struggles, what they are trying to do and what a successful result looks like. This is problem framing: the same discipline you use when separating a presenting complaint from a useful working problem.

Make the first version small

A first version might list four synthetic teaching sessions, filter them by facilitator status and let you assign a fictional colleague. Exclude live calendar integration, messaging and patient information. These exclusions keep the first build understandable and give you a visible result before external dependencies complicate the work.

Define evidence before asking an agent to build

Write acceptance criteria that someone else can check: “When I filter for unassigned sessions, only sessions without a facilitator appear”; “Refreshing the page preserves a saved assignment”; “An empty result says there are no unassigned sessions.” An agent can produce code quickly, but you remain responsible for deciding whether the result solves the problem.

Your first artifact

Create a README with Problem, User, First version and How we will know it works. Keep the product administrative or educational while you learn. Our examples use invented names and records throughout.