Stop Using AI to Build Things No One Needs

Let your users stake on what to build next

It’s easy to vibe code a software product, harder to maintain it, and challenging to monetize it. “Only one in ten apps we build generates any profit. One in twenty generates serious profit.” That feels like the new baseline among my tech friends.

My friends with product background are becoming more technical in their day jobs, and they can now research new domains much faster. Still, none of them say their AI skills result in more value for users.

The more users you get, the more expensive it becomes to ship the wrong things, especially while your competitors are shipping the right things at a new speed.

So how to stay laser-focused on building things people actually want?

Customer interviews, pre-registrations, surveys, prototypes, and data analytics all help validate product hypotheses. They give you more confidence, but they do not prove the most important thing: paid demand.

There is an old saying that customers vote with their wallets. What if users could literally vote with their money on what they want before we build it?

To make this more relevant to startup reality: what if we launched a poll where upcoming product features were the options, and users could vote with their funds for the features they truly care about?

…

At first, it looks like an old, simple tool that could now help us prove demand early. Then you start to notice its second-order effects.

Feature prioritization turns into quick funding.
When the poll ends, you can collect the funds from the winning option, turning user decisions into immediate sprint funding.

Power users activate an engagement growth loop.
It seems like a good idea to reward users who participate in these polls with project-specific bonuses. Let’s say your app’s monthly subscription costs $50. You make one vote cost the same $50. People who voted for the winning option get two months of subscription, while votes for non-winning options are refunded. Then you share public updates on the bonuses and the building process. Others start to realize their input matters. Higher community engagement leads to more funding and better prioritization.

Products for small niches get a better risk/reward profile.
It becomes easier to prove demand before you build anything, and easier to maintain the product by focusing only on the things that truly matter to users.

The caveat of this approach, which might be called stake-driven development, is that you need trust. People need to trust you enough to give you money now for something they might receive in the future.

So this approach seems to fit three scenarios.

You already have a product and a user base.
You ask your users to vote on the product features they want to see implemented. You get money before you start building anything.

You are building a new product and currently have no user base.
You run customer interviews. At the end of each interview, you send the lead to a poll where they can immediately fund the product variant that best suits their needs.

You have no product, but you have access to a friendly community you can talk to.
Let’s say it’s a community of Pokémon card collectors. Maybe you could vibe code something useful for their hobby. Scrape ideas from the community chat, run personal interviews to get deeper insight, summarize a few product ideas, and then roll out a fundable poll in the public chat.

Will this work for every product? No. It probably will not work if your clients are large enterprises. But if your clients are retail users or small teams, this approach looks worth trying.