Choose a first app you can actually finish

Write three candidate tasks

List small tasks people currently complete using a document, form or spreadsheet. For each, name the person, the input and the useful output. “Organize everything for my business” is too broad; “record a request and show its review status” is specific enough to test. Choose examples you understand well enough to notice an incorrect result, rather than an unfamiliar industry with attractive marketing potential.

Identify the hardest dependency

For each idea, circle the dependency that could stop a useful first version: account approval, private data access, payment processing or a complex external integration. A project with fewer dependencies is usually easier to evaluate responsibly. This is a planning heuristic, not a success prediction. A dependency is not solved merely because a service appears in the builder’s integration directory or public roadmap.

Define a small finish line

Write a finish line that includes the awkward case. For a calculator, that means useful results and sensible behavior for missing or invalid inputs. For a tracker, it includes persistence after reload and an understandable correction route. Name the features deliberately excluded. If the definition needs several unrelated user journeys, shrink the first version until one person could verify it in a short structured session.

Pick the most reversible experiment

Favor a project that can use fictional data and can be abandoned without disrupting anybody’s work. Keep the original workflow available while you evaluate the replacement. Before paying for a plan, check account access and the current offer, then set a separate evaluation allowance. The goal is to learn whether a narrow implementation is useful, not to prove that every idea must become a custom application.

• Choose one explicit reason to abandon the experiment before committing money, private data or another person’s workflow.