​

​

​Podcast, YouTube, Blog​

Dear founder,

​

I’ve been running into an interesting challenge in the last few days with Podscan. I have to make a choice that is both technically feasible, scalable, and balanced—a balance between giving my trial customers precisely what they want and being able to keep my business profitable.

Let me walk you through this situation because I think it perfectly illustrates the kinds of decisions we, as founders, have to make all the time.

​

​

This issue is sponsored by my friends Corey, Zach, and Nick at Conversion Factory.

Imagine having a senior copywriter, designer, and web developer at your disposal to turn every marketing idea into a reality. The folks at Conversion Factory are marketers who know design and designers who know marketing. Whether you need help positioning, launching, branding, or anything in between… they help startups "punch up" and make a ruckus. And they do it all without the usual BS of an agency — no quotes, no contracts, no billable hours, no Slack, no email, no calls. 100% async on a flat retainer.

​Check out Conversion Factory (I highly recommend it, I ran into them at MicroConf in New Orleans (again!), we chatted for HOURS, and they're a smart and impactful bunch.)

​

​

Now, let's talk "Value Demonstration vs. Cost Control."

Podscan has only recently turned profitable after being unprofitable for a about a year while building up the product. It is a business that is highly reliant on AI systems, which is expensive, both for basic functionality like transcribing podcasts and for additional features like sentiment analysis and other smart things that people need done with these transcripts that a normal algorithm couldn’t easily handle.

I use AI in many ways: I have my own servers running local language models, and I occasionally use external services. The costs can add up quickly.

The specific problem I’m facing is that I want to show off these AI-powered features to prospects who sign up for a trial. I want them to get that “wow” feeling that Podscan is super valuable. The service allows users to set up alerts for specific mentions in podcasts—when a certain word is mentioned, they get an email or a webhook notification. It’s really cool.

In many cases, just checking keywords with a simple text search is fine and very cheap. But the real value of Podscan comes when users want context-aware filtering.

For example, someone might want to track mentions of the word “yield,” but they don’t want results about farming or traffic controls—they’re specifically interested in “yield” as a financial term. This requires AI-centric context analysis, which is much more expensive to run.

The Current Approach and Its Limitations

Currently, for trial customers, I limit this context-aware filtering to about a dozen attempts per hour. My paid accounts get hundreds, if not thousands, of these checks per hour because they’re literally paying for the infrastructure. But for free users, only the first 10-12 context checks per hour are processed, and anything after that gets ignored.

This creates a situation where, over a floating 24-hour window, there are only 24 moments when credits are available. Podcast episodes that trigger certain keywords during those times get scanned, but if they don’t contain the relevant context, and better matches come in later when the hourly limit is already reached, those better matches get ignored for trial users.

The result? For some trial customers with specific needs—exactly the kind our tool is designed to solve—I can’t effectively demonstrate Podscan’s value. Showing that value might cost me hundreds of dollars during a customer’s trial period, who might then convert to a plan that’s only 1/10 of that cost per month. This makes the customer lifetime value sink while the customer acquisition cost balloons (funny enough).

The Balancing Challenge

This is an interesting intersection between a technical problem, a business problem, and a financial decision:

1. Technical challenge: How do I keep people from abusing the system? I’ve had trial users set up alerts for high-frequency terms like “AI” with context filters checking for “making money with AI”—terms that could trigger thousands of checks per hour.
2. Value demonstration challenge: From a customer’s perspective, it’s really cool to sign up, set an alert, and immediately see a wave of relevant data flowing in from all over the world. This immediate value demonstration is crucial.
3. Financial challenge: I can’t spend hundreds of dollars on a trial user who might never convert or might convert to a $30/month plan.

This is generally a problem with free trials, or with its “even more deranged cousin,” the freemium model.

Learning From Others

I remember a story from Josh Pigford when he was still running Baremetrics several years ago. They introduced a freemium model, and immediately, people started importing years of historical Stripe data. Their servers started smoking because of the amount of data being crunched for free users—gigabytes per minute for hundreds of new customers who might never pay.

Freemium models run this risk a lot, and even free trials face similar challenges, as I’m experiencing firsthand.

Finding a Balance

My challenge is to find an effective balance, and I want to share my thinking because I believe we run into these issues all the time as solopreneurs or small teams. As bootstrappers, we’re budget-constrained, but we’re also resource-constrained in ways that force us to make judgment calls about how much we can give to free trial users.

We don’t want our paid users subsidizing the experience of trial users. We want paid users to pay for their own experience. It may be subsidized for trial users a little bit, but we certainly don’t want people coasting by for free for weeks just because our system can potentially generate valuable data for them.

My Solution

My approach is to be as quick as possible to demonstrate value, but also as fast as possible to throttle a trial user’s resource expenditure.

What I’m implementing (and will likely have implemented by the time you read this) is a system where I’ll allow people on an account basis to use resources just like a paid account, but only until a certain number of results are reached for each alert.

I think that’s a fair compromise. Let’s say you set up an alert for a keyword, and you get your first 100 results within two hours. That’s amazing! You can see the value immediately. Then, because you’re on a trial, a limit kicks in and says, “You’re on a trial. You got your first 100 results. Now we’re throttling you down to 10-12 of these AI checks per hour. You had 250 per hour until now because that’s what a paid user would get. But we’ve reached a number of results significant enough to show you what you can get in the paid version.”

That’s what a trial is for, right? To show people what the paid version would get them.

The Benefits and Considerations

The benefit here would be front-loading the time to first value. The “drawback” would be that people would still have trial time left but with limited functionality. But if they want to keep receiving that flood of data, they can just upgrade to the paid plan.

And isn’t that what every SaaS business ideally wants—for people to upgrade to the paid plan as fast as possible? So it’s not really a drawback for the customer. They got to see the value, experience the inflow of data, and now they can upgrade if they need to keep that data rolling in.

I think this is a fair change to make.

Alternative Approaches

I’ve considered other options:

1. Manual limit increases: This is something I occasionally do when customers talk to me about it. But it’s an overly hands-on approach that doesn’t scale well.
2. Selective approval: I could do some kind of value judgment on whether an alert setup is “smart enough” and confirm larger limits for certain alerts. But this also feels fiddly.

I think basing limits on the number of results per alert is a better way forward.

Potential Risks

The only risk I see is with nonsensical alerts. If I only count positive findings and an alert never finds anything, it could still be a constant drain on my resources. This could be problematic with people having highly generic keywords.

I need to ensure that if a scan runs 1000 times with an AI component and not a single result is found, I can determine whether that’s just bad luck or a misconfiguration.

So I need two limits:

1. A cap on the number of high-quality results found
2. A backstop where, if no results are found after a significant number of attempts, I also reduce the limits

I’ll also want to maintain the ability to manually override these limits for specific customers when appropriate.

Why This Matters

I’m sharing my thought process because I want to show you how nuanced it can be to make a business decision that’s also a technical decision and a financial decision. We’re running into these kinds of challenges all the time—at least once a week for me.

I’ve been talking a lot about making data available to larger customers who want summary data or data exports. I’ve been building a system that exports each day’s full podcast episode collection—tens of thousands of described episodes—into one big file so that companies can download it if they want to pay for it.

This raises similar questions: It causes a lot of database queries and storage requirements that need to be balanced and priced appropriately. I can’t just make features available because I can build them; I need to make them available to those who are willing and able to pay for the resources they consume.

It’s always a balance between resources you have and resources that other people have (which, in our case, is money). The revenue-expense calculation needs to fit.

The Takeaway

I hope there’s something in here that you can apply to your own business—how you can present value as quickly as possible while ensuring that users understand they should upgrade if they want to keep accessing that value.

Just because you offer a seven-day trial doesn’t mean you can’t limit it. You can limit a trial, and if users need more, they can upgrade. You could just as easily have offered a two-day trial, after which they would have to upgrade. It’s all completely arbitrary.

The key argument is: charge for things that cost you money, but allow people to see what paying you would give them. That’s what a free trial is all about, and that’s the decision framework I apply to this problem.

​

​

​

We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!

​

​

​

Thank you for reading this week’s essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and ​share this issue on Twitter.​

If you want to reach tens of thousands of creators, makers, and dreamers, you can ​apply to sponsor ​an episode of this newsletter. Or just reply to this email!

​