A lot of founders start in the same place: a blank page.
They want a new idea. A clever idea. Something nobody has built before.
That sounds exciting. It is also a slow way to get started.
A better place to look is where people are already frustrated.
Find a product that people pay for. Then find the users who keep saying the same things:
- “This costs too much.”
- “It does way more than I need.”
- “The setup is a nightmare.”
- “I only use two features.”
- “Why is there no simple version of this?”
Those complaints can lead to good SaaS ideas.
Not because you should copy a bigger company. You should not. But because the market has already told you something useful: people care enough about this problem to spend money on it.
Your job is to find the part that is still broken for a certain group of people.
Read complaints. Find a narrow problem. Test whether people will pay. Then build the smallest version that solves it.
1. Start With a Market That Already Exists
You do not need to invent a new category.
Imagine you are looking at a popular tool like Typeform. People use it to collect leads, run surveys, and build forms. That means the main problem is already validated.
But not every customer needs a full form platform. A solo consultant may only need one clean lead form and a simple email follow-up. A local gym may just need an easy booking form. A small online store may want a quick product quiz without paying for a big plan.
The opportunity is not “make another Typeform.”
It might be: make a simple lead form tool for coaches who want to collect leads and send one follow-up email.
That is a smaller promise. It is also easier to explain, build, and sell.
Big products often grow into big bundles. They add features for larger teams, more use cases, and more revenue. That makes sense for them. But it can leave smaller users behind.
Some users do not want a dashboard with 40 settings. They want to finish one job in ten minutes. That is where a focused product can win.
2. Read What Users Hate
Do not guess what people want. Go read what they say.
You can find useful feedback in G2 and Capterra reviews, Reddit, Product Hunt comments, X posts and replies, YouTube reviews, App Store or Chrome Web Store reviews, and niche Slack, Discord, and Facebook groups.
Start with a product you know or a market you can understand. Then read the negative reviews first.
One bad review means very little. Some people will complain about anything. You are looking for repeated patterns.
For example, imagine you read 40 reviews of an appointment scheduling tool. You may see comments like:
- “It is too expensive for a one-person business.”
- “I only need bookings and reminders.”
- “My clients get confused by the booking flow.”
- “I do not need team scheduling.”
- “It takes too long to set up.”
Now you have something worth exploring.
The real problem may not be “people need a cheaper calendar tool.” It may be: one-person service businesses want a booking page that is easy for both them and their clients.
As you research, save useful comments in a simple document. For each one, write down who is complaining, what product they use now, what exactly bothers them, and what job they are trying to get done.
After you collect 30 to 50 comments, look for the message that keeps coming back. If ten different users say the same thing in different words, pay attention.
3. Narrow the Problem Before You Build
A complaint is not automatically a business. People complain about software all the time.
Before you build anything, ask a few hard questions.
Does the problem happen often?
A problem that happens every day is usually better than one that happens once a year. Good SaaS products often sit inside repeat work: getting leads, booking meetings, sending invoices, collecting approvals, creating reports, managing client work, or following up with customers.
If a user feels the pain every week, they are more likely to look for a better tool.
Can you name the user clearly?
“Small businesses” is not clear enough. Try freelance designers, independent recruiters, Shopify store owners, real estate agents, newsletter writers, small marketing agencies, or online coaches.
The narrower your first audience is, the easier your product becomes. You will know what features to ignore and where to find users.
Compare these two lines:
A simple CRM for small businesses.
A simple CRM for freelance recruiters who manage fewer than 100 candidates.
The second one tells the reader, “This might be for me.”
Can you remove features without hurting the result?
Many existing products have lots of features because they serve lots of customers. Your customers may only need a small part of that product.
Ask what result the customer is paying for. A freelance designer may not need a full project management system, but they do need clients to review work and give clear feedback.
The first version may only need a page to share work, a simple approval button, a place for comments, and email reminders.
The goal is not to make a stripped-down product. The goal is to make the important job easier.
Can you offer more than a lower price?
Price matters, especially when people feel they are paying for features they never use. But “cheaper” is not a full strategy.
A bigger competitor can run a sale, add a cheaper plan, or copy your price. You need another reason for people to choose you: faster setup, one specific job, an easier experience for non-technical users, a niche workflow, better privacy, or support from someone who understands their work.
Low price can get attention. Clear focus is what makes people stay.
4. Test the Promise Before You Write Much Code
This is where many founders make the wrong move. They see a problem, get excited, and spend three months building. At the end, they launch to silence.
Before you build the product, build a simple page that explains it.
Your page should answer five things quickly:
- Who is this for?
- What painful problem does it solve?
- What does the user get?
- Why is it simpler or better than the current option?
- What should the visitor do next?
For example:
Client approvals without the project-management mess.
A simple review page for freelance designers. Send work, get clear feedback, and move on.
You do not need a polished brand or a long feature list. You need a clear promise.
Then ask people to do something. The stronger the action, the better the signal.
- Read the page
- Join a waitlist
- Reply to a short survey
- Book a call
- Ask for early access
- Put down a refundable deposit
- Pay for a founding-member plan
Email signups are nice, but they are easy. A paid deposit is much more meaningful. So is a customer who agrees to use a rough early version.
Be honest about what exists. You can say: “I am building this with a small group of freelance designers. Early members get a lower price and can help shape the product.”
5. Put the Idea in Front of Real Users
A landing page by itself proves nothing. You need to show it to people who have the problem.
Go back to the places where you found the complaints. Join the conversation in a useful way. Do not spam a group with “Try my new startup.”
Instead, share what you noticed and ask a real question.
I keep seeing freelance designers say that clients hate logging into project tools just to approve a file. I am testing a simpler approval page. Would that save you time, or is the real problem somewhere else?
This works better because it does not pretend you already know the answer.
Good signs include people explaining their current workaround, telling you what they pay for now, asking when it will be ready, asking whether it works with another tool, wanting to try it, or asking about the price.
Bad signs are useful too. If people say, “I would never use that,” ask why. Maybe you picked the wrong user. Maybe the real problem is different. Maybe the idea is not strong enough.
It is much better to learn this before building a big product.
6. Look for Action, Then Build One Useful Workflow
The best early signal is not praise. It is action.
A person who gives you time, a call, a deposit, or a payment is telling you something important: “This problem is real enough for me to do something about it.”
Once you get that kind of interest, it is time to build. But keep the first version small.
Your MVP should solve one job from start to finish. If you are building for client approvals, do not add invoicing, team chat, time tracking, AI summaries, and ten integrations in version one.
Let users upload work. Let clients review it. Let them approve it. Send reminders when needed.
That is enough to learn.
A small product is easier to launch, easier to fix, and easier for users to understand. You can do some work manually at first. If users want a weekly report, create it by hand for the first five customers. That may sound unscalable, but early on it gives you a close look at what people really need.
Your first goal is not scale. Your first goal is proof:
- Will people pay?
- Do they use the product again?
- Does it save them time or money?
- What do they ask for next?
Do Not Compete on “Cheap” Alone
A lower price can be a good entry point. It can help you reach people who are tired of paying for large tools. But low prices can also hurt you.
If the product costs too little, you may not have enough money for support, development, and marketing. Some buyers may also wonder if the product will still exist next year.
So do not say only, “We cost one-tenth of the big guys.” Explain why your product can be simpler and less expensive.
For example: “We only do client approvals. There are no unused modules, no team setup, and no expensive plan built for large agencies.”
Now the price makes sense. You are not competing on price alone. You are showing that your product was built for a different kind of customer.
Learn From Existing Products Without Copying Them
There is nothing wrong with studying successful products. It is smart. But inspiration is not copying.
Do not copy another company’s name, branding, code, design, or private content. Do not pretend your product is connected to them if it is not.
A successful product proves that a certain job matters. Your work is to understand which users are not happy with the current way of doing that job, then make something with its own point of view.
Ask who is paying too much for features they do not use, who is confused by the setup, who has a workflow the big product does not care about, and what one result could be faster, simpler, or clearer.
That is how you build an alternative with a real reason to exist.
A Quick Checklist
- Who is the first customer?
- What tool or workaround do they use now?
- What repeated complaint did you find?
- How often does this problem happen?
- What result do they actually want?
- Which features can you leave out?
- Why would they choose you besides price?
- What can you ask them to do before the product is ready?
- What is the smallest version that can solve the problem?
If you cannot answer these questions, keep researching. That is not wasted time. It is the work that keeps you from building the wrong thing.
You do not need a magic idea. You need a real problem, a clear group of people, and proof that they care enough to act.