I wrote about the tech stack of Listen Notes in early 2018 (with a slight update in 2019) in a blog post that got shared several times on Hacker News. It’s 2025 now, and with the evolution of our product lineup, my mindset, and technology itself (plus the decay of outdated tools), I think it’s time for a refresh.
Back in 2018/2019, during the early years of Listen Notes, I focused on how to build products fast and get the right product off the ground. It was our “building phase”—similar to opening a new coffee shop, where you focus on interior design, sourcing coffee beans, designing the menu, etc.
Now in 2025, Listen Notes has a mature product lineup. Our main focus has shifted to stability (aiming for ~100% uptime) and sustainability (ensuring Listen Notes remains a key player in podcasting even 10 or 20 years from now), much like running a coffee shop that consistently serves great coffee day in and day out.
Overview
So What Is Listen Notes?
Listen Notes, Inc. is a company I started in October 2017. Initially, it was a single-page web app to search podcast episodes by keyword. This is how listennotes.com looked like in 2017:
As you can see, the 2017 version of ListenNotes.com was quite basic. I hope this inspires you to launch your own web projects. Remember, launching is just the beginning—most of the work comes afterward.
Now in 2025, Listen Notes is one database with three user interfaces (UIs):
One Database: The best podcast database with high-quality metadata and (ideally) close to zero AI-generated fake podcasts.
Three UIs to query the database:
A website for discovering podcasts: ListenNotes.com
A Podcast API for developers to integrate podcast discovery into their apps: PodcastAPI.com
A “bring your own UI” option where you get raw data from us and use your preferred UIs (e.g., Excel, Google Sheets, SQLite, etc.) to explore the data.
We also offer a few small-ish products. For example, we have a Cloudflare-based open-source CMS called microfeed and a fast podcast transcription/summarization tool called Listen411 (or Transcript.New).
At this point, Listen Notes has more than one person to work on it (with a single-digit team size, and some even part-time). The exact number fluctuates based on our current technical and non-technical tasks. I believe we’ll see more companies like this—lean, efficient teams where not everyone needs to be full-time. I’ve been inspired by how Gumroad is run.
I’d like to openly share how we run Listen Notes. However, as a private company, I can only disclose what I feel comfortable with. Like other companies (e.g., 37signals), we strive for a certain level of transparency but choose not to share revenue or highly detailed stats.
While some startups embrace radical transparency (kudos to them!), most companies—including ours—prefer to keep some things private. We appreciate your understanding.
You might find this article interesting: The Golden Era of Being an Open Startup Is Gone. There’s a darker side to human nature—when you try to be transparent, some people criticize you for not being transparent enough. It’s like donating to someone, only to be told it wasn’t enough. Let’s see how this goes. Fingers crossed.
This will be a long post, but here’s a quick summary of the Listen Notes tech and non-tech stack in 2025. (Apologies if some cool, new tools you love are missing!)
Engineering
OS: Ubuntu Linux
Cloud Hosting: Amazon AWS, Google Cloud, Cloudflare R2 + Pages
Web Backend: Python, astral-sh/uv, Django, uwsgi, Nginx, supervisord
Web Frontend: ReactJs, Tailwind, Webpack, Volta
Async Workers: Celery, bash scripts, Docker
DevOps: Ansible, Slack
Datastore: Postgres, Elasticsearch, Redis, ClickHouse
Monitoring & Alerting: BetterStack
Performance & Security: Cloudflare CDN / Firewalls / Turnstile
Payments: Stripe, PayPal
AI-Assisted Coding: ChatGPT
Design: Figma
Non-Engineering
Documents: Notion, Microsoft Office 365
Legal: Clerky, Stripe Atlas
Contractors / Freelancers: UpWork, 99designs, Facebook Groups
Domain Names: Cloudflare Registrar
Helpdesk: HelpScout
Emails: Superhuman, Google Workspace, Cloudflare Email Routing
Small Website Building: microfeed.org with Cloudflare R2 & Pages
Bookkeeping: Quickbooks Online
Office / Company address: WeWork
How We Build Listen Notes Software
The main products of Listen Notes are not particularly “technical”, because we don’t do deep AI research like OpenAI or build defense tech like Anduril or cure cancer. We just build superficial CRUD apps—like many web products today. As mentioned earlier, our main web app consists of one database and three UIs. Our code lives in a monorepo containing Django/Python for the backend, ReactJs for the web frontend, and various bash scripts/Ansible YAML files for DevOps. We use multiple data stores, including Postgres, Elasticsearch, Redis, and ClickHouse.
Other small-ish projects (like microfeed and Listen411) have separate repos, but this article primarily focuses on our main Listen Notes business—the monorepo.
One Database
If I remember correctly, the most profitable AWS products are all database-related. While we run on AWS, we don’t pay for those managed database products—we run open-source datastore software on AWS EC2 instances for cost efficiency. Sustainability is key: we want to provide excellent service without running out of money.
Personally I enjoy shopping for new EC2 instance types—comparing specs, pricing, and benchmarking—especially after AWS re:Invent each year. It's a bit like how others love shopping for handbags, watches, or cars. I don’t know if it's a healthy (and admittedly expensive) hobby!
The Single Source of Truth: Postgres
We use Postgres as our primary data store, which has grown to over 1.2 TB. In the doomsday scenario, even if the code base or servers were gone, with our Postgres dump, the business could be restored. That’s how critical it is.
When Listen Notes started, we used Postgres 9.6; now we’re on Postgres 17.0 (as of writing this post in early 2025). I remember each major upgrade vividly, almost like flipping through a family album.
Our Python code—running on async worker servers (from compute-optimized EC2 instances like c5 to c6i to c7g)—ingests and processes podcast metadata, which then flows into Postgres. Most data related to the website (e.g., user info) & API are also stored in Postgres.
Our Postgres cluster typically has 3 (sometimes 4 or 5) instances: one primary (for writes and some reads) and several read-only replicas with short query timeouts (e.g., 30 seconds). These servers run on storage-optimized EC2 instances (e.g., i3 → i3en → im4gn & is4gen). We avoid AWS RDS for cost and control reasons (e.g., lack of root access).
Over time, we’ve accumulated many custom bash scripts for routine DBA tasks, some scheduled, others ad-hoc.
Search Engine: Elasticsearch
The heart of Listen Notes is our podcast search engine. We index all public podcasts and episodes in the world—now totaling over ~200 million documents. (For comparison, in 1998 Google indexed ~25 million web pages, which was a lot then.)
Our Elasticsearch cluster runs on storage-optimized EC2 instances. Whenever a podcast or episode is added, updated, or deleted, we sync the corresponding document from Postgres to Elasticsearch. We run periodic jobs to keep the two copies of data almost perfectly in sync.
Search queries—whether triggered on the website, via the Podcast API, or from internal scripts—are routed from our Python code to the Elasticsearch cluster.
Analytics: ClickHouse
We store analytics data (like API / listen / search logs) in our own ClickHouse installation. Added to our tech stack around 2020, ClickHouse has proven to be robust and fast for data warehousing. Kudos to the ClickHouse team!
Fast & Ephemeral Datastore: Redis
We rely on Redis as a cache for rate limiting, feature switches, and other performance-critical functions. Our Redis instances, hosted on memory-optimized EC2 instances, are among the longest-running servers in production, sometimes for 2–3 years before an instance upgrade—remember I enjoy shopping for new EC2 instance types? :)
What Is “One Database”?
Technically, our “one database” is the logical “Podcast Database.” In practice, various data types are spread across Postgres, Elasticsearch, ClickHouse, and Redis. Even data like API / listen / search logs contribute indirectly (e.g., to our Listen Score). In any CRUD app, the data layer is critical—and it’s especially true for our business.
Three UIs
In today’s world, UIs aren’t necessarily graphical—APIs and even voice interfaces (e.g., Amazon Echo) count. For Listen Notes, our three UIs are:
UI #1: The Website (listennotes.com)
Our website is a typical Django app with Views, Models, Celery tasks, and more. When I first wrote Listen Notes (late 2016), I used Django 1.9 and Python 2.7; today, we run Django 5.1 and Python 3.13.
We organize our Django code into “apps” (e.g., playlists, episodes, datasets) with standard files like views.py, models.py, and admin.py. As some files grew large, we broke them into multiple view files (e.g., views_xxx.py, views_yyy.py, views_zzz.py, etc.)
We used to use virtualenv and pip, but since early 2025 we’ve switched to uv. We found that uv is extremely useful for managing multiple Python projects across various versions—even when some dependency libraries don't yet support Python 3.13.
Most webpages on ListenNotes.com are partly server-side rendered (Django templates) and partly client-side (a React single-page app compiled via Webpack with Volta to pin NodeJs versions). Although some criticize JS bundles and prefer vanilla JavaScript, we haven’t found major issues with our current approach. We simply cannot commit to a multi-week migration project based solely on a random blog post on the Internet—what works as best practices for others may not suit our needs.
For async tasks triggered by user events (e.g., sending transactional emails), we offload to Celery async workers.
In production, Django is served via uwsgi (managed by supervisord) behind an nginx load balancer. We group uwsgi processes to prevent one slow page type (e.g., search) from affecting other page types (e.g., feed).
UI #2: The Podcast API (PodcastAPI.com)
I wrote about building our Podcast API a few years ago. While the core remains the same, we’ve added more API endpoints, data attributes, SDKs for multiple languages, and even a self-hosted code playground.
We launched the API in December 2017, and it’s now integrated into thousands of apps and websites.
Initially, we used RapidAPI (then Mashape) to manage and monetize the API. However, after experiencing multiple RapidAPI outages, we spent a month building our own API gateway. This not only improved our reliability but also saved us from paying RapidAPI's 20% commission fee. While paying 20% might be acceptable for a side project, it's simply too high for a serious API business.
Our API gateway is now part of our monolithic Django app, handling rate limits, authentication, authorization, caching, and the actual request processing.
To let users try the API without writing code, we built our own multi-language code playground using Docker for an isolated environment.
UI #3: “Bring Your Own UI”
We allow customers to export raw podcast metadata and explore it in their favorite tools (Excel, Google Sheets, etc.).
As a small business that serves many other small businesses, we favor an on-demand pricing model. Small customers might spend $10–$20 multiple times a year to access just the data they need, while larger customers can purchase the entire podcast database delivered as a SQLite file.
We have extensive Python scripts to handle batch data exports and automatically deduplicate records from previous orders.
Design
When we first started Listen Notes, we used Sketch for all our design assets.
In mid-2018, while working with a designer on our website redesign, we were introduced to Figma. Since then, it has become our go-to tool for all design assets.
How Do We Make Money?
I know some idealistic developers believe everything on the Internet should be free or that the only moral way to earn is via a 9-to-5 job or donations. Listen Notes is a for-profit company—like a coffee shop, we have operating costs, and the people behind Listen Notes need to earn a living. If money wasn’t a concern (e.g., maybe become a trust fund kid in my next life?:), Listen Notes might be 100% free.
We monetization via the aforementioned three UIs:
UI #1 (Website): Free for 99.9% of users (with ads), with some premium features behind a paywall (no ads). Instead of forcing long-term subscriptions, we offer one-time “2-day passes” (think Disneyland tickets) by default, which many customers repurchase over several years.
UI #2 (API): Operates on a freemium model. There’s a free plan for side projects, a self-service PRO plan (with fair pricing—if you use zero requests, you pay nothing), and an Enterprise plan involving a sales process.
UI #3 (Data Exports): Self-service options let users buy a small piece of data on demand, while enterprise customers follow a full sales process.
We use PandaDoc for contract management and both Stripe and PayPal for payment collection. Using two payment processors offers peace of mind in case one fails or bans us.
We appreciate Stripe’s highly friendly and competent customer support, along with its excellent developer experience. However, when it comes to handling dispute charges, PayPal significantly outperforms Stripe.
Any business that accepts credit card payments will inevitably face customer disputes—malicious claims are simply unavoidable. Fortunately, Listen Notes experiences only one or two disputes per year. When processed via PayPal, our win rate is nearly 100%, compared to about 15% when handled through Stripe. To be clear, this isn’t Stripe’s fault; it’s the credit card networks (Visa, MasterCard, American Express) that ultimately decide the outcome, with Stripe merely acting as the intermediary.
To minimize disputes, we follow several best practices: offering a great product, providing excellent customer service, and ensuring that customers clearly understand the terms before payment. For our self-service tools, we display a prominent modal that outlines the terms and requires customers to click the “I Agree” button before proceeding. While this might deter some users, it effectively reduces the risk of future disputes—a trade-off we are willing to make.
Additionally, our self-service tools automatically send PDF invoices to customers. These invoices are created by taking a screenshot of the HTML version of the invoice using headless Chrome and Puppeteer.
Internal Tools
Running a database business means continuously maintaining and cleaning the data.
Our internal tools help us:
Manually review newly added podcasts to ensure they don’t violate our content policies.
Auto-detect AI-generated fake podcasts and streamline the review process.
Handle user account operations (merging duplicate accounts, blocking bad actors, etc.).
Toggle feature switches to ensure confidence when launching new features.
Enhance customer support by instantly retrieving all essential details about a specific user or podcast—it’s like having a co-pilot.
…
These internal tools are built into our monolithic Django app and include a web portal as well as ChatOps (command-line tools within Slack) for quick operations.
AI / Machine Learning
We maintain several small repos for AI/ML projects, primarily for features like “PEOPLE ALSO LIKE THESE PODCASTS.” But recently, we’ve had to use AI to fight AI —
With tools like NotebookLM making it easier than ever to mass-produce fake podcasts, spammers have begun inserting casino links into AI-generated podcasts and distributing them across platforms. Listen Notes was the first to crack down on this issue. We developed multiple models to detect AI-generated fake podcasts and even open-sourced a simple one: notebooklm-detector.
A few months ago, we reached out to Notebook LM’s lead PM to ask if they had tools for detecting Notebook LM-generated audio. She initially said yes but struggled for weeks to follow up before eventually leaving Google with several colleagues. It’s unclear how serious Google is about this project.
Regardless, fighting AI-generated fake podcasts remains an ongoing effort. We invested in a maxed-out Mac Mini with an M4 chip to train models and refine our detection and review process. We’ve also uploaded some generated fake podcasts to Kaggle, hoping the community can collaborate to combat AI-generated spam effectively.
How We Do Dev and DevOps
Dev Environment
We host our repos on both Bitbucket and GitHub for vendor redundancy. All production servers run on Ubuntu Linux. As for our devbox, we run Ubuntu inside Parallels + Vagrant on macOS.
I personally code in PyCharm. I tried VS Code a few times in the past few years but always returned to PyCharm (I'm sorry; I promise I'll give VC Code another try in a few months to see if the chemistry is there. :) I also used GitHub Copilot for a year (2024) but eventually canceled the subscription. Nowadays, I often rely on ChatGPT for writing small bash scripts, React components, or Python functions—it’s like having an intern to do self-contained coding tasks for $20/month.
Cloud Hosting
In 2017, we used three $10/month DigitalOcean droplets. In early 2018, we switched to AWS (thanks to WeWork’s $5,000 AWS credits). Since then, we’ve become a loyal AWS customer. While cheaper alternatives exist, the cost of downtime or poor support is far higher in human and customer trust terms. AWS remains our choice, even though it’s our second biggest expense after human costs.
For EC2 instances, we always purchase reserved instances and pre-pay where possible. It’s a significant expense but well worth it.
We provision servers using Ansible. This lets us spin up an EC2 instance and have it fully configured automatically.
Data Backup
Our primary data (in Postgres) is our single source of truth, replicated across multiple servers in realtime. We also run daily backups like this (encapsulated in a cron job):
Run pg_dump on one of our read-only Postgres servers.
Encrypt the dump with GPG.
Upload to AWS S3, Google Cloud Storage, and Cloudflare R2 - I hope these three public companies don’t lose our data all at once :)
Code Deployment
We deploy our Django and React code directly from MacBook Pro using an Ansible-orchestrated script. Our process is simple and effective—compile assets (JS/CSS), upload to Cloudflare R2 (served via Cloudflare CDN), and check out latest Django code on production servers via Ansible. A load balancer (nginx) ensures zero downtime by temporarily removing some uwsgi processes during deployments.
Monitoring and Alerting
In the past, we used Datadog, PagerDuty, and Atlassian Statuspage, costing ~$3,500 annually.
As a small business owner, I frequently evaluate whether there are more affordable and better alternatives to the tools we use. Recently (early 2025), I found BetterStack. And we’ve already moved our entire monitoring & alerting stack to BetterStack—a bundled solution that cut our monitoring costs by 90% and offers responsive, friendly support.
Fighting Bad Guys/Bots
All requests to ListenNotes.com & Podcast API pass through Cloudflare, which provides CDN, firewall, and DDoS protection. We’ve set up custom firewall rules for different web pages and API endpoints. Our internal tools also integrate with Cloudflare’s API, allowing us to block or challenge malicious IP addresses with a click. To protect some compute-intensive pages on our website, we used to use Google reCAPTCHA, but since early 2025 we’ve switched to Cloudflare Turnstile—it's free and works well.
Major Upgrades
We periodically upgrade key software components—such as Ubuntu, Postgres, Elasticsearch, and Django—to apply bug fixes, introduce new features, enhance security, and boost performance. Additionally, we update our EC2 instance types to optimize the price/performance ratio. Each upgrade is meticulously planned and rehearsed, which has prevented outages over the past eight years. These tasks remain too critical to fully trust to AI for now.
What Tools We Use to Run Listen Notes, Inc.
This section covers the non-technical aspects of running the company—the parts I wish someone had shared at length when I started Listen Notes in 2017.
Customer Support
Great customer support is the best form of marketing. I personally reply to most customer support emails, typically within an hour (and almost always within 12 hours).
Two key tools help us do great customer support:
Documentation & Help Articles: We use HelpScout for our helpdesk (listennotes.help). We used to use Intercom until I switched to HelpScout: more affordable and better!
Email Client: I use Superhuman. Over the years, I’ve accumulated a lot of email snippets that lets me reply to most customer support messages within seconds—right inside Superhuman using shortcuts.
We treat our customers the way we wish to be treated by any software or hardware vendor's support team. As customers, we all want prompt responses and we want to deal with honest, friendly, and competent human beings.
Marketing
We have multiple marketing channels. But the two most effective channels so far are:
Providing great customer service that leads to positive word-of-mouth.
Buy Google Ads. We’ve experimented with Facebook and Twitter ads, but Google Ads has proven most effective for us.
Banking and Business Credit Cards
We hold several checking accounts with major U.S. banks and Mercury that allows no-fee international wires. Why do we maintain checking accounts at multiple banks? Simply in case one experiences technical issues, goes bankrupt, or de-banks us—vendor redundancy gives us peace of mind.
We also park our cash in Vanguard (VUSXX yielding 4+% as of early 2025). Caveat: Opening a Vanguard business account required multiple phone calls—a true test of patience.
For business credit cards, we favor:
Amex Business Gold: 4x points for advertising and software/hardware (except AWS).
Amex Blue Business Plus: 2x points for all expenses under $50k/year.
Chase Ink Business Preferred: 3x points for travel expenses.
Amex Amazon Business Prime: 5x cashback on Amazon expenses, including AWS.
These cards help us maximize rewards by allowing points transfers to airline and hotel loyalty programs (e.g., Chase to Hyatt), significantly reducing our conference travel expenses.
Legal
We incorporated Listen Notes, Inc. through Stripe Atlas in 2017. Stripe’s customer support has always been friendly, competent, and incredibly helpful.
For quick legal paperwork, we use Clerky, which offers on-demand pricing.
For more complex legal matters, such as sales contracts, we work with a local law firm.
Company Documents and Project Management
We’ve used Notion since early 2018 for wikis and project planning. While it might not be perfect for every feature, it consolidates many useful tools in one place. We maintain runbooks for DevOps, DBA tasks, financial tables, and monthly kanban boards. Although cool kids use Linear nowadays, Notion works well for our small team.
We also pay for Microsoft Office 365 to ensure compatibility with enterprise customers who rely on Word, Excel, and Teams.
Payrolls and Benefits
Since 2017, Gusto has reliably handled our payroll without excessive upselling. We also use it to send job offers, which significantly streamlines the process. Additionally, Gusto manages our payroll-related taxes, including withholding taxes and W-2 forms. It's a very reliable service—we love it.
We use Lively (integrated with Schwab) for HSA and E*TRADE for 401k. It took me quite a while to figure out how to do these things—a lot of Googling, Reddit-ing, and many phone calls with other humans in the pre-ChatGPT era—but I’m glad it’s finally done. This might be the fun (or not-so-fun) part of being a small business owner!
Contractors / Freelancers
I personally believe that in the future, it will be normal for people to work multiple part-time jobs and have multiple income streams. Pay cycles will likely become more frequent than the traditional bi-weekly paycheck—ideally in real time, where you get paid immediately after completing a task.
At Listen Notes, we frequently work with contractors and freelancers. A common example is hiring a CPA for tax prep—there’s no need for a full-time, in-house CPA at a tiny company. For design work or experimental projects, we often turn to platforms like Upwork or 99designs. I also enjoy hiring multiple people for the same task and comparing their results. While this approach can be more expensive, I value redundancy and having options.
Occasionally, we also find freelancers through Facebook Groups, generate contracts using Clerky, and process payments via Gusto.
Domain Names and Corporate Emails
We register dozens of domains through Cloudflare, GoDaddy, and Namecheap (since some TLDs are only available on certain registrars).
Our corporate emails (e.g., hello@listennotes.com) are managed through Google Workspace, while some wildcard/project-specific addresses are handled via Cloudflare Email Routing (e.g., hello@listen411.com).
BTW - we have several domain names for sale. Email hello@listennotes.com if you are interested:
breaker.fm
listen.host
listenhost.com
inka.fm
Misc. Small Websites
Aside from our core products, we run several small websites using our own opensource project microfeed -
Listen Notes Changelogs: changelog.listennotes.com
Our mascot llamacorn: llamacorn.listennotes.com
Listen Notes brand assets: brand-assets.listennotes.com
Microfeed is a lightweight CMS built on the Cloudflare stack and originally designed for podcast hosting. Using microfeed allows us to host these “micro” sites on Cloudflare at virtually no cost. We plan to create more fun “micro” sites with microfeed in the future!
Office
Before COVID, we had a small office at WeWork. During the pandemic, we shifted to working from home. Now, we've returned to a dedicated private office at WeWork, which also serves as our business address. While knowledge workers can technically work from home, having a separate workspace often boosts productivity—at least it does for me.
Bookkeeping
We do bookkeeping on our own using Quickbooks Online. While there was indeed a learning curve for us in early 2018, we have steadily improved over the past few years.
Many VC-funded tax startups aim to generate recurring revenue by offering bookkeeping services (kind of like SaaS?), which in turn helps justify their valuations. However, as a small business owner, you might not need these services. If your financial operations are straightforward, handling bookkeeping internally can deepen your understanding of your business finances and enhance your financial acumen. After all, if you can flip binary tree, there's no reason you can't grasp some basic financial principles :)
Conclusion
Thanks for reading this long blog post. I truly wish I’d had a resource like this when I started Listen Notes in 2017. I hope sharing our practical tools and practices can help others running a small software business.
You don't have to chase every new tool or tech trend. Many of the tools we rely on have been around for over a decade—some even longer. In fact, podcast as a media format is 20+ years old!
Our focus remains on stability and sustainability. We’ve been around for 8 years. Look forward to next 8 years~
This blog post was initially published at https://www.listennotes.com/blog/tech-non-tech-stacks-to-run-listen-notes-2025-113/