Latest / The Indie Hacker Podcast with Fexingo: Solo Developers, SaaS Side Projects, and Independent Tech / How a Solo Dev Hit 10K MRR With a Product That Charges Per Active User
Transcript
- Lucas: So you see a lot of indie SaaS products price by the seat — five bucks per user per month, flat. But there's another model that's less common and arguably smarter for certain products: charging per active user. Not just per user, but per user who actually uses the thing. Luna: Yeah, I've seen that mostly in enterprise tools — like Datadog or Snowflake — where you pay for consumption. But for a micro-SaaS? That's bold. Lucas: Well, one solo founder pulled it off. His product is a Slack bot that runs automated stand-ups — you know, replaces those daily status meetings with asynchronous check-ins. He launched in early 2025 and hit $10,000 monthly recurring revenue by December, about 11 months in. Luna: And he charges per active user? How does that work for a Slack bot? Lucas: So the pricing is $4 per active user per month. But the key is how he defines 'active.' A user has to submit at least one stand-up update in a given month to count. If they're just a member of the Slack channel but never post, they're free. And there's a 14-day free trial that requires a credit card upfront. Luna: Interesting — so the credit card at sign-up is a filter. It weeds out looky-loos. Lucas: Exactly. He said his activation rate — users who post at least once during the trial — is about 60 percent. But of those, around 70 percent convert to paid. The churn is actually lower than the industry average for seat-based pricing, which he attributes to the fact that if a team stops using the bot, they stop paying. There's no zombie seats. Luna: So the pricing aligns with value. The more the team actually uses the bot, the more they pay — but they're only paying for real usage. That seems fair. Lucas: Right. And the math works out nicely. He has about 250 active users across his customer base. At $4 per user, that's $1,000 per user per year — so $250,000 annual run rate. But the real magic is that his churn is about 4 percent monthly on a revenue basis, which is low for a micro-SaaS. Luna: Four percent monthly churn is low? I thought the rule of thumb for SaaS was 5-7 percent monthly. Lucas: For B2B micro-SaaS, 4 percent is actually pretty healthy. But it gets better: because his pricing is per active user, if a customer grows their team, revenue scales automatically. He doesn't have to upsell them to a higher tier. Luna: That's the dream, right? The product itself drives expansion. But what about the risk — what if a customer's usage drops? Then revenue drops. Lucas: That's the downside. In a flat seat model, if a team shrinks, you might still get the same monthly fee until they remember to cancel the extra seats. Here, revenue is more volatile. But he argues that volatile revenue that tracks true value is better than stable revenue that breeds resentment. Luna: I can see that. If you're paying for 50 seats but only 20 people use it, you feel ripped off. With per active user, you only pay for what you use. It's more honest. Lucas: And it helped him win deals. He says several prospects chose his bot over a competitor because the competitor charged $5 per seat regardless of activity. The engineering managers he talks to hate paying for unused licenses. So his pricing became a differentiator. Luna: What's the average team size among his customers? Lucas: About 12 active users per team. So the average monthly bill is around $48. That's low enough that it's an easy approval for a team lead with a corporate card. And it's high enough that he's profitable on a single server. Luna: So the unit economics work. How did he find his first customers? Lucas: He started by posting in a few Slack communities for engineering managers — just describing the problem: 'Tired of status meetings? I built a bot.' He got his first five customers that way. Then he added a simple referral program: if you refer another team, you get a month free. That drove the next 20. Luna: No paid ads, no content marketing? Lucas: Nothing. He's a solo dev with a full-time job. He spent maybe five hours a week on marketing — mostly engaging in Slack groups and responding to support tickets. The product itself did the selling. Luna: That's the indie hacker dream. But let's talk about the technical side: how does he track 'active user'? Is that tricky with Slack's API? Lucas: He uses Slack's events API to listen for when a user submits a stand-up. Then he stores a last-active timestamp in his database. At the end of the month, a cron job tallies up active users per workspace and generates an invoice. The whole billing system is about 200 lines of code using Stripe. Luna: So it's not technically complex. The hard part was the pricing decision. Lucas: Absolutely. He told me the hardest moment was choosing between $5 per seat and $4 per active user. He went with active user because he felt it was more defensible long-term. And he was right. His churn is lower, his NPS is higher, and his revenue is growing faster than if he'd gone with flat per-seat pricing. Luna: I want to dig into the churn a little more. You said 4 percent monthly revenue churn. What's the user churn? Like, do customers who cancel come back? Lucas: He tracks two churn numbers: customer churn and user churn. Customer churn is about 4 percent — teams that stop paying entirely. User churn is higher — about 7 percent — because within a customer, some users stop being active. But since he only charges for active users, that's fine. The customer keeps paying for whoever remains active. Luna: So inactive users don't hurt his revenue. That's a nice property. But what about the customer who goes from 15 active users to 5? Their bill drops, but they're still a customer. Lucas: Exactly. He'd rather have a small recurring bill than a zero-dollar churn. And he actually sees expansions — customers who start with 5 users and grow to 15 over time. That's the real growth engine. Luna: So what's the takeaway for other indie hackers considering this model? Lucas: I think the key is that per active user pricing works best when your product has a clear, measurable action that defines value. For a stand-up bot, that's submitting a daily update. For a design tool, it might be exporting a file. You need that natural usage unit. Luna: And you need to be comfortable with revenue that fluctuates. That can be nerve-wracking if you're bootstrapped. Lucas: True. But if you build a product people rely on daily, the fluctuations even out. And you avoid the toxicity of billing for unused seats. That builds goodwill. Luna: I love that this founder focused on a simple, honest pricing model instead of trying to maximize short-term revenue. It paid off. Lucas: It did. And speaking of things that pay off — if you found today's deep dive useful, and you want to support the show staying ad-free, you can buy us a coffee at buy me a coffee dot com slash fexingo. Every bit helps us keep bringing you these kinds of real founder stories. Luna: Yeah, it's a small gesture that goes a long way. And we really appreciate it. Lucas: So back to the pricing model — one thing I didn't mention is that he also offers an annual plan at $40 per active user per year, which works out to about $3.33 per month. About 30 percent of his customers take that, which gives him more predictable cash flow. Luna: That's smart. Discount for commitment, but still per active user. So the annual plan still tracks usage. Lucas: Right. And that reduces the volatility concern. He said the annual plan customers churn at less than 2 percent monthly. They're his most loyal segment. Luna: So if you're an indie hacker listening — maybe consider per active user pricing if you can define a clear usage metric. It might be the differentiator that gets you to 10K MRR. Lucas: And it doesn't hurt to require a credit card for the trial. It filters out non-serious users and gives you a much cleaner funnel. This founder swears by it. Luna: Alright, next episode we're talking about a solo dev who hit 10K MRR with a product that charges by the API call. That should be interesting. Lucas: Can't wait. See you then.