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

Hi, this is Will.

It's an interview with Wenbin Feng, the founder of Listen Notes, a search engine for podcasts powered by Django.

Enjoy.

I'm Will Vincent, joined as always by Carlton Gibson.

Hi, Carlton.

Hi, how are you?

How are you?

Thank you for joining us.

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 Listen Notes?

What's the quick pitch?

So Listen Notes is a search engine for podcasts.

It's like Google, but for podcasts.

So you type it 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 VLT services, just use our API to search podcasts, to fetch podcasts, metadata.

Right.

Yeah, probably the one and only.

Yeah.

Yep.

Super.

And how long have you been uh working on this?

So I started this EndNote as a side project in early 2017, January 2017.

I spent probably one week saw to get a quick prototype for this EndNote.

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, and I needed to find something to do.

So I picked up Listen Nose and worked on it a little bit, and work on it full-time, and I incorporated it as a company, a one-person company.

And then until now.

Actually, this bind uh would be the two-year anniversary for decent notes as a company.

Congratulations.

Yeah, it's really good.

Thank you.

But I but I hire some uh contractors, ONO for different things, like design, content, or some uh front-end development, something like that.

Yeah.

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 does a bare bones prototype look like before this?

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

Yeah.

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

Uh it has a search engine, it has a player, it has API, a lot of things.

But back to the beginning, uh 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.

That's it.

And uh I basically started uh with uh the Django template.

Uh I I believe the command line is Django start or something like that.

Yeah.

So start a simple start project.

So basically I started uh the Bellbone project, uh added one view uh for the for the search for the search page.

And I I spin up uh uh Elasticsearch instance and index data.

And uh so basically I have three digital ocean instances, one for web server running Django, one for uh Elasticsearch, and then one for um Postgres database.

Where did that come from?

Right to pop your

Also, podcasters can submit themselves.

So let's say today you start podcast today, uh you you need to submit your podcast to somewhere.

You submit to Spotify, to iTunes, and listen notes.

So every day we we are getting uh close to 100 podcast submissions from podcasters themselves.

So Elasticsearch, that's not a that's not a simple thing to spin up.

I mean clearly you've worked with Elasticsearch before, right?

So basically I I follow um some simple nodes I took um a few years ago setting it up.

Uh yeah, yeah, yeah, it was not too difficult.

Because I I I did it before.

Single node because you meant to have the duplication and the replicas, and that's when it starts to get a bit hairy because you're

Yeah.

Yeah, well, uh it's especially relevant to me because at DjangoCon this year I gave a talk on search, um talking about basic search and then uh with Postgres built-in search.

Um I'm curious, did you ever consider using built-in um you know the full text search in Postgres?

Or did you already know Elasticsearch?

So did you was that a case?

So I actually use uh Postgres full text search for my other small side projects with a small amount of data.

Uh at the beginning of this uh this SendNouse project, I did some testing with uh Postgres uh full text search.

Uh it was very slow, if I do not correct it, it was very slow, so I gave up quickly.

Uh maybe because of the amount of data that we need to index.

It changes a lot.

Oh, it changed a lot.

Well, what

particular, right?

Oh, okay.

Probably you guys don't update your podcast much, but you know, if you have the whole internet podcast data at any given time, there are some podcasts changing their description, title, ISS feed, audio URL, all kinds of things.

Could you describe the setup of workers you're using to you know pull in this information?

So for workers, basically they are asynchronous processing uh touch workers.

I use salary, C E R Y.

If your audience are familiar with salary.

Um yeah, so yeah, we still some uh so basically salary is uh uh is a hookup with uh uh salary beat, which is a scheduler like Chrome.

Yeah.

So we have some scheduled tasks like for for cloning data, uh pulling data from ISS feed to add new episodes, and salary also handles other async tasks, um uh mostly compute-intensive tasks, like uh sending emails, uh uh resizing images, uh 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 uh you know it's not tons and tons of workers, it's you know emails and checking for changes to the podcast directories.

Um so it makes a lot of sense.

So I um so how much may and I know you have all sorts of actually could you talk about so you have monitoring involved, and I you've listed a whole bunch of tools, right?

So because other so that otherwise you couldn't sleep at night.

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

You know, if someone's saying, okay, which what do I start with, right?

Because there's so many you can add.

So high level, you need to know the website is up, the API is up, right?

Yeah, so uh for monitoring, I use Datadog.

And Datadog uh is connecting to PageOD for alerting.

And for Better Dog, uh we uh continuously uh pin the uh website and the API endpoint and check the response to see if it's uh 200 is no 500.

Right.

And if it's no 200, then probably something broken and uh I will get alert.

So high level you need to have this kind of stuff, but for individual components, uh you also need to monitor some matrix.

Like for Postgres, you need to monitor a few things for Redis and a few things, Libya NQ, uh Elasticsearch, yeah.

Each of them I all have one or two alerts associated with this.

Yeah.

And I think you mentioned for Django itself, you use rollbar.

Is that still the tool that you like to use?

Yes, yes.

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

I'm not putting words in your mouth.

Docker repository is down or relevant, like right.

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 Wembin's doing single-handedly.

Right?

So that that would be the way I'd phrase it.

So what's your experience?

I was gonna ask if it if it would be different if you had a team of developers, because to me, that's in some ways the biggest advantage is on a team having the same local setup um separate from Yeah.

Yeah.

What are your thoughts?

Yeah.

For the workload I'm running for the team, I have basically it's just me as a backend engineer.

So Docker is good to provide a standardized container.

It is about it is very portable.

So you can run Docker container on your local dev, you can run the same container in stages, 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, uh, so it's just me.

Uh I basically set up everything.

I don't need standardization for other people.

You you might have, say, you want you you mentioned RabbitMQ.

Well, maybe you don't want to install the whole Erling 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 you know you don't need to go the whole hog with Docker.

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

Yeah, and um in 2014, uh I believe it was me who introduced Docker to the company.

And uh so when did Docker come out?

Maybe 2013.

Right, okay.

So basically we standardize the uh the dev environment for all the engineers with Docker containers, and so it's easy to set up.

Onboarding is easy, yeah.

Right.

Yeah.

So because you you get that you get the development VM and you just be able to vagrant up and it would run, and but it's slow and heavy, and it's much nicer.

Okay, for these and nose.

And but Docker is quicker and lighter, and you know.

Yep.

I can see why people like it for the development environment.

Uh for deployment.

Speaking of deployment, so you're on AWS, is that right?

Mm-hmm.

I'm curious if you talk about your experience maybe with AWS versus other ones you've used professionally.

So I uh earlier on I mentioned that I spin up three digital ocean.

Oh, yeah, you said

I don't know, because because it's very lightweight or cheap.

Uh yeah, or whatever.

I had three instances for listeners as a side project.

I used the same setup for many banks.

Uh maybe one year after I started this side project, I migrated to ARS.

Uh the reason was very very simple because I started to work in WeWork, and we work gave you um $5,000 ARS credit.

And then I migrated to ARS.

Uh I mostly just use uh EC2 instance.

Okay.

I I don't want to uh have uh vendor login uh with uh adres.

Uh yeah.

Uh anything else?

Oh, I I also use S3.

Yeah, I think you in S3 and Cloud Pro your for your front end.

Um I guess that's an

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 you know, like two or three of the core services and get to know those, yeah, it's not any more complex than any other provider.

It's just that they've also got quick site and you know all these million AI offerings.

And do you need all of them?

Can you talk about that transition and at what point you switched over to the to using a dedicated front end?

Good for you.

Uh so basically Django uh ran the renders uh uh the the boilerplate for HTML and then React uh render uh components inside uh HTML page.

But so that first weak prototype you also uh hooked it up with React and Django Rest framework?

Yeah.

Yeah.

That's awesome.

You can you can whip these things up, but I know that all those things sound like uh just because I get so many questions about all of that, it's um it it takes some practice.

But once you get to know other steps, right, you're sort of duplicating your own steps, right?

For I'll just do my this is how I hook in React.

Um yeah.

For for React, you're saying

But uh I said that now nowadays you can find a lot of such tools if you want to get started uh quickly.

Well I always wonder how 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.

But again, it's that it's that first prototype versus you know what you end up with eight two years later.

Right, yeah, yeah, yeah.

I mean, I have my own one, Django X, that's simpler by design.

Um, but I'm always curious if there's others out there I'm not aware of because it's there's and actually a Django X, uh 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 maybe 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, because cookie cutter is fantastic, but it's it's um you need to know what you're doing to use it.

Yep.

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.

So okay so as I said I started uh listen notes uh as a side project and then I worked on it full time starting uh in September 2017 and then after I ran this website for a couple of months or so I got some requests from developers asking if I provide APIs and so that was the end of 2017.

I was not sure whether API can be a viable business or whether it deserves my time.

Right.

So I tried to build a quick prototype quick and dirty prototype but I also want to be able to charge people for using API.

So uh I did some Googling I found an API marketplace called uh MarchApe M-A-S-H-A-P-P-E.

It doesn't exist anymore.

It was acquired by a startup by rape uh called rapid API so they rebranded this thing as rapid API right now.

It still exists by with a different name.

Okay.

So I found this API marketplace MarshApe uh it basically it handles the payment it handles API analytics it measures how many API requests uh user uh API users use during the the building cycle so they can do the do the building calculation and handle some education or if a developer subscribed to your API plan and unsubscribe and then subscribe again yeah

no that's fantastic cred

ching podcast metadata by ID one for fetching episode metadata by ID so I think these are the minimum requirements 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 uh for about one year you know API business has a long cycle today someone discovered this A

PI good they sign up they spend six months building their app they spend another six months marketing maybe another six months to gain some traction and then uh two uh two years later I start to collect money so yeah so API reason is slow and I so yeah I didn't I didn't put some any effort on API for about one year.

be API v2 so I built this whole thing uh in the beginning of this year when it's running now how long

well I like

to use an off-the-shelf tool um confirm that there's market validation before you spend the time because um you know 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.

Um wow man I'm so impressed by that.

So so the business itself now so how does um in broad strokes so you have the API that you charge for you have ads on the site itself uh how do you think about the business kind of where now and where you want it to be long term.

Uh I'm doing fine uh it's not going out of business any sooner so uh but uh yeah I I'm I start to see in uh big picture uh what's the long term so basically I uh so this I I want to listen not to make podcasts uh accessible in general so long so then let me explain a bit so uh how many people in the world right now probably 8 billion close to 8

billion how many people listen to podcasts today uh less than 100 million maybe less than 50 million so there's still a lot of room to grow for podcasts or spoken audio in general so with human beings uh get information through eyes and through ears yeah most big companies nowadays are basically focused on screen time yeah getting information through eyes but

uh I think audio has uh huge potential uh in uh in in in in the in the future you know some uh some companies like Apple they're making AirPods uh uh Amazon they're making uh echo these are all uh voice first products and yeah my instinct talking is uh audio could be something yeah so if you can you can help people find audio content maybe you will be a

good business yeah and that let's let's come back to listen notes how can listen notes help podcasts become accessible so we don't we also at this point we don't build apps we don't we don't build our our own contents it's a it's a website website is easy for people to discover to share right and especially for international users and also we provide APIs so developers can quickly build podcast related service us

ing the API they don't need to worry about the backend and this can somehow help the innovation uh in the application space for podcasts making podcasts more accessible yeah this is why I think

es if you go to website you scroll down to a button you see that you can switch to different languages.

Yep very easy and is uh

partnership with some translation agencies so you can directly pay those agencies on the service but for certain languages that's uh I cannot find translators layer so I need to uh post on upwork to find individual translators yeah yeah.

I mean, I was when I was in San Francisco, I worked at a company called Quizlet and I worked a lot on the uh translation, which was um literally we would get, you know, a a Chinese teacher in San Francisco to translate the site.

It you know, it was very we found a couple users and then we scaled up from there and um it's it's no easy thing.

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

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

Yeah.

Yeah.

So but still it's nice.

I mean, yeah, I'm certainly guilty of assuming everything's in English.

So um Wow.

And yeah.

Are you up to date?

Are you on Python 3.7, 3.8 this week?

Are you are you on Django uh 2.2?

I started this announce 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.

Did you was it easy?

Did you hit the relative?

So uh primarily uh Ubuntu, Django, Postgres, Elasticsearch.

I like to keep the uh keep using almost the latest version, not the latest one, maybe second to the latest one.

Yeah, yeah.

And um uh it's uh I always say it's a bit like make um, you know, you 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,

It's not always uh build building, shining uh new features.

You need to invest time to maintain this whole thing.

Uh yeah.

For each upgrade, basically I would uh change so basically I use Ensible 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 will test on my local dev inside uh Vagor and the VirtualBox.

Yeah, yeah.

And then I test on staging.

And if things go well, okay, I launch new production instances, change the load balancer uh setting, pointing to new servers, and I will keep the old instance running for a couple of days and then terminating.

Yeah.

Pretty standard process.

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 gonna ask, how do you handle um like when you need to do a database migration?

So it perhaps changes the structure of the data, and then you want to migrate it from staging to production.

So you're gonna add a new field, or how how would you how would you handle a more complicated migration?

How do you uh how do you how what's your strategy then?

Uh, what happened if I I need to add a new column to a big table?

What happened if I need to add uh index to a big table, something like that.

Uh so most of the Django uh my migration uh is enough for migrating the schemas.

Uh but sometimes I need to modify the migrant script to put in some raw SQL.

Yeah.

I mean, you must have been one of the very first users for that, right?

I think that's 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 C Corp is easier to bring on new people, but a little history.

We are C Corp.

Yeah, maybe they are supported, maybe they support LLC right now, but back then it's only C Corp.

Well, right, because there's some I mean it it depends on the business, but there's 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.

Uh and then we were a top 100 website and still an LLC.

Um, so that was interesting working with the CEO on that transition.

But it's easier to go from an LLC to a C Corp than back.

Um but and and I see also, I mean, so BRECS charge card.

Um, 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 what that is?

Yeah.

Well because I mean uh you know Stripe now is offering business loans and I assume I don't think they have a credit card, but I'm sure they'll that's coming.

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

I mean, I mean makes me think.

I mean, I I have my own book publishing business.

Um and I, you know, I just have a simple Bank of America credit card and I have to spend thousands of dollars on stuff and um you know, I could use maybe I should rethink this.

Um but maybe I guess that's an advantage.

Being in San Francisco, you're uh surrounded by these best practices, or well, you're surrounded by these good offers, I should say, right?

For all the needs.

Interesting.

Yeah.

Because you've got your load balance, so you've got your multiple servers, but if your credit card gets down,

you're gonna have two.

Actually, when I started uh listening notes, uh I posted a question on uh Hacker News asking uh what credit cards do people use, something like that.

Because I I found that on the internet you can find a lot of very high-level uh 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?

Where so which bank is is is better for small business, something like that.

It's very hard to find answers.

Yeah.

Well, I mean, I uh that's something that um 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 uh just you know

Yeah, bookkeeping.

So I wonder, you know, for you now I I was gonna ask it, do you feel like you have things sufficiently automated now that you've invested in all these tools, or is it still

Most of the things you do uh is uh it's 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 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 playbooks, you can make money.

Uh and marketing is hard.

I'm still figuring how to do marketing.

Yeah.

So I spend and 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.

I mean,

I just looked at, I just responded to email.

It's it's it's uh

Uh yeah.

That's good.

So what's what's the positive take on it?

Because you learned something from it or it's because it's personalized, like,

yeah, sure.

Well, uh, I I feel like I'm opening a small restaurant and I know all my customers.

Well, they 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 answered from me directly.

And typically they get they get a reply in a few minutes.

I reply email very fast.

Uh yeah.

That really because they they have a connection with you.

And that you can offer a service which no way some giant competitor can be.

Yeah.

Uh if uh something, something, something goes wrong, I need to find a context.

Yeah.

It's typically buried very deep.

And you when you send email to them, you get a ticket.

Yeah.

Oh, the the they assign a ticket to you and you reference to this ticket number.

Then one week later you get a response from them.

Uh it's very frustrating.

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, um, it's it, you know, once you have a customer, they're probably gonna stay or grow, which is nice.

I mean uh

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 lots it's hard to quantify the value of responding to emails and engaging with people, but it 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, you know, say I spend a lot of time on email, they're like, what are you doing?

You know, hire someone else to do it for you.

Um and maybe there's some truth, but I think it's it keeps you in touch with your your your users.

Exactly.

I want to do it in person.

Yeah.

And so in terms of other operational tasks, um, I built a bunch of internal tools connecting to Slack.

So I'm using Slack.

Uh I don't talk to human beings on Slack.

But uh on Slack, I get notifications when some events happen.

Like some podcasters that want to delete their podcast from our database.

Okay, I get 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 notifications from Slack.

I can see the basic information for the podcast, the podcast images, the podcast title, uh 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 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 a Slack.

But it sounds like you've automated Slack so you you can relax because you don't have to worry about it, I guess, as much.

But you're still getting notifications, right?

Someone wants to delete their polar cost.

Uh well, I need to make sure this is the legit uh uh person.

It's not it's not a random person on the on the internet who wants to delete Joe Logan's polar cast.

Well, I cannot do that.

So yeah, yeah.

I like how you've used Slack for that.

It's it's kind of like a bash shell but uses more memory.

Yes.

I like that.

Yeah.

Um are there any any last things you want to um mention or talk about um before we before we wrap up?

I mean I'm so impressed by what you've built single-handedly here.

Yeah.

Uh if you haven't listened to podcasts yet, listen to Polarcast.

Uh I nowadays I get more information from Podercast than from other uh media format.

I I put on my ALPs all day long.

I listen to Polarcast all day long.

Uh so on listen notes, uh I uh I have the playlist feature.

So you can curate episodes to playlist.

You don't need to subscribe to podcasts, you can just add individual episodes to playlists.

So I have a master playlist with 2500 episodes in the over the past two years.

So uh I listened to a lot of podcasts.

You can subscribe to my to my playlist if you want.

Yeah.

I just uh you know what a super chat.

I mean, it's lovely to go talk with you, to go through your stack, how you're running it, and you know, really nice and realistic and ground, and it's just you and you've got you're able to run such actually quite a big installation single-handedly.

Thank you.

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 uh to scale.

When people ask a question, I can explain why I build this, what's the history of this particular feature, why I made this decision, what are some educations that we don't handle right now, but they will be built in two months, something like that.

Well, maybe as a last question, so what what what should uh people look forward to?

What are some new products or features that are coming on listen notes in the future?

Uh that you want to talk about.

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

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

Uh 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, 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 not have today?

Maybe seven.

Okay, 43 to go.

So basically, I so that today I build a new search filter.

Two weeks later I build another one.

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

It's not it's not like I build a filter and then the web chair feet double.

It's not like this.

But uh it's it's a it's a process, it's a long process.

You keep improving the service incrementally.

Um yeah, making your user happy and making it useful.

Yeah.

Yeah.

They want you, you want people to keep using it and then tell their friends, and those incremental improvements are what's gonna make them stay and recommend you.

Right, right.

Yeah, yep.

Fantastic.

Thank you so much for taking the time today.

Um, we're gonna have show notes for all the things we talked about, especially the article you wrote, um, which is really a fantastic run through of a one person startup.

So thank you again.

It's nice talking to you guys.

Okay, all right, have

Bye.

Thank you.

Bye bye.