I once had an idea for an application to collect and deliver clothes through laundries. In my head, the opportunity seemed obvious: people needed clean clothes, laundries existed and an application could connect the two sides. I thought I just needed somebody to develop the technology.
When I discussed the project, I was asked to prepare a Lean Canvas first. The exercise made me think about the audience, market, costs, revenue and work required. I eventually decided against proceeding, because the demands and risks did not justify what I would have needed to give up at that stage.
Start by describing the problem independently of your solution
Describe who has the problem, when it occurs and how it is currently solved. An idea becomes difficult to evaluate when its explanation begins and ends with the application you would like to build. Separating the need from the solution helps distinguish a specific difficulty from enthusiasm for a different way of working.
For the laundry project, thinking that everybody needed clean clothes was too broad. That general need did not establish sufficient demand for collection and delivery under conditions I could offer. The idea needed to be connected to a more specific situation in which somebody would use it.
I would ask who struggles with that work, how frequently and what alternative they use. Someone might handle it at home, use a nearby laundry or organise their time differently. Those alternatives matter, even when none resembles the application you have imagined.
This care also applies when starting a business with AI support. Producing a presentation or prototype easily can help, but it does not answer the question of who needs the solution and why they would change their current behaviour.
To prepare your next step, explore Validating business ideas.
Distinguish confirmed information from assumptions to test
Completing the document does not turn a hypothesis into a fact. Mark what you know, what comes from an estimate and what still needs confirmation. The plan is useful partly because it reveals these gaps, preventing a convincing sentence from hiding the absence of information required to make a sound decision.
Writing that certain people would pay for the service differs from observing a purchasing decision under the proposed conditions. Similarly, imagining that a laundry would accept a commission does not confirm its availability, capacity or interest in participating. Each statement may require verification of its own.
I would begin with uncertainties that most affect the idea's viability. If the service depends on partners who reject the conditions, application design becomes secondary. If interest exists but operating costs seem incompatible with the price, that relationship needs to be understood before developing features.
The diagnosis before choosing a marketing plan follows the same discipline of clarification. Understanding the offer, audience and resources helps you choose the next task, instead of filling every uncertainty with what you would like to be true.
Expose the work the application cannot perform alone
Describe what needs to happen between the customer's request and completed delivery. Identify people, dependencies, exceptions and follow-up. An application can organise information and facilitate contact, but operations still require decisions and work that belong in the assessment, especially when the service depends on several parties coordinating their responsibilities throughout the process.
For the clothing collection example, I would now ask who receives the request, arranges the time, follows the collection and confirms delivery. I would also examine how to handle a change or a request that cannot be fulfilled. These are analytical questions, not events I claim to have observed in a launched business.
Technology can solve part of the coordination, but it does not make these responsibilities unnecessary. Before choosing features, understand who has decision authority and what information they need. Otherwise, you may build a polished interface for a process whose execution nobody has accepted responsibility for.
That is why planning an application before starting to code requires more than a list of screens. Business operations guide the requirements. An important operational uncertainty does not disappear simply because you can already demonstrate the visual journey of a request.
Connect revenue, costs and resources without hiding uncertainty
Place the way you earn revenue alongside the resources required to deliver the service. Distinguish costs per operation, structural commitments and the time of the people involved. Work with scenarios labelled as estimates, so you can understand which conditions support the proposal and which make it incompatible with your own limits.
Receiving a commission on every request can seem simple when you look only at revenue. The analysis changes when you add customer acquisition, coordination, support and service maintenance. These costs will not necessarily behave identically as volume grows, so explaining the assumptions matters.
The timing of resource requirements matters too. An idea may require work and commitments before generating enough revenue to support them. Looking at a future scenario with many customers is insufficient without understanding the path needed to get there and what could happen differently along the way.
In my case, preparing scenarios made the effort, time and priority the project would demand more visible. The conclusion concerned that opportunity and my situation. It did not establish that nobody could make a similar service work under different conditions or with other resources.
Compare the idea with what you would have to give up
An opportunity must be compared with existing commitments and realistic alternatives for your time. Ask which project would slow down, which responsibility would need to change and how much involvement the new idea would demand. The decision can be negative even when you recognise value in the problem and the proposed solution.
That comparison weighed heavily in my decision. I already had projects where I could pursue growth with greater predictability and did not want to give the new operation the priority it seemed to require. I still recognised merit in the idea, but that was insufficient to justify executing it then.
This differs from asking whether the market is large. A broad market does not automatically increase your capacity to manage another operation. The same project may suit a dedicated team while becoming an unsustainable distraction for somebody with competing responsibilities.
Avoid treating every abandoned idea as a failure of courage. Sometimes the analysis simply clarifies a choice you had not yet expressed. It is also useful to distinguish that conclusion from rejecting a difficulty that could be investigated through a limited test and understood without a major commitment.
Finish with a decision and conditions for reviewing it
The outcome may be to conduct a limited check, reformulate the proposal, postpone it or abandon the idea. Record the reason and the assumptions that influenced the choice. A completed Lean Canvas guarantees neither success nor failure; it helps make explicit what you are accepting, what remains unknown and what you are prioritising.
I decided not to develop that project. I cannot say how it would have turned out if I had proceeded, because that experience never happened. The exercise's value lay in clarifying the work and sacrifices required, enough to choose where I wanted to concentrate my resources.
If the decision is to postpone, state what would need to change before revisiting it. That could be team availability, an operational condition or information about demand. Without that note, it is easy to return to the same idea months later and repeat the initial excitement without using the reasoning already completed.
Keep the document as a record of the decision, preserving its uncertainties. Planning has served its purpose when it lets you choose the next step with greater awareness of the conditions. Sometimes that step is continuing to develop what you already have, without adding another project.