People are signing up and, look at you, some come back each week. They’ve told friends about the app, and a few have asked what you’re building next.
That’s encouraging, especially if you’re still trying to establish whether people want the product. But when someone asks how the business will make money, user activity can only take you part of the way.
Sometimes the answer is simply that the person using the app pays for it. In other businesses, the user and buyer are different people. Parents use a community app while local businesses pay for partnerships. Employees use software their employer purchases. If that’s your model, you need to understand why people return to the product and what someone else would pay to support it.
If you haven’t guessed it already, those questions are connected. A buyer may be interested precisely because you’ve built something people value.
We’re here to tell you the risk comes when you assume that interest will turn into revenue without finding out what the buyer actually wants.
Know who’s using it and who might buy
Picture an app that helps new parents meet families nearby. Parents use it to find events, join conversations, and make connections, while a local business may be more interested in reaching that community.
Parents care whether the app is useful and whether the community feels worth returning to. The business has different questions:
- Who would it reach?
- What would a partnership include?
- How would it know whether the expense was worthwhile?
And even more people may be involved. At a company, an employee might use your software, a department head might want it, and someone in procurement might approve the purchase.
The point we’re driving towards is that calling all three “the customer” makes it harder to see where a sale could stall.
Start by writing down who uses the product, who benefits from that use, and who controls a relevant budget. You may find that one person fills every role. If you don’t, learn what each person needs before letting one group’s enthusiasm stand in for another’s.
Be precise about what traction shows
Sign-ups tell you someone was interested enough to register. Repeat use tells you more: people are finding a reason to return. Neither tells you, on its own, that a prospective buyer will pay for access to those people or for the product they’re using.
Fifty users who return every week may be more useful evidence for your next decision than thousands of people who signed up once. But even strong retention leaves a commercial question open if your revenue depends on a separate buyer.
That doesn’t make the traction meaningless, because an engaged audience may be part of what you offer a sponsor or partner. You still have to find out what they would purchase. “We’d love to work together” is a great beginning to a conversation, but whether it leads to a paid event, a small experiment, a request for free promotion, or, less optimally, nothing at all, remains to be seen.
When you describe your progress, say what happened.
- How many people returned?
- Over what period?
- Has anyone agreed to pay, or are you still discussing an offer?
Those distinctions will make the next decision easier.
Find out what the buyer would purchase
It’s tempting to begin with a feature request, but for those who’ve been here long enough, know where we stand on adding new features just because someone asked for it. If a partner wants a dashboard, you might be well-served by putting a dashboard on the roadmap.
But before you do, ask what decision they’re trying to make with it.
If they want to know whether an event brought people into their store, you might be able to answer that during a small pilot without building reporting software. Perhaps they need data you can’t responsibly collect or share, which tells you something too.
Talk to prospective buyers about what they’ve paid for before, how they decide whether a partnership is worth the cost, and who signs off. Then give them an offer they can evaluate. Spell out what you’ll deliver, the price, the timing, and what success would look like to both sides.
An interview helps you understand how a buyer thinks. An actual buying decision gives you stronger evidence of willingness to pay. Even then, one purchase only establishes that one buyer accepted one offer under those conditions. You’ll need more evidence to know whether the offer can sell again and whether you can deliver it at a viable cost.
The question ParentConnect faced
ParentConnect began as an in-person community for new and expecting mothers outside Chicago. Its founders, Emma Huntley and Meera Sinha, came to Coura looking for help extending that experience through an app without losing what made the community work.
As the engagement developed, Coura’s work went beyond the product. Amodhi helped the founders rethink launch-event pricing and recognize that local brands might value a paid relationship with the community. ParentConnect’s case study describes a business model built around community members and paying brand partners. It also reports a sold-out event with 65 attendees, a fully subscribed app beta within two days, and roughly 70% retention at week three.
Each piece of evidence is distinctly useful. The event result helped the founders reassess pricing and the value of access to their audience. The beta and retention figures describe early product traction. The case study says brand partnerships anchor ParentConnect’s five-year revenue model and that conversations with two national brands were in progress.
The lesson isn’t that every community product should pursue sponsors. ParentConnect’s situation shows why a founder has to examine the whole business: the experience members came for, the value a partner might pay for, and the choices needed to make those two things work together.
Protect the reason users showed up
A prospective buyer can have a reasonable request that’s still wrong for your product.
Say a business offers to sponsor your community app but wants its promotions placed inside conversations between members. The money matters as much as the possibility that members will stop trusting those conversations.
You’d need to find out whether a different arrangement could meet the business’s goal without changing what members value. An event partnership might work. A clearly labeled placement might work. The proposed deal might not be a fit. You won’t know without examining the request in the context of the product you’re building.
This is where product strategy and revenue strategy meet. Before adding a buyer-requested feature, understand what they need it for, what it will cost to build and maintain, and what it will do to the user experience. If you’re making an exception for one buyer, be honest with yourself about whether that exception is worth carrying forward.
Test the offer before building around it
You don’t need to settle your entire business model in one experiment. You can make the next question smaller.
If you think local businesses will pay to reach your community, offer one business a specific paid partnership. If an employer might buy your product for its team, propose a limited paid pilot with a clear scope. Put a price on it. Define what you can deliver with the product and resources you have now.
Then pay attention to what happens. If the buyer declines, find out why; the price, audience, timing, and offer are different possible explanations. If they agree, deliver the work and learn what it actually takes. Do they want to buy again? Can you serve another buyer without recreating the whole process? Does the revenue justify the effort and expense?
A first sale is a real milestone. It isn’t the same as a repeatable business model, and it doesn’t need to be presented as one.
That honesty is useful when you talk to investors, too. “Our users return, and we’re testing a paid offer with prospective partners” tells them what you’ve learned and what remains uncertain. If you later have paying partners and evidence that some renew, the story changes because the evidence has changed.
Decide what you need to learn next
If people are using your app but you don’t know who will pay for it, take the usage seriously. Look closely at what it demonstrates, then get equally specific about the buyer.
Who has a budget for the value you can offer? What would they buy today? Could you deliver it without undermining the experience that attracted users? You can investigate those questions before committing to a new set of features.
Coura helps founders make product, positioning, and go-to-market decisions with the whole business in view. If you’re trying to connect early traction to a workable revenue model, see how Coura works.
FAQ
How do you make money from an app if users don’t pay?
First, identify who might receive enough value to buy something connected to the product. Depending on the app, that could be an employer purchasing access for staff or a business paying for a partnership with a community. Then test a specific paid offer with a prospective buyer. User activity can help explain the opportunity, but it doesn’t establish that someone else will pay.
Are app users and customers the same people?
Sometimes. In a paid consumer app, the person using the product may also buy it. In other products, people use the app while an employer, organization, or partner pays. If those roles are separate, find out what each group needs and who makes the purchasing decision.
Does having active users prove an app can make money?
No. Repeat use is evidence that people have a reason to return; it doesn’t establish what they’ll pay or whether a separate buyer will purchase an offer. A paid pilot provides stronger evidence of willingness to pay, but one sale still doesn’t prove the model will work repeatedly or cover its costs.
How can you test an app’s revenue model before building more features?
Offer a prospective buyer something specific that you can deliver with your current resources, such as a limited paid pilot or event partnership. State the price, scope, and timing. What they agree to buy—and what it costs you to deliver—will help you decide whether a requested feature belongs on the roadmap.
Should you build features a prospective buyer asks for?
Treat the request as a clue about what the buyer needs, then investigate it before committing development time. Ask what decision the feature would help them make and whether you can meet that need during a pilot without building it. Also consider whether the change would weaken the experience that brought users to the product.