What Happens When You Let a Community Help Decide What SaaS Gets Built Next?

Reverse the usual order

Most software products begin in private. A founder has an idea, researches it, designs it, builds it and only then shows it to other people and asks what they think. I have started wondering whether that order should be reversed.

What happens if the people who might eventually use the software are involved before the product exists? What happens if they influence the problem, the idea, the features and even whether something should be built at all?

That is one of the experiments behind my Build SaaS with AI community. I do not want the group to become another place where I simply announce completed products. I want it to become part of the product-development process itself.

Problems are more valuable than feature requests

If somebody tells me “you should add an AI workflow builder,” that may or may not be useful. It is already a proposed solution. I am much more interested in hearing “every time I do this task, I have to copy the same information into three places.” That is a problem.

Once you understand the problem there may be several solutions: a new app, a feature inside an existing product, a small automation, a guide or something that already exists.

That is why I increasingly want community conversations to begin with “what are you struggling with?” rather than “what software should I build?”

Problems are more valuable than feature requests.

AI changes what can happen next

Community-driven development is not new. AI changes the speed between feedback and experimentation. Someone can describe a problem in the morning, I can explore it with AI, compare it with applications I already have, design a small prototype and bring something tangible back while the discussion is still fresh.

That creates a much stronger feedback loop than collecting ideas and disappearing for six months.

The community is not a free product department

Inviting people to suggest ideas can accidentally create an expectation that every suggestion will be built. That would be impossible and it would be terrible product strategy.

One person wants simplicity, another wants advanced controls. One wants automation, another wants manual control. Someone wants a mobile app, someone wants an API and someone wants a feature that is perfect for them but almost nobody else.

Listening does not mean obeying. The founder still has to make decisions.

Voting is a signal, not a command

Polls make participation easy and help expose interest, but the most popular option is not automatically the right product decision. People often vote for features that sound exciting and then never use them.

A poll can tell me people are interested. It cannot necessarily tell me they will pay, that the problem is important or that this should be the next thing built. That requires a deeper conversation.

One detailed comment can beat fifty likes

Imagine somebody explains: “I spend two hours every week doing this manually. I have tried three tools and none solve this part.” That is valuable because it tells you the problem is repeated, consumes measurable time and existing solutions may be incomplete.

That does not guarantee a viable SaaS idea, but it gives you far more to work with than a generic poll asking whether somebody would use an AI marketing tool.

The first version does not need to be big

If ten people describe the same problem, I do not need to build a giant platform around it. I can build the smallest useful answer, let people try it and then ask whether it solved the problem, what was missing and whether they would use it again.

AI lowers the cost of learning. Instead of spending months trying to predict the perfect product, I can create an intentionally limited version and use real behaviour to decide whether it deserves more attention.

A community can prevent products too

A community can reveal that an idea is not worth building. Perhaps nobody cares. Perhaps the problem occurs once a year. Perhaps people already have a solution they like. Perhaps the feature sounds useful until you explain how it would actually work.

Success in community-led development should therefore include weak ideas identified before they become maintenance obligations.

A product you wisely decide not to build can be a very successful outcome.

Building in public creates accountability

When you discuss an idea publicly, you have to explain it more clearly. Why does it exist? Who is it for? Why is the current solution not enough? Why are you building it this way?

Those questions pressure-test weak thinking. A build-in-public community should not become theatre where every experiment conveniently turns into a winner. If a prototype turns out to be unnecessary, that result should be shared too.

Recognition and value matter

If a community genuinely influences what gets built, contributors should feel recognised: founding members, beta testers, idea contributors and people who helped identify bugs or shape features. Otherwise “help shape what gets built” becomes empty marketing language.

The exchange also needs to go both ways. Members should gain useful tools, practical lessons, honest build stories, early experiments, guides, resources and opportunities to influence products. The community only works if participating is worthwhile even for someone who never buys anything.

A better product-development loop

The model I am moving toward is simple: community problem, clarify the pain, check existing products, explore solutions with AI, build the smallest useful experiment, give it back to the community, observe actual use and then improve, integrate, merge or stop.

That last word matters. Stop. A community-driven process needs permission to stop, otherwise every experiment becomes permanent software.

The founder still has a job

Community-led development does not remove founder judgement. It makes it more important. Someone still has to connect the dots, recognise repeated problems, ignore distractions, understand technical consequences, balance short-term requests against long-term architecture and say no.

The community should not simply watch the journey. It should be able to influence the direction. AI has already made it easier for me to create software. The next question is whether involving more people can help create better reasons to build it in the first place.

A smaller community may be more useful than a giant audience

You do not necessarily need thousands of followers to build with a community. A smaller engaged group can be more useful because you can recognise recurring contributors, follow up with them and see whether they actually tried what you built.

A large audience is useful for distribution. A smaller community can be unusually useful for understanding. Those are different jobs. For product development, a handful of people who explain a repeated problem in detail can be more valuable than thousands of passive impressions.

That also makes beta testing stronger. Someone who was part of the original problem conversation already understands why the product exists. Their feedback can be much more specific than a random tester saying they like the interface.

The best idea may come from somebody else’s business

I naturally see the problems inside my own workflows, which creates blind spots. An affiliate marketer, local business, creator, membership operator or course seller may describe a frustration I have never encountered. Those differences can lead to much better product ideas than simply extending the tools I already use.

The community supplies real-world starting points. AI gives me a faster way to explore them. The useful combination is not crowdsourcing a roadmap; it is widening the range of problems I am exposed to before I decide where to invest development time.