Finding the Right Problem to Solve Before Building an App
A useful app rarely starts with the words “I want to build an app”. It usually starts with a repeated frustration, a missing feature, a messy workflow or a problem that existing products do not solve in the way you need.
Before thinking about AI tools, code, design or app stores, the first question is simple: what problem is actually worth solving?
Start with the need, not the app
Many people start too broadly. They begin with ideas like “I want to build a fitness app”, “I want to build a booking app” or “I want to build a productivity app”. Those ideas are not wrong, but they are too wide to build from.
A better starting point is to ask what is difficult, repetitive, annoying or poorly served by current options.
A strong app idea does not need to be completely original. It can improve an existing process, remove friction, combine features that are usually separate, or make something simpler and more private.
The aim is not to invent a huge platform straight away. The aim is to notice a problem clearly enough that the first version has a purpose.
Your own frustration can be a valid starting point
An app idea can begin with something you personally need. That does not make the idea weak. In many cases, it is useful because you understand the problem from the inside. You know where the friction is, what you have already tried, and what existing tools do not quite get right.
The key is to test whether other people experience a similar issue.
A personal tool can become more useful when it is shared, tested and improved through feedback. Early users often reveal what is confusing, unnecessary or missing.
The goal is not to build for everyone immediately. The goal is to solve one clear problem well enough that a specific group of users can understand its value.
The SetHarbour origin story
SetHarbour started from a practical training problem.
I wanted a workout tracker where interval training could be built into gym plans, instead of being treated as a completely separate feature. I could find workout trackers, and I could find interval timers, but I struggled to find something that brought those ideas together in the way I wanted to train.
That was the starting point.
From there, the product thinking developed further. If the app could work offline, there was no reason to force account registration. If the data could stay on the user's device, there was no need for unnecessary tracking. I also disliked the idea of long-term subscriptions for features that felt more suited to a one-time unlock.
So the problem became clearer:
Workout tracking + gym plans + interval timing + offline privacy + fair unlock model
The first problem was practical. The wider values around privacy, simplicity and pricing grew around that problem.
Read more about SetHarbour.
Look for repeated friction
Good app opportunities often appear where there is repeated friction.
The best problems are usually specific enough to explain in one sentence.
“I need a private workout tracker that lets interval training sit inside gym plans.”
That is stronger than:
“I want to build a fitness app.”
The more specific the problem, the easier it becomes to decide what the first version should include.
- 1A task people keep doing manually
- 2A process that relies on messy notes or spreadsheets
- 3A service with poor booking or communication
- 4A tool that has too many features but misses the useful one
- 5A product that forces accounts, tracking or subscriptions when it does not need to
- 6A workflow that works in theory but breaks down in real life
From problem to app opportunity
Once the problem is clear, ask:
- Who has this problem?
- How often does it happen?
- What are they using now?
- What do they dislike about existing options?
- What would make the process simpler?
- What is the smallest useful version of the solution?
A good first app idea is usually small enough to build, test and explain clearly.
If the idea needs a long explanation before anyone understands it, it may need narrowing. If the problem can be explained quickly, the app has a stronger starting point.
Key takeaway
Do not start with the app. Start with the problem.
A useful app idea is often found inside repeated friction: a missing feature, a messy workflow, an overcomplicated product, a privacy concern or a pricing model that feels wrong for the value being offered.
When the problem is clear, the product direction becomes easier to shape.
Next guide
Next guide: Turning an App Idea Into a Clear MVP Workflow
Once the problem is clear, the next step is to turn it into a practical user journey, define the MVP and decide what belongs in the first stable version.
Read the next guidePractical support
Need help shaping an app idea?
Harbour Apps can help small teams, founders and organisations turn rough app ideas into clearer workflows, screens, testing plans and launch-ready direction.
Build With Us