A few years ago, I watched someone build a SaaS product in six weeks. Not a platform. Not a marketplace. A single tool that solved exactly one problem. The audience was small. The pricing was simple. The whole thing felt almost too plain. It now does seven figures a year.

That experience stuck with me. It changed how I think about software. The big idea is rarely the winner. The smaller, specific, almost boring problem is usually where the opportunity is. Find a group of people dealing with something repetitive and annoying. Build something that handles that one thing. Charge for it. Then pay attention to what they ask for next.

Finding the right problem

The hard part is picking the right problem. Not something that sounds nice in theory. Something people deal with every week. Something they genuinely don’t enjoy doing. Something that quietly wastes their time or energy.

Most of the good opportunities are already inside existing workflows. People are already doing the task. They just wish it was easier. That’s usually the signal.

A few patterns tend to show up. People are already paying for a workaround, even if it’s messy. The task keeps coming back regularly, not once in a while. And if you look around, you’ll see people complaining about it in public. That kind of frustration is useful to pay attention to.

Validating without code

This is where things often get overcomplicated. Landing pages, ads, surveys. They can help, but they don’t really prove much on their own.

The only thing that really matters is whether someone is willing to pay.

The simplest way to test that is to just do the work manually for a few people. Charge them a small monthly fee. Use whatever tools you already have. Spreadsheets, email, anything. If they keep paying, that tells you a lot. Then you can think about automating it.

I saw someone do this with a reporting tool. He handled everything manually for a few clients for a couple of months. They kept paying. That was enough of a signal to move forward and build it properly.

Running something like this for a while gives you clarity. If people stay, you’re onto something. If they leave, there’s usually a reason worth understanding.

Building only what matters

When it comes to building, keeping things small helps more than anything. One feature. One job. One clear output.

Trying to do too many things at once usually slows everything down. It’s easier to start with the smallest version that actually solves the core problem and put it in front of people.

Once it’s live, you start noticing patterns. Some requests come up again and again. Others are just one-offs. Over time, it becomes clear what actually matters.

The first version doesn’t need to be perfect. It just needs to work. If it solves the problem, people are generally okay with rough edges in the beginning.

Pricing simply

Pricing doesn’t need to be complicated either. Most of the time, a simple structure works fine. A basic plan, maybe a higher tier later if needed.

In the beginning, even a single plan is enough.

The important part is that the core value matches what people were already willing to pay for during the early stage. Everything else can be added later if there’s demand.

Making money early

Charging early tends to make things clearer.

Free users can be helpful, but they don’t always tell you if the problem really matters. People who pay usually do.

The setup itself is not that complicated anymore. Payments, login, subscriptions, there are simple ways to get that working fairly quickly.

The bigger challenge is finding those first few people who actually need what you’re building.

Finding the first customers

For something niche, broad marketing usually doesn’t work that well. What tends to work better is just being present where the audience already is.

Communities, forums, small groups. Places where people are already talking about the problem.

Helping out, answering questions, sharing useful input. Over time, people notice. And when your tool fits naturally into what someone is asking, that’s when it makes sense to mention it.

It’s slower, but it feels more direct.

And realistically, you don’t need a huge number of users to get started. Even a small group of paying customers can turn into something meaningful over time.

What I learned

Looking back, the main thing that stood out was speed. Not rushing, but not overthinking either.

The first version was simple. A bit rough. But it worked. That was enough.

What didn’t happen was months of polishing before launch. No waiting for everything to feel perfect. Just putting something useful out there and improving it as people started using it.

Starting smaller than feels comfortable seems to help.

Find a few people dealing with the same problem. Help them solve it, even if it’s manual at first. Charge for it. Then build around what they continue to pay for.

That’s really the core of it.