Problem-First Project Generator

Useful projects usually begin where somebody is already adapting, waiting, repeating work, accepting avoidable risk, or stitching together a workaround. The first task is not to invent an idea. It is to notice friction that already changes someone’s behavior.

A frustration is more promising when it recurs in a recognizable situation and matters enough that people spend time, money, attention, or trust coping with it. Novelty can come later. Reality comes first.

“People struggle with organization” is too broad to investigate. “A first-time homeowner cannot find the permit, warranty, and repair history when a leak appears” points to a person, a moment, and a job that needs to be done.

Specificity is not about shrinking ambition. It gives you somewhere honest to begin. Different people can experience similar symptoms for different reasons, and a tool that helps one situation may burden another.

Evidence can be modest: a direct observation, a request for help, a repeated public complaint, a measurable delay, or a workaround that people maintain. None proves a market by itself, but each is stronger than a plausible story invented after the fact.

Assumptions are not failures. Hidden assumptions are. Label what you believe but have not verified—how often the problem occurs, whether people would change behavior, or whether the proposed improvement is worth its cost—so the project can test the right uncertainty.

A workaround is evidence that the problem matters, but it is also a compact design history. Spreadsheets, group chats, sticky notes, and manual reviews often survive because they are flexible, inspectable, familiar, or easy to abandon when circumstances change.

Do not ask only why the workaround is bad. Ask what it protects. A replacement that saves ten minutes but removes judgment, trust, or reversibility may be worse than the friction it eliminates.

“Build an app” is an implementation decision, not an outcome. A useful change sounds like less duplicated work, a decision made with better evidence, a safer handoff, a shorter delay, or a record that remains understandable after the original person leaves.

Add non-goals and boundaries early. A project can reduce one cost by moving it onto someone else, make a process faster while making it less accountable, or create maintenance work greater than the original pain.

The smallest experiment is not always a miniature product. It might be a structured interview, a paper workflow, a manually delivered service, a sample dataset, or a narrow prototype used once in the real situation. Its job is to produce information, not merely look buildable.

Decide in advance what success would look like and what result would make you stop, narrow, or reshape the project. A test that can only confirm enthusiasm is promotion, not learning.