Dear founder,
Yesterday, I shrunk the size of my production database from four terabytes to just under one terabyte.
Still ginormous, but very impactful for Podscan, in several ways.
Something interesting happened last weekend that made me realize I needed to change how I think about scale.
🎧 Listen to this on my podcast.
While checking my monitoring dashboards, I noticed a pattern in Podscan’s data ingestion that would significantly change how I approach orchestrating my bootstrapped business.
Let me back up a bit and give you some context.
Podscan has grown to process millions of podcast episodes, with a database that’s now multiple terabytes in size. As a bootstrapped founder, this creates an interesting tension: I need to keep the business running lean while handling an ever-growing mountain of data. With about six months of runway left, I’m at that critical stage where every decision about scale matters.
The good news is that if our current subscriber growth continues, we’ll hit profitability within those six months. But here’s the catch – we’ll only get there if I can thread the needle between two competing forces: growing revenue while keeping expenses in check. Or better yet, finding ways to reduce costs without compromising the product.
The Weekend Discovery
Back to that weekend observation. I noticed something fascinating in our ingestion patterns: On weekdays, we process about 50,000 episodes daily, with roughly 40,000 being fresh releases. But on weekends? The number of new episodes drops dramatically – sometimes to as low as 5,000-10,000 on a Saturday morning.
This means that during the week, we’re processing 25% more episodes than necessary to stay current. And on weekends, we’re running at nearly full capacity mostly processing historical backlog.
That’s when it hit me: we’re over-indexing our resources on content that might never provide value to our users. Both in terms of older episodes that aren’t of much interest to those who need mention alerts, and even within the freshly released episodes.
The Smart Bootstrapper’s Approach to Scale
This realization led me to question a core assumption about Podscan. Did we really need to process every single podcast episode immediately? Our users – mainly people tracking brand mentions and market trends – aren’t typically interested in every type of podcast content.
Some kinds are always interesting, yes. But others, not.
Think about it: there are thousands of daily Bible readings, church sermons, and music showcase podcasts. While valuable content, they rarely trigger the kind of brand mentions or industry discussions our users track. Yet, we were giving them equal priority in our processing pipeline.
Technical Optimizations That Made a Difference
Over the last few months, I’ve been experimenting with various technical optimizations to handle our growing scale. And my new realizations fit right into those prioritization frameworks. Here are some key learnings that might help other founders facing similar challenges:
- Smart Database Management: I discovered that running on a smallish CPU instance with carefully optimized queries often performs better than throwing money at bigger hardware. It’s not about having the most powerful database – it’s about being smart with how you use it.
- Chunk-Size Automation: I chunk every query that touches more than 10 database rows at a time. For large-scale operations, I built a self-aware system that automatically adjusts the chunk size based on processing time. If an operation takes between 1-5 seconds, we maintain the chunk size. Faster? We increase it. Slower? We decrease it. This has been a game-changer for managing large-scale operations without overwhelming our resources. Just let the performance of the moment determine how heavy the load is. This is called back-pressure, and it works.
- Compression as a Superpower: Perhaps the most impactful change was implementing automatic compression for large text fields. By using Gzip compression with base64 encoding instead of raw test, we reduced our storage needs by about 85%. The beauty of this solution is that it’s completely transparent to users – they get the same high-quality data, but we’re using a fraction of the storage and bandwidth.
The Path Forward
These insights led to a fundamental shift in how I’m approaching Podscan’s “growth” — the ingestion side of it. Instead of trying to process everything immediately, we’re moving to a more intelligent system that prioritizes content based on user needs. This means we can potentially cut our server costs by up to 50% without compromising the core value we provide to customers — we might transcribe fewer episodes, but the value for our customers remains the same. They might even see results faster because “non-interesting” stuff gets deferred to later.
This experience reminded me of an essential truth about bootstrapping: it’s not just about building features or acquiring customers. Sometimes, the most impactful work happens when you step back and question your assumptions about how things should work.
For now, I’m focusing more on sales and outreach —I’ll share more about this next week— while implementing these database optimizations. Podscan already has the core features needed to be a valuable social listening tool. The challenge isn’t adding more features – it’s making sure we can sustainably deliver value to our growing user base.
Remember, being a smart bootstrapper isn’t about having infinite resources. It’s about being thoughtful with the resources you have and continuously finding ways to do more with less. Sometimes, the best way to scale isn’t to build more – it’s to build smarter.
If you want to track your brand mentions on podcasts, please 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!