No One Wants Another App
Everyone I talk to these days seems to have an idea for a software product.
They can already picture the dashboard, the pricing page, the mobile version, the AI assistant, the integrations, and the announcement post they will publish on launch day. Some have even chosen the name before speaking to a single customer.
When I ran my software company, simplicityEngine, people came to us constantly with ideas for apps they wanted us to build. They had feature lists, sketches, competitor links, and ambitious plans for what the product would eventually become.
Many of them were missing the most important piece from the beginning.
People already have more software than they know what to do with. They have forgotten passwords, unused subscriptions, abandoned dashboards, browser tabs they keep open for weeks, and tools they bought because the demo looked impressive.
They do not wake up hoping to create another account. They wake up wanting a problem removed, a task completed, a decision made, a customer found, a cost reduced, or an outcome reached sooner. And if they could afford someone else to do it for them, instead of software, they would.
Your app is only one possible delivery method.
Contents
The Build First Blindness Epidemic
We are living through a build first blindness epidemic.
AI coding tools, no code platforms, templates, boilerplates, and cheap cloud infrastructure have made it possible to create software faster than ever. A founder can describe an idea on Friday and have something clickable by Sunday.
That speed feels like progress, so people keep building.
They add onboarding, billing, team accounts, notifications, analytics, dark mode, and ten integrations before anyone has proven that the customer cares enough about the core outcome.
The product becomes more complete while the business question remains unanswered.
Most founders begin with, “Can this be built?”
The more useful question is, “Why would someone stop what they are doing, trust this product, change their behaviour, and pay for it?”
Technology has made the first question easier. The second one has become harder than ever. Because it requires real thinking and hard work. It still requires customer conversations, observation, judgment, positioning, and repeated attempts to sell.
Building can create the feeling of certainty. You can see the screens. You can click the buttons. You can measure how much work has been completed. Customer demand is less comfortable because the answer may be no.
That discomfort is why many founders choose another week of development over another hour of selling.
Building Got Easier, Choosing What To Build Did Not
Before AI coding, building too early could waste tens of thousands of dollars and many months. Today, a founder may waste less money and still lose a year chasing the wrong product.
The lower cost of development has removed one obstacle and created another. People now launch ideas that would previously have died during the effort required to build them.
This means we will see more software, more overlap, more generic dashboards, and more products that differ mainly through branding and a few feature choices.
The ease of building does not create a reason to buy.
A product still needs a customer who recognizes the problem, dislikes the current alternatives, values the proposed outcome, and believes your approach is worth switching for.
That is why the early work should focus on the customer and the job they are trying to complete.
Start With The Service
If you believe an app could solve a problem, offer the outcome as a service first.
Find one potential customer and help them manually. Charge more than the future software subscription because you are providing attention, judgment, customization, and direct involvement.
Then find a second customer.
Then a third.
Each customer will force you to confront details that never appeared in the original idea. They will use different words to describe the problem. They will care about steps you assumed were minor. They will ignore features you considered essential. They will introduce exceptions, edge cases, approval requirements, and dependencies you never imagined.
This is where the useful version of the product begins to reveal itself.
The manual service gives you access to the full problem and to the person who has that problem. You can see what happens before the customer reaches you, what they need from you, and what happens after you deliver the result.
An app idea usually starts with one step. A customer experience shows you the whole sequence.
Manual Work Is Product Research
Founders often treat manual work as something beneath the future software company.
They imagine the app as the scalable version and the service as an embarrassing temporary phase. This thinking is backwards.
Manual delivery gives you the information required to build software that deserves to exist.
You discover which inputs are required, which decisions need judgment, which steps repeat, which exceptions occur, and where customers become confused. You also discover which parts customers value enough to pay for and which parts can disappear without affecting the outcome.
During this phase, you should document everything.
- What does the customer ask for first?
- Which information is always missing?
- Which steps take the most time?
- Which steps require experience or judgment?
- Which parts repeat across customers?
- Which requests appear only once?
- Where do delays happen?
- What creates the most relief for the customer?
- What does the customer praise after delivery?
- What would they gladly pay more to avoid?
Those observations become the blueprint for the product.
How A Category Of 1 Emerges
Your Category of 1 rarely appears because you sat alone and invented a clever name for a familiar product.
It emerges when you understand a customer problem at a level that generic competitors do not.
Working directly with customers helps you discover the specific mechanism, workflow, audience, promise, or constraint that changes the product from “another app” into a better way of solving the problem.
You may discover that the customer does not need a general client portal. They need a guided client portal built around a success path that tells every client what happens next.
You may discover that language learners do not need another flashcard app. They need to begin with the sentences they already say in English and learn how to express those thoughts in Mandarin.
You may discover that a broad project management tool is unnecessary. The customer needs one narrow workflow that helps a specific type of team complete a specific job with fewer mistakes.
What have you learned from customers that would cause you to design the product differently from someone who only saw the category from a distance?
That answer may become the product’s mechanism, positioning, onboarding, pricing, or entire reason to exist.
This is why differentiation should come from understanding the work, rather than decorating a generic app after it has already been built.
What To Learn From Early Customers
The purpose of serving customers manually goes beyond validating that the problem exists.
You are trying to learn how the customer evaluates the problem and what an acceptable solution must include.
Customers often describe the problem differently from founders. Pay attention to the phrases they repeat, the outcomes they ask for, and the words they use when they become frustrated. Those phrases can shape your positioning, sales copy, onboarding, and product labels.
Ask which tools, services, spreadsheets, employees, or improvised methods they already use. Their current approach tells you what your product must replace and why switching may be difficult.
A broad problem may contain one moment that creates most of the urgency. Find the point where delays, mistakes, cost, embarrassment, or missed revenue become hardest to tolerate.
The first few exceptions may appear unique. After several customers, patterns begin to emerge. Those repeating exceptions often become the features that separate a useful product from a shallow one.
Some steps can be automated quickly. Others depend on experience, context, taste, or trust. Decide whether the product should automate those decisions, assist the user, or keep a person involved.
Customers may praise many features and pay for only one outcome. Look at what causes them to approve the purchase, renew, upgrade, refer someone, or ask for more.
Your first idea may target everyone. Early customers may reveal that one type of user understands the value faster, gets better results, and requires less convincing. That group can become the focus of the product.
When It Is Time To Build
It becomes tempting to build software as soon as the first few customers teach you something useful.
Wait.
Keep delivering the service until repeated work begins to create a capacity problem.
When customers are consuming all your available time, you have evidence that demand exists and that parts of the work repeat. You can then decide which repeated steps should be automated and which parts still benefit from human involvement.
- You have paying customers, rather than only interested people.
- The same type of customer keeps arriving with the same problem.
- The delivery process repeats in a recognizable sequence.
- You can describe the required inputs and expected output.
- You know which exceptions occur frequently.
- You are turning away work or delaying customers because of capacity.
- Customers ask for faster access, self service, collaboration, or recurring use.
- You know which part of the process creates the most value.
- You can explain why your approach deserves to be chosen over current alternatives.
At that point, software becomes a way to expand a proven process.
You are productizing what customers already value.
When You Are Still Too Early
Founders often mistake activity for evidence.
A waiting list does not carry the same weight as payment. Compliments do not carry the same weight as usage. A viral post does not carry the same weight as retention. An impressive demo does not carry the same weight as a business.
- You cannot name the first ten customers.
- You have never asked anyone to pay.
- The target customer keeps changing.
- Every conversation produces a completely different use case.
- You keep adding features to make the product easier to explain.
- The value depends on a long demonstration.
- People say the idea is interesting but do not ask when they can use it.
- Your main reason for building is that the technology makes it possible.
- You are more excited about the product than the customer problem.
When these conditions appear, more development usually creates more product around an unproven assumption.
Return to the customer. Sell the outcome manually. Learn what deserves automation.
AI Does Not Fix Weak Demand
AI can help you build faster, write code, create designs, produce content, analyze conversations, and automate parts of delivery.
It cannot make customers care.
It cannot decide which problem is urgent enough to earn a budget. It cannot replace the judgment that comes from watching customers struggle, hearing their objections, and seeing what they continue paying for.
AI may reduce the cost of a wrong build. It can also help you create the wrong build at a much greater speed.
The founders who benefit most from AI will be those who use it after developing customer insight. They will move faster because they know which workflow to create, which steps to automate, and which outcome the product must deliver.
Everyone else will produce more software for people who never asked for it.
Conclusion
Instead of building an app immediately, begin by doing the work as a service.
Help one customer. Charge them. Help another. Pay attention to what repeats, what changes, what customers value, and which part of your approach produces the best outcome.
Keep going until demand begins to exceed your capacity.
Then build the product that helps you deliver what customers already want, to more people, with less effort and greater consistency.
Your Category of 1 will often come from the insight you gain during that manual phase. It is the specific way you solve the problem, the sequence you follow, the audience you understand, or the mechanism that makes your approach easier to choose.
That is when another app may deserve to exist.
Do not become the founder who builds first, searches for a customer later, and keeps adding features because nobody understands why the product should be chosen.
Nobody wants another app.
They want a better way to get something important done.