Transcript: Listen Notes - Wenbin Fang (Ep 41 Replay)

Hi, this is Will. Today's episode was originally released in 2019. It's an interview with Wenbin

Feng, the founder of ListenNotes, a search engine for podcasts powered by Django. Enjoy.

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 with me.

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 podcast.

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 podcasts, 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,

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 left 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, 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 this and those.

Oh, wow.

It's a company.

Congratulations.

It was really good.

Thank you.

And you're still one man?

Still one person?

Full-time employee, yes.

One full-time employee, me.

But I hire some contractors on and off for different things,

like design, content, or some front-end development, something like that.

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 wonder if you can recall, so what did that actually involve?

I mean, start project, like what does a bare bones prototype look like for this?

Because that's something that newcomers don't understand how that can be done.

Yeah.

So if you look at ListenNotes.com today, it's quite complex.

It has search engine, it has a playlist, it 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, added one view for a search page, and I spin

up an Elasticsearch instance, index data.

So basically, I have three digital ocean instances, one for web server running Django, one for

Elasticsearch, and then one for PostgreSQL database.

So how did you...

Where did you get the initial data? Where did that come from? Right to populate?

So there are only a few well-known podcast directories on the internet.

Okay. So did you scrape them or something?

Scrape 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. You submit to Spotify, to iTunes, and listen notes. So every day

we are getting close to 100 podcast submissions from podcasters themselves.

All right. So you started, so it's 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 the same 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, yeah.

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 simple node, yeah.

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, 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 ZenNose 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 uh what there's so there's new

shows and then there's new episodes right is it more episodes what else and episodes data

podcast data change it all the time oh okay probably you guys don't don't update your

podcast much but you know if you have the whole internet's podcast data at any given time there

There are some podcasts changing their description, title, RSS 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.

use Celery. C-E-L-E-R-Y. Your audience are familiar with Celery. Yeah. So yeah, with those

some, so basically Celery is a hookup with Celery Beat, which is a scheduler like Chrome.

So we have some scheduled tasks like for crawling data, pooling data from RSS feed to add new

episodes, and Celeri 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

It's also simple and that you can understand that it's, you know, it's not tons and tons of workers.

It's, you know, emails and checking for changes to the podcast directories.

So it makes a lot of sense.

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.

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, if someone's saying, 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 PedroDuty 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, however, 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

well so Carlton and I

spoke and we wanted to ask you about so you

sort of proudly don't use docker at

all and Carlton is

big on this wagon and

no okay make the case

Carlton

my case is simply

this docker pod story is down right now

which is relevant like

right but for 95%

of Django applications out there.

You don't need all this

highfalutin 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.

You'll never have port issues.

You'll never have network issues.

You don't need

all this massive containerization stuff

until you're scaling up

to something much, much, much bigger.

And look at what Wembin'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 it's just me as a backend engineer.

So Docker is good.

And to provide a standardized container, 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.

And I don't have a 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 mentioned RabbitMQ.

Well, maybe you don't want to install the whole Erlang VM and all the rest of it

to use a container there to locally use RabbitMQ while you're developing or testing.

That's one useful case where you don't need to go the whole hog with Docker.

You don't have to jump into Kubernetes or whatever to use it a bit.

Yeah, so for my previous job, I worked in Nextdoor, a local social network website.

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.

yeah yeah no that's it right yeah i mean this is where a few years ago people were using vagrant

and vms right so because you you get that you get the development vm you just be able to vagrant up

and it would run and but it's slow and heavy i'm using as much nicer sorry i'm using vagrant right

okay for this and those no but i i still use vagrant loads because i'm a big advocate of vms

and but docker is quicker and lighter and you know yep i can see why people like it for the

development involved. Yeah. Speaking of deployment, so you're on AWS, is that right?

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 they they call the instance drop this because i don't know because

because it's very lightweight or cheap yeah five dollars uh yeah or whatever five dollars provides

i had three instances for listeners as a side project i used the same setup for many months

uh maybe one year after i started this side project i migrated to adrs 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. I don't want to have a vendor

log in with adrs uh yeah i i i just use ec2 instance uh anything else oh i i also use s3

right yeah i think in s3 and cloud for your for your front end yeah yeah well i guess that's an

but again that's very that's very sensible right because amazon i mean like each of the big

services they've got you know 50 60 different things that you can use if you want to but like

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, I mean, you have for a single person startup, I mean, 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 RESTJS.

Oh, okay. Oh, wow. 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 render components inside the HTML page.

Right.

But so that first week prototype, you also hooked it up with React and Jenga REST framework?

Yeah.

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.

practice. But once you get to know

all the steps, you're sort of duplicating your own

steps, right? For, 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 CookieCutter, or

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.

One downside using such tools is you don't go very deep into the mechanism.

all these things yeah but again it's that it's that first prototype versus you know what you

end up with two years later right yeah yeah well and just in terms of django frameworks um 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. But I could make it how I start my projects

now, which would be a lot more complex. It would 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 between, yeah, simple and then what you would actually use. Because cookie cutter is

It's fantastic, but you need to know what you're doing to use it.

Mm-hmm.

Yep.

Okay.

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 going back to the memory of how I started API.

So as I said, I started Listen Notes as a side project, and then I worked 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 requests 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.

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 with a different name. So I found this API marketplace

match app. 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 then

handle some edge cases. Or if a developer subscribe to your API plan and unsubscribe,

and then subscribe again. Yeah, no, that's fantastic.

Create a 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. Sounds easy.

So I spent about two hours using Django REST framework, building three API endpoints.

One for search, one for fetching podcast metadata by ID, one 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 this 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 and those api good they sign up they spend six months

building their app.

They spent another six months marketing their app.

Maybe another six months to gain some traction.

And then two years later, I start to collect money from them.

So API business is slow.

So yeah, 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 replace

rapid API for the API gateway stuff. So I wanted to build my own pavement,

my own API analytics stuff. So there will be API v2. So I built this whole thing in the beginning

of this year.

And it's running now.

Wow.

How long did...

I mean, that sounds like a lot of work.

Was that...

Three months.

Three months.

Three months.

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.

So it's unusual, but I had to get it done.

I mean, I think that's a brilliant philosophy, 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.

Right.

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.

So, but yeah, I start to see big picture, what's the long-term.

So basically, I want to send notes to make podcast 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 podcast today?

Less than 100 million, maybe less than 50 million.

So there's still a lot of room to grow for podcast

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.

My instinct told me that audio could be something.

So if you can help people find audio contents,

maybe it will be a good business.

And let's come back to ListenNotes.

How can ListenNotes help podcasts 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

podcast 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 podcast,

making podcast 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 a 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 do 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

the find your translators

or do you have to have a relationship

with individual translators?

I use a service, I forgot the 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.

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.

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, you know, a Chinese

teacher in San Francisco to translate the site.

You know, it was very, we found a couple of users and then we scaled up from there.

And it's no easy thing.

So it's impressive that you have all these languages.

And it takes, yeah, 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.

Yeah, certainly, certainly, yeah.

It's far from perfect.

Yeah, so.

But still, it's nice.

Still a lot of.

It's still nice to see a site in your own language,

obviously, I mean, I'm certainly guilty

of assuming everything's in English, so, wow.

Yeah, I'm very happy to see international users

using this and those, and yeah.

One thing I did want to ask is,

you know, what versions are you using?

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 Django 2.1 and Python 3.6, 3.6.8.

Okay, so half strings.

Yeah, I started this and those 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?

Did you hit back with compatibility problems?

So I basically allocate a couple of days every few months

to upgrade major software components in the whole test deck.

So primarily Ubuntu, Django, PostgreSQL, Elasticsearch.

I like to keep using almost the latest version.

Not the latest one, maybe second to the latest one.

Yeah, okay.

And I always say it's a bit like 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.

Maintenance is important.

It's not always building, signing new features.

You need to invest time to maintain this whole thing.

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 those instances running for a couple of days

and then terminate them.

Yeah.

Pretty standard process.

Yeah, yeah, no, but like done well and done professionally,

and that's 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 well i was going to ask how

do you handle um like when you need to do a database migration oh perhaps changes the structure

of the data and then you want to migrate it from staging to production say that say you're going

to add a new field or how would you how would you handle a more complicated migration you mean the

something like schema migration adding new code and adding index well yeah where you need where

perhaps you need the old version to work back and how do you handle the oh what if whatever if i

need to roll back how do you how do you how what's your strategy there uh well it's a very broad

topic because there i i basically keep keep some norms about about database operations uh what

if i need to add a new colon to a big table what happened 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.

Like concurrent index, something like that.

Yeah.

Well, I also, I want to, 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 have 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 and Atlas only supported C-Corp back then.

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 I see also, I mean, so Brex charge card.

People outside of San Francisco may not 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'll 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, 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.

Yeah, it's interesting because it makes sense if you're Stripe that you you have more financial debt data than you'd ever want.

Yep. And yeah. And, you know, running these businesses. Right.

I mean, I mean, it makes me think I mean, I 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 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.

than what other people are doing right here.

Yeah, interesting.

From an ops point of view,

I always hear this sort of idea

that your credit card is the single point of failure.

Yeah.

Because you've got your load balance,

so you've got your multiple servers,

but if your credit card gets canceled,

that's how your servers go down.

You've got to have two.

Yeah, I have multiple credit cards.

Actually, when I started ListenNotes,

I posted a question on Hacker News

asking what credit cards do people use,

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. 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

Actually, 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.

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 spent, and a lot of,

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.

It's, it's, it's a.

To be frank, I quite enjoy the process of refining emails to users.

Yeah.

Well, good.

So what's, 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 am opening a small restaurant and I know all my.

customers well 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 they get reply in a few minutes i reply email very fast

uh yeah but that that's the kind of thing that really builds a business right because they

have a connection with you and yeah you can offer a service which no way some giant competitor

personally i i feel very frustrated to deal with face these companies yeah

because i use a lot of um third-party services as you can see uh if something something something

go wrong i need to find the contact yeah it's typically buried very deep and you when you send

email to them you get a ticket yeah oh they they assign a ticket to you and you reference to this

ticket number then one week later you get 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 to your service um it's you know

once you have a customer they're probably going to stay or grow which is nice i 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, 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, I think it has all these incredible benefits. Um, I mean, cause I'm constantly being advised by some of my business friends who I, you know, say I spend a lot of time on email.

They're like, what are you doing?

Hire someone else to do it for you, da-da-da-da.

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.

So in terms of other operational tasks, I build 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 alerts

and I can do everything

on Slack I can run commands

and the podcast is deleted

I can look up a particular podcast

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 and I can approve right there.

So if I am on a go, I am on vacation or something like that, I can do work on my phone because I can use Slack.

I was just going to ask how you do boundaries because, you know, I mean, 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 just don't 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 it 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 know, you probably had used it

at your startups before, so.

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 uh if you haven't listened to podcast yet listen to podcast uh i nowadays i

get more information from podcast than from other media format i put on my airpods all day long i

listen to podcast all day long uh so on listen notes i i have the playlist feature so you can

curate episodes to playlist you don't need to subscribe to podcast you can just add individual

episodes to playlist so i have a master playlist with 2500 episodes in the over the past two years

so i listen to a lot of podcasts you can subscribe to my to my playlist if you want

oh fantastic yeah uh 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 grounding it's just you and you've got you're

able to run such actually quite a big installation single-handedly that's 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

from prototype to scale.

I think that's the 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 that you want to talk about?

So most of the time, I don't build new features, like big new features.

Most of the time, it's just to iterate on existing features, adding new stuff.

It's quite boring in some people's eyes.

Let me give you one example.

Now, a search engine must have some filters, search filters.

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 are 50 different filters, right?

How many filters does this node have today?

Maybe seven, okay?

43 to go.

So basically, today I build a new search filter.

Two weeks later, I build another one.

Well, this kind of thing don't move the needle much, right?

It's not like I build 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.

And yeah, making your user happy

And making it useful.

Yeah.

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 guys.

thanks for coming on the show thank you all right have a good bye thank you bye