Transcript: Listen Notes - Wenbin Fang
Hello, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.
I'm Will Vincent, joined as always by Carlton Gibson. Hi, Carlton.
Hi, Will.
And this week, we're joined by Wenbin from ListenNotes. Hi, how are you?
I'm good. How are you?
I'm good. Thank you for joining us.
Yeah, thanks for coming on, Wenbin.
We wanted to have you on because we both loved your article on the boring tech behind a one-person internet company,
And that actually blew up on Hacker News recently and justifies a lot of the points that Carlton and I try to make around keeping it simple, even at scale.
So we'd love to talk to you about how you do that.
So for folks who don't know, what is ListenNotes?
What's the quick pitch?
Yeah.
So ListenNotes is a search engine for podcasts.
It's like Google, but for podcasts.
So you type in keywords and then you can search the whole internet, podcasts and episodes.
and we also provide APIs for developers.
If you want to build a podcast app
or podcast reality services,
just use our API to search a podcast
to fetch podcast metadata.
Right, so if I wanted to make an app
best Django podcasts,
I could use your API
and I'd come up with a list of Django podcasts
and Django Chat would be the number one Django podcast
and I could listen to that.
Yeah, probably the one and only.
Yeah, yeah, yeah.
Super.
One and only.
And how long have you been working on this?
Yeah, so I started Distant Nodes as a side project in early 2017, January 2017.
I spent probably one week still to get a quick prototype for Distant Nodes.
And then I didn't touch the code base for about nine months.
Because during that time, I was running my first startup, which eventually failed.
And in September 2017, I dived the startup.
I co-founded it, and I needed to find something to do.
So I picked up ListenNose and worked on it a little bit,
and I worked on it full-time, and I incorporated it as a company,
a one-person company, until now.
Actually, this month will be the two-year anniversary for ListenNose.
Oh, wow.
It's a company.
Congratulations.
fantastic it was really good thank you and you still one man still one person uh full-time
employee yes one full-time employee give me but i hire some uh contractors on and off for different
things like design content or some front-end development something like that yeah okay so
one thing i wanted to ask you because for beginners to python they hear something like
i did a prototype in a week or a weekend and it sounds unimaginable so i'm so i wonder if you can
recall so what did that actually involve i mean start project like what is a what is a bare bones
prototype look like for this because that's something that yeah newcomers don't understand
how that can be done yeah yeah so if you look at listen notes.com today it's quite complex
it has search engine it has a playlist has api a lot of things but back to the beginning
the project requirement
was very simple. I just
want to search
podcast episodes. Let's see.
A search bar, type in keyword,
see the search results. Let's see.
And
I basically started
with the Django
template. I believe
the command line is django start
or something like that. Yeah. So start a simple
project.
Basically, I started the barebone project
I added one view for a search page.
And I spin up Elasticsearch instance, index data.
So basically, I have three digital OS and instances,
one for web server running Django, one for Elasticsearch,
and then one for PostgreSQL database.
So how did you get the initial data?
Where did that come from?
Oh, so there are only a few well-known podcast directories on the internet.
Okay.
So did you scrape them or something?
So I scraped them, and then gradually I built internal tools so I can submit myself.
Also podcasters can submit themselves.
So let's say today you start a podcast today, you need to submit your podcast to somewhere.
We submit to Spotify, to iTunes, and listen to notes.
So every day we are getting close to 100 podcast submissions from podcasters themselves.
So you started with a simple page, you had your Elasticsearch, you had the initial data.
So Elasticsearch, that's not a simple thing to spin up.
I mean, clearly you've worked with Elasticsearch before, right?
Yeah, I had some experience.
So basically, I follow some simple nodes I took a few years ago, setting it up.
It was not too difficult because I did it before.
Were you just running like the single node?
Yeah, single node.
Because you're meant to have the duplication and the replicas,
and that's when it starts to get a bit hairy because you're…
Right now, I have a cluster, but back then, it was a single node.
Okay.
Yeah, well, it's especially relevant to me because at DjangoCon this year, I gave a talk on search, talking about basic search and then with Postgres built-in search.
I'm curious, did you ever consider using built-in, you know, the full-text search in Postgres, or did you already know Elasticsearch?
So was that a consider?
Yeah, so I actually use Postgres full-text search for my other small site projects with a small amount of data.
At the beginning of this Senos project, I did some testing with Postgres, full-text search.
It was very slow, if I remember correctly.
It was very slow, so I gave up quickly, maybe because of the amount of data that we need to index.
Right, it's ingestion speed.
Right, because it seems like you're pulling in data, but data that's already there isn't going to change much,
so you can index it and query it pretty quickly.
No, it changes a lot.
Oh, it changed a lot.
The index data changed a lot.
Well, what...
Because...
So there's new shows
and then there's new episodes, right?
Is it more...
Episodes.
What else?
And episodes data,
podcast data
change all the time.
Oh, okay.
Probably you guys
don't update your podcast much,
but, you know,
if you have
the whole internet
as podcast data,
at any given time,
there are some podcasts
change their description,
title,
ISS feed,
Audio URL, all kinds of things.
Well, so I wanted to ask, so in your article from, was it May of 2019, you said there's
20 production servers and many of those are workers.
Could you describe the setup of workers you're using to pull in this information?
Sure.
So for workers, basically they are asynchronous processing task workers.
I use Celery, C-E-L-E-R-Y, if your audience are familiar with Celery.
yeah so yeah with those some uh so so basically salaries uh uh is a hookup with a salary beat
which is a scheduler like clone yeah so we have some scheduled tasks like for for crawling data
uh pulling data from rss feed to add new episodes and salary also handles other async tasks
mostly compute-intensive tasks like sending emails, resizing images,
doing heavy database queries, things like that. Yeah. Well, I like that this is... I mean,
your use case is such a... It's complex, but it's also simple and that you can understand that it's
not tons and tons of workers. It's emails and checking for changes to the podcast directories.
so it makes a lot of sense so um so how much and i know you have all sorts of actually could you
talk about so you have monitoring involved and you've listed a whole bunch of tools right so
because otherwise you couldn't sleep at night what how did you think about or how did you baby step
from that right like if you recall like what did you start with and then now obviously you have
a lot of monitoring going on okay how would you tell yourself to do it you know someone's saying
Like, okay, what do I start with, right?
Because there's so many you can add.
Yeah, so basically we set up monitoring and alerting
to give us confidence about the health of the entire system, right?
So high level, you need to know the website is up.
The API is up, right?
So for monitoring, I use Datadog.
And Datadog is connecting to PagerDuty for alerting.
And for Datadog, we continuously ping the website and the API endpoint
and check the response to see if it's 200, if it's not 500.
Right.
And if it's not 200, then probably something is broken and I will get alert.
So high level, you need to have this kind of stuff.
But for individual components, you also need to monitor some metrics.
Like for Postgres, you need to monitor a few things.
For Radius, another few things.
Maybe MQ, Elasticsearch.
Each of them, I all have one or two alerts associated.
Yeah, and I think you mentioned for Django itself, you use Rollbar.
Is that still the tool that you like to use?
Yes, yes.
so i get the stack trace the full stack trace if something wrong yeah yeah well uh so carlton and
i spoke and we wanted to ask you about so you uh sort of proudly don't use docker at all um
and carlton is big on this wagon and no okay make the case my case my case is simply this
right but for 95 of django applications out there you don't need all this
hypha looting containers you want a vm and you want to bang your application on it and you want
to run it the good old-fashioned simple way because that vm will never go down that will
you you'll never have port issues you'll never have network issues like you don't need all this
massive containerization stuff
until you're scaling up
to something much, much, much bigger.
And look at what Wenbin's doing single-handedly.
So that would be the way I'd phrase it.
What's your experience?
Go ahead.
I was going to ask
if it would be different
if you had a team of developers
because to me,
that's in some ways
the biggest advantages on a team
having the same local setup
separate from...
Yeah.
Yeah.
What are your thoughts?
So I don't use Docker
because it's unnecessary for my situation.
For the workload, I'm running for the team.
I have basically just me as a backend engineer.
So Docker is good to provide a standardized container.
It is about, it's very portable.
So, you can run Docker container on your local dev.
You can run the same container in staging, in production.
You can spin up CI with Docker containers.
It's very convenient.
It's very easy to scale up and down.
But for my situation, well, I run all these servers for many, many months.
So I don't need to scale up and down often.
I don't have team so it's just me I basically set up everything I don't need standardization
for other people I mean maybe one use case you you might have say you want you you mentioned
RabbitMQ well maybe you don't want to install the whole Erlang VM and all the rest of it and
to use a container there to locally use RabbitMQ while you're developing or testing that seems
that would be that's one useful case where you know you don't need to go the whole hog with
docker you don't have to jump into yeah kubernetes or whatever to get to use it a bit yeah so for for
my previous uh job as a previous guy i work in nextdoor a local social network website yeah and
And in 2014, I believe it was me who introduced Docker to the company.
And so when did Docker come out?
Maybe 2013.
Something like that, yeah.
Right, okay.
Yeah.
So for a mid-size company, for mid-size staff with tens of engineers,
yeah, with Docker it's nice.
So basically, we standardize the dev environment
for all the engineers with Docker containers.
And so it's easy to set up.
Onboarding is easy.
Yeah, because onboarding is huge.
Yeah, you know, that's it.
I mean, this is where a few years ago
people were using Vagrant and VMs, right?
So because you get the development VM
and you just be able to Vagrant up and it would run.
But it's slow and heavy.
I'm using Vagrant.
Docker is much nicer.
Sorry, I'm using Vagrant right now.
Okay.
For this and those.
No, but I still use Vagrant Loads
because I'm a big advocate of VMs.
But Docker is quicker and lighter and, you know,
I can see why people like it for the development environment.
Yeah.
And for deployment.
Speaking of deployment, so you're on AWS, is that right?
Mm-hmm. Yep.
Now, I assume you have previous experience
because AWS is not the easiest thing to start with.
I'm curious if you talk about your experience
maybe with AWS versus other ones you've used professionally.
Yeah.
So earlier on, I mentioned that I spin up three digital ocean.
Oh, yeah.
You said that.
Yes.
They call the instance Droplist.
I don't know.
Because it's very lightweight or cheap.
Yeah, $5 or whatever.
Yeah, $5 per vans.
I had three instances for this and those as a side project.
I used the same setup for many vans.
Maybe one year after I started this side project, I migrated to AWS.
The reason was very, very simple because I started to work in WeWork.
And WeWork gave you $5,000 AWS credit.
And then I migrated to AWS.
I mostly just use EC2 instance.
Okay. I don't want to have a vendor log in with AWS. Yeah. I just use EC2 instance. Anything else? Oh, I also use S3.
Right. Yeah. I think in S3 and Cloud for your front end.
Yeah. Yeah.
Well, I guess that's a...
But again, that's very sensible, right?
Because Amazon, I mean, like each of the big services,
they've got 50, 60 different things that you can use if you want to.
But if you just focus on S3 or just focus on EC2
or two or three of the core services and get to know those,
it's not any more complex than any other provider.
It's just that they've also got QuickSight
and all these million AI offerings.
and do you need all of them?
Not for now.
So the front end,
so you have,
for a single person startup,
you're now running APIs
and using, I believe, React in the full bit.
Can you talk about that transition
and at what point you switched over
to using a dedicated front end?
Actually, at the very beginning,
I started to use WebJS.
Good for you.
So basically Django,
So, I did both back-end rendering and front-end rendering for HTML.
So, basically, Django renders the boilerplate for HTML,
and then React renders components inside the HTML page.
Right.
So, that first week prototype, you also hooked it up with React and Django REST framework?
Yeah.
Yeah.
Yeah.
That's awesome.
No, I'm just trying to think that's going to, you know, it's sort of something you can do when you have experienced listeners.
You can whip these things up, but I know that all those things sound like, just because I get so many questions about all of that, it takes some practice.
But once you get to know all the steps, right, you're sort of duplicating your own steps, right?
I'll just do my, this is how I hook in React.
Yeah.
On GitHub, you can find many boilerplate starters.
So basically, you run one command,
and then it gives you the project boilerplate.
For React, you're saying?
For React, for Django, for the whole project setup.
Did you use Cookie Cutter?
Which one are you referring to?
I don't remember I used some.
I don't remember exactly.
But I said that nowadays, you can find a lot of such tools.
if you want to get started quickly.
Yeah, well, I always wonder how good they are
and how much you understand them,
because, I mean, you can use them,
but then if you don't know what's going on...
Yeah, one downside using such tools
is you don't go very deep into the mechanisms
or all these things, yeah.
But again, it's that first prototype
versus, you know, what you end up with two years later.
Right, yeah, yeah, yeah.
Well, and just in terms of Django frameworks,
cookie cutter is probably the top one by far. I mean, I have my own one Django X that's simpler
by design, but I'm always curious if there's others out there I'm not aware of because
if there's an actually Django X, so my own one is at this middle ground where it's basically just
basic site with templates and authentication and custom user model. Um, but I could make it how I
start my projects now, which would be a lot more complex. It would make sort of become cookie
cutter, but I feel like that would make it less relevant to beginners who just want something up
and going. So there is sort of this tension, um, you know, between, yeah, simple and then what you
would actually use, uh, you know, cause cookie cutter is fantastic, but it's, it's, um, you need
to know what you're doing to use it. Um, okay. So the, so now something near and dear to Carlton's
heart. So the API, can you talk about managing performance on the API and any sort of steps
you've made along the way to serve all the data that you do all right let's see if you recall
yeah i'm trying i'm going back to my to to the memory about how i started api so okay so
as i said i started uh listen notes uh it's a side project and then i work on it full-time
starting in september 2017 and then after i run this website for a couple of months or so i got
some request from developers asking if I provide APIs.
So that was the end of 2017.
I was not sure whether API could be a viable business
or whether it deserves my time.
So I tried to build a quick prototype, quick and dirty
prototype, but I also want to be able to charge
people for using the API.
So I did some Googling, I found an API marketplace
called MashApe, M-A-S-H-A-P-E.
It doesn't exist anymore.
It was acquired by a startup called Rapid API.
So they rebranded this thing as Rapid API right now.
It still exists, but it's a different name.
Okay, so I found this API marketplace, MashApe.
Basically it handles the payment, it handles API analytics.
It measures how many API requests API users use
during the billing cycle.
So they can do the billing calculation
and they handle some edge cases.
Or if a developer subscribe to your API plan
and unsubscribe, and then subscribe again.
Yeah, no, that's fantastic.
Or if you credit card, get declined, something like that.
I didn't want to deal with these things.
okay so good they handle all these things so basically what i needed to do was to provide
a few api endpoints and i hook up with their service okay sounds easy so i spent about two
hours using django rest framework building three endpoints api endpoints one for search one for
fetching podcast metadata by id when for fetching episode metadata by id that's it so i think these
are the minimum requirement for building a podcast app if you want to use my api okay so after two
hours i had the api business running and people slowly sign up but i didn't touch the api for
about one year you know api business has long cycle today someone discovered this is not api
good they sign up they spend six months building their app they spent another six months marketing
right right maybe another six months to gain some traction and then uh two two years later i start
to collect money from them. So API business is slow. I didn't put any effort on the API for about
one year. So the end of 2018, well, I saw some serious usage of the API. So tens of apps signed
up by that point and some paid users so i decided to uh to replace rapid api for the api gateway
stuff so i i wanted to build my own pavement my own api analytics stuff so there will be api v2
so i built this whole thing uh in the beginning of this year it's running now how long did i mean
I mean, that sounds like a lot of work.
Was that?
Three months, three months.
Three months.
Yes, so.
Right, okay, so that's a big commitment.
So basically I prefer building things up,
making incremental changes, small incremental changes.
So three months for me is a huge project.
It's unusual.
Yeah, well I like-
But I had to get it done, yeah.
I mean, I think that's a brilliant philosophy
fee, though, to use an off-the-shelf tool, confirm that there's market validation before you spend
the time, because that's the curse of engineers, is it's fun to build your own everything, but
it's usually not the best use of time unless it's a proven need. Wow. Man, I'm so impressed by that.
So the business itself now, so how does, in broad strokes, so you have the API that you charge for,
You have ads on the site itself.
How do you think about the business kind of where now and where you want it to be long term?
So right now it's kind of sustainable now for one person business.
I'm doing fine.
It's not going out of business any sooner.
But, yeah, I start to see a big picture of what's the long term.
So basically, I want ListenNotes to make podcasts accessible in general.
So let me explain a bit.
So how many people in the world right now?
Probably 8 billion, close to 8 billion.
How many people listen to podcasts today?
There's than 100 million.
Maybe there's than 50 million.
So there's still a lot of room to grow for podcasts or spoken audio in general.
So we human beings get information through eyes and through ears.
Most big companies nowadays are basically focused on screen time,
getting information through eyes.
But I think audio has a huge potential in the future.
You know, some companies like Apple, they're making AirPods, Amazon, they're making Echo.
These are all voice-first products.
And my instinct told me that audio could be something.
Yeah.
So if you can help people find audio content, maybe you will be a good business.
And let's come back to listen notes.
how can this and not help PolarCast become accessible?
So at this point, we don't build apps.
We don't build our own contents.
It's a website.
Website is easy for people to discover, to share, right?
Especially for international users.
And also we provide APIs,
so developers can quickly build PolarCast-related service
using the API.
They don't need to worry about the backend.
and this can somehow help the innovation
in the application space for PolarCast,
making PolarCast more accessible.
Yeah, this is why I think-
And do you, I mean, speaking of international,
do you use any of the international tools
within Django to, I mean, I see it in English,
but do you have other languages that you have support for?
Yes, we support more than 20 languages.
If you go to website, you scroll down to the button,
you see that you can switch to different languages.
Oh my goodness, yeah.
And are you using the built-in Django tools for this,
or what are you?
Yes, yes, yes.
I use the built-in Django I18n stuff.
It's very good.
I'm very satisfied with Django for this.
So basically, I generate a bunch of Django.po files,
And then I outsource for translators to translate into different languages.
Yep, very easy.
And do you use a service for that?
Because I know there are services that offer to find your translators,
or do you have to have a relationship with individual translators?
I use a service.
I've got a name.
It's called ChangeFX.
It is a service.
I can send you the link for the show notes.
Okay, we'll put it in the show notes.
I mean, it's interesting because lots of people have this issue.
Yeah, so basically the service provides a translation editor.
So you can see the English and the translated text side by side.
It's easy to translate.
And they also have partnership with some translation agencies.
So you can directly pay those agencies on the service.
But for certain languages, I cannot find translators there.
So I need to post on Upwork to find individual translators.
Yeah.
Well, congratulations on all those languages.
I mean, when I was in San Francisco, I worked at a company called Quizlet, and I worked a lot on the translation, which was literally we would get a Chinese teacher in San Francisco to translate the site.
We found a couple of users, and then we scaled up from there, and it's no easy thing.
know it's impressive that you have all these language and it takes yeah the the maintenance
right i mean that's sort of the i mean like for example i was reading through like i think i caught
a typo in one of your pages i forget if but you know if that were a word that would be something
then in every language next time you run through you have to translate certainly certainly yeah
yeah it's a far from perfect yeah so but still it's nice still a lot of it's still nice for
to see a site in your own language obviously i mean yeah i'm certainly guilty of assuming
everything's in english so um wow yeah i'm i'm very happy to see international users
using using uh listeners and yeah one thing i did want to ask is um you know what versions
are you up to date are you on python 3.7 3.8 this week are you on django 2.2 so i'm using
I've been using Django 2.1 and Python 3.6, 3.6.8.
Okay, so f-strings.
Yeah.
I started this in early 2017.
So back then, the latest version was 1.9, I believe.
I updated twice along the way, 1.9 to 2.0 and 2.0 to 2.1 for Django.
And how have you found that process?
Was it easy?
you hit oh yeah so uh i basically um allocate a couple days every few months to upgrade major
software components in the whole test deck so primarily ubuntu django postgres elastic search
i like to keep the keep using almost the latest version not the latest one maybe second to the
the latest one yeah okay and um it's i always say it's a bit like make um you know it's servicing
your car it's doing the work to keep your car running you know you've got to change the oil
check the tires and maintenance is important it's not always uh building shining uh new features
you need to invest time to maintain this whole thing uh yeah for each upgrade basically i would
So basically, I use Ansible to do the server provisioning.
I version control the Ansible configuration files.
For each upgrade, I bump the version number in Ansible configuration files,
and I would test on my local dev inside Vagrant and VirtualBox.
Yeah, yeah, exactly.
And then I test on staging.
And if things go well, okay, I launch new production instances,
change the load balancer setting, pointing to new servers,
and I will keep all the instances running for a couple of days
and then terminate them.
Pretty standard process.
Yeah, but done well and done professionally,
and that's exactly the way it is.
I like how you're building it in Vagrant first
and then putting it to staging and then into production.
That's just sweet.
I was going to ask, how do you handle when you need to do a database migration?
because it perhaps changes the structure of the data
and then you want to migrate it from staging to production.
Say you're going to add a new field,
how would you handle a more complicated migration?
You mean something like schema migration,
adding new code and adding index?
Yeah, where perhaps you need the old version to work back
and how do you handle, what if I need to roll back?
What's your strategy there?
Wow, it's a very broad topic
because I basically keep some norms about database operations.
What happens if I need to add a new column to a big table?
What happens if I need to add index to a big table?
Something like that.
So mostly Django migration is enough for migrating the schemas.
but sometimes I need to modify the migrate script to put in some raw SQL.
Yeah, run SQL operation.
Concurrent index, something like that.
Yeah.
Well, just in terms of forming a business, I think the fact that you've been around only two years,
I mean, looking at your list, I mean, you use Stripe Atlas to incorporate. I mean,
you must've been one of the very first users for that, right? I think that just launched.
I mean, so did you consider, you know, a C-Corp versus an LLC?
I mean, because if you're so, you know, obviously a C-Corp is easier to bring on new people, but a little...
We are C-Corp. We are C-Corp.
Yeah.
Because Stripe Atlas only supported C-Corp back then.
Yeah.
Maybe they support LLC right now, but back then it was only C-Corp.
Right.
Well, right, because there's some...
I mean, it depends on the business, but there can be some tax advantages to an LLC.
But if you want to have any employees or sell yourself, you have to be a C-corp.
At Quizlet, we were an LLC for a long time.
And then we were a top 100 website and still an LLC.
So that was interesting working with the CEO in that transition.
But it's easier to go from an LLC to a C-corp than back.
But and I see also, I mean, so Brex charge card, people outside of San Francisco may
I don't know what that is, but that sounds also like a smart hack for a small business.
Can you explain what that is?
Well, if you live in San Francisco, you see Brex, billable ads everywhere.
Yeah, so I have the Brex card because they also give me $5,000 AWS credit on top of whatever credit I get.
Right.
So it's very nice.
Because, I mean, you know, Stripe now is offering business loans.
And I assume, I don't think they have a credit card, but I'm sure that's coming.
It's interesting because it makes sense if you're Stripe that you have more financial data than you'd ever want.
Yep, true.
Yeah, and, you know, running these businesses, right?
I mean, it makes me think, I mean, I have my own book publishing business.
And, you know, I just have a simple Bank of America credit card.
And I have to spend thousands of dollars on stuff.
And, you know, I could use, maybe I should rethink this, but maybe I guess that's an advantage.
Being in San Francisco, you're surrounded by these best practices or, well, you're surrounded by these good offers, I should say, right?
For all the needs.
I don't know whether it's best practice, but it's what other people are doing, right?
here yeah interesting from from an ops point of view i always hear this uh sort of idea that your
credit card is the single point of failure yeah because you've got your load balancer you've got
your multiple servers but if your credit card two credit cards go down you're gonna have two
yeah i right i have multiple credit cards actually when i started uh this and those uh i posted a
question on hacker news asking uh what credit cards do people use something like that because
Because I found that on internet, you can find a lot of very high-level startup advice.
Oh, you need to go to product market fee, you need to do this, do that.
They are very high-level, very abstract.
In terms of concrete advices, okay, where do you get an office?
Where do you get a credit card?
So which bank is better for small business?
Something like that.
It's very hard to find answers.
Yeah.
You sort of have to ask someone you trust who's already done it.
Yeah.
Yeah. Well, I mean, that's something that, I mean, so you've been doing this over two years. I mean, for me last year, so I've been now doing books and teaching full time and I probably had to spend two or three months just on my business setup last fall, which was deeply frustrating. But, you know, many of these things you list here, you know, setting up my bank accounts, you know, credit cards, all this stuff is just, you know.
bookkeeping yeah bookkeeping i mean you know i i think like you using quickbooks but then
um yeah so it's a it's a it's a good problem to have but it it does often feel like you do
kind of everything but coding or everything but your business just to keep it going yeah though
i wonder you know for you now i was gonna ask you do you feel like you have things sufficiently
automated now that you've invested in all these tools or is it still no no no so actually actually
Especially running an internet business, coding, engineering is just a very small part of it.
Most of the things you do is not engineering, it's not coding.
So engineering is deterministic, right?
Nowadays it's 2019 now, if you want to build something, build a website, build an app,
you can build it.
You can build it yourself or you can outsource to hire contractors to build it.
But business is very non-deterministic.
There's no guarantee that you follow certain playbook,
you can make money.
And marketing is hard.
I'm still figuring out how to do marketing.
So I spend, and there are a lot of manual operational tasks
you need to do.
For example, every day I spend one third of my time
just replying to emails.
Well, you know, I was complaining to Carlton
about this earlier this morning.
I mean, it's like, how do you?
It's like you need to have the information and you want to engage with your users, but, you know, it's like, what did I do today?
I just looked at, I just responded to email.
To be frank, I quite enjoy the process of refining emails to users.
Yeah.
Well, good.
So what's the positive take on it?
Because you learned something from it or it's because it's personal?
Yeah, sure.
Yeah, well, I feel like I'm opening a small restaurant
and I know all my customers.
They can talk to me very easily.
So if you go to website, go to listen notes,
you can see my email address is on every page at a button.
So anyone can reach me, they get answer from me directly.
And typically they get reply in a few minutes.
I reply email very fast.
Yeah.
But that's the kind of thing that really builds a business, right?
Because they have a connection with you.
And you can offer a service which no way some giant competitor can offer.
Personally, I feel very frustrated to deal with faceless companies.
Yeah.
Because I use a lot of third-party services, as you can see.
If something goes wrong, I need to find the contact.
Yeah.
It's typically buried very deep.
And when you send email to them, you get a ticket.
Yeah.
Oh, they assign a ticket to you and you reference to this ticket number.
Then one week later, you get a response from them.
It's very frustrating.
Yeah.
No, I mean, that's right.
And then when something goes wrong or a competitor shows up, you don't feel any loyalty because
there's no person on the other end of the line.
And I guess, too, your service, once you have a customer, they're probably going to stay
or grow, which is nice.
mean uh i hope so yeah well i mean it's not it's not a purely transactional thing you know it's not
you're not selling you know a book where someone buys it and then they leave almost for forever
um so you yeah yeah no that's great i mean that's the kind of things that um it's hard to you know
as engineers it's hard to quantify the value of responding to emails and engaging with people but
it yeah it i think it has all these incredible benefits um i mean because i'm constantly being
advised by some of my business friends who I
say I spend a lot of time
on email. They're like, what are you doing?
Hire someone else to do it for you.
And maybe
there's some truth, but I think it keeps
you in touch with your users.
Exactly. I don't want to
outsource this customer
support too early to someone
else. I want to do it in person.
Yeah.
In terms of other operational tasks,
I built a bunch
of internal tools connecting to Slack.
So I'm using Slack.
I don't talk to human beings on Slack.
But on Slack, I get notifications
when some events happen.
Like some podcasters,
they want to delete their podcast
from our database.
Okay, I get an alert
and I can do everything on Slack.
I can run commands
and the podcast is deleted.
I can look up a particular podcast
and when new podcast is submitted to listen notes i get notification from slack i can see the basic
information for the podcast the podcast image the podcast title the sample audio so i can get a
sense whether this is a legal podcast uh and and i can approve right there so if i am on i'm on a
go i am on vacation or something like that i can do work on my phone because i i can use slack
I was just going to ask how you do boundaries because all three of us, to a degree, run single-person companies.
And that is always the problem is you never really turn off.
But it sounds like you've automated Slack so you can relax because you don't have to worry about it, I guess, as much.
But you're still getting notifications, right?
Yeah, I still need to use human judgment for certain things.
Someone wants to delete their podcast.
well, I need to make sure this is the legit person.
It's not a random person on the internet
who want to delete Joe Rogan's podcast.
Well, I cannot do that.
Yeah.
I like how you've used Slack for that.
It's kind of like a bash shell, but uses more memory.
Yes.
Well, I mean, because I sort of pride myself
on not using Slack for anything,
but I guess if you're used to it.
But this actually sounds like maybe a good use case
and you probably had used it at your startups before.
Well, the problem with Slack is that there's other people on it.
Well, exactly, right.
I'm the only human being on my Slack channel.
Right, right.
So I'm good.
That's kind of deep.
I like that.
Yeah.
Are there any last things you want to mention or talk about
before we wrap up?
I mean, I'm so impressed by what you've built single-handedly here.
Thank you.
Yeah.
If you haven't listened to PolarCast yet, listen to PolarCast.
Nowadays, I get more information from PolarCast than from other media format.
I put on my AirPods all day long.
I listen to PolarCast all day long.
So on listen notes, I have a playlist feature.
So you can curate episodes to playlist.
You don't need to subscribe to PolarCast.
You can just add individual episodes to playlists.
So I have a master playlist with 2,500 episodes over the past two years.
So I listen to a lot of podcasts.
You can subscribe to my playlist if you want.
Oh, fantastic.
Yeah.
Carlton, anything you want to add?
No, that's super.
I just, you know, what a super chat.
I mean, it's lovely to talk with you, to go through your stack,
how you're running it, and, you know, really nice and realistic and grounded,
and it's just you, and you're able to run such,
actually quite a big installation single-handedly.
Thank you, thank you.
Perfect.
It's just you, so you remember these steps,
because sometimes we interview people at bigger companies,
and they weren't around, or they didn't decide,
so they can't speak to that process of, you know, from prototype to scale.
I think that's an advantage of me doing custom support.
When people ask questions, I can explain why I built this,
what's the history of this particular feature,
why I made this decision,
what are some edge cases that we don't handle right now,
but they will be built in two months, something like that.
Right. Well, maybe as a last question,
so what should people look forward to?
What are some new products or features that are coming
on ListenNotes in the future?
uh that you want to talk about so most of time i don't build new new features like big new features
most of the time is just to iterate on existing features adding new stuff it's quite boring in
some people's eyes let me give you one example like a search engine must have some uh filters
search filters when you search when you search you may want to fine-tune the search results right
okay how many search filters does google have you go to google's advanced search page you can see
a lot let's say there there are 50 different filters right how many filters does this
have today, maybe seven, okay, 43 to go.
So basically, today I built a new search filter.
Two weeks later, I built another one.
Well, this kind of thing don't move the needle much, right?
It's not like I built a filter
and then the web traffic double.
It's not like this, but it's a process.
It's a long process.
You keep improving the service incrementally, yeah.
Making your user happy and making it useful.
Yeah.
Well, the key point is you want people to come back.
You want people to keep using it
and then tell their friends
and those incremental improvements
are what's going to make them stay and recommend you.
Right, right.
Yeah.
Yep.
Super.
Fantastic.
Thank you so much for taking the time today.
We're going to have show notes
for all the things we talked about,
especially the article you wrote,
which is really a fantastic run-through
of a one-person startup.
So thank you again.
thank you it's nice talking to you thanks for coming on the show thank you bye thank you bye