Transcript: Buttondown - Justin Duke

This episode is sponsored by MailTrap, an email delivery platform that developers love.

Try for free at mailtrap.io.

Hi, welcome to another episode of Django Chat, a podcast on the Django Web Framework.

I'm Will Vincent, joined by Carlton Gibson. Hi, Carlton.

Hello, Will.

And we're very pleased to welcome Justin Duke from Button Down. Welcome, Justin.

Thank you both for having me. I'm excited to be here.

thank you for coming on so tell us for the you listeners who perhaps don't know tell us

what button down is and how you that's on a django show for sure so button down is a email tool

similar to say mailchimp or tiny letter sub stack uh that the rich ecosystem of ways you can just

blast out emails to thousands of subscribers um all built on top of python and django over the

past couple of years have been experimenting with some of the more modern web stuff for the front

end, but the core backend, how we send our emails, how people view those emails, all that is running

through Django and running through Python. There you are. So I just have to jump into it. A

recurring theme on this show is people always say, but maybe Go is better. What are your current

thoughts on when you see something slow in your application and maybe the grass is greener over

there? You know, button downs at the phase of a product where it, I start to have to think about

scaling concerns and performance way more than say like three or four years ago, where it was

mostly around like, how do I hit product market fit? How do I iterate quickly? All the things

that I think Python is particularly good at. And even now that like, I am really, really

performance sensitive i still feel like there's upper echelons of software uh and just in terms

of raw volume where i think you hit the nuclear button of like we have to migrate off of the

language that we're using because this just like cannot scale but i think that is generally a

couple orders of magnitude larger than where most people abstractly think about it like 95 99 percent

of the time when i'm dealing with some sort of perf issue it's like the boring stuff right it's

like an n plus one query or something that can be solved at the database or caching layer i think

even even now even as we're handling so much traffic there are so many python level tools

that help you address kind of those those perf implications that uh i haven't really fantasized

about like oh let's just take this little subsystem and rewrite it in in go or rust like

that would have to be motivated by something other than pure performance seems a very mature outlook

well can i ask how many how many people are working on button down now because i know you

have some support staff is is it just you and engineering or what's the team size right now

we're around uh five to six folks who are working roughly full-time hours and then a uh a legion of

very lovely contractors doing stuff like support uh documentation and writing that sort of thing

The goal has always been keep it really tight knit and keep it really, I guess, small in terms of headcount.

I've worked at really large companies and I've learned a lot from that.

But one of the things that at least right now in my career I'm not super interested in doing is the startup hedonic treadmill of hire as many people as possible, spin them all up, spend all your time scaling and scaling and scaling.

I think this is my first time working this long on a product project or product that

has just a handful of folks and I think the the level of velocity and focus that you get out of

that is really really rewarding okay I want to jump in there because I'm um I I'm about 12 months

into bootstrapping a project just single-handedly and it's and it's part of the story there is that

we've gone back to htmx and template rendering and all the rest so I wasn't I didn't have to

take on a whole front end team to get as far as i've got um but one of the sort of take-homes i

think from my last year of experience of getting back to building with django rather than just

working on it is that really it's a force multiplier like there's no way i could have done

this what you know in another project and another with another thing i think and what's your

experience there i mean do you feel you know django helps you out in that in that keeping it tight

keeping it small absolutely i think the when i look back to the first say year or two years

building out button down i think something that i only really recognized in hindsight was how much

of this stuff just wasn't even a problem for me because it's something that the framework brought

for you like the classic example that i think is becoming more and more um relevant as like a lot

of full stack folks are opting towards like JS and using a purely JavaScript based framework is

like off which is like a really boring thing to talk about but when I first spun up button down

it's like all right well I have this built-in user model like I get some admin stuff for free like I

can plug in all off down the line to get in social login and all that stuff and like that was not like

a major consideration where I had to evaluate vendors and think about all these various things

it's just like well Django brings this in for me like even now as like I start to look at okay

parts of Django maybe we have to replace them with something that's like a little bit more

bespoke and home-baked the amount of early decision making and early build-out that you

don't have to do because Django has like really smart sensible defaults that will do like 95%

of what you need for you is really hard to beat yeah brilliant brilliant and then that begs the

of the question which bits are you starting to think oh yeah we might need to replace that bit

we might need to roll around our own there for sure so i think some of this varies like to talk

about some stuff that has fall under that umbrella in say the past year or two years um and none of

this i think is particularly surprising but like the api url patterning for for django and like

the request lifecycle, I think third-party packages like DRF and now more recently stuff

like Django Ninja or FastAPI, like that is just handled a little bit more better or more

ergonomically for a use case like mine, which is, you know, button down really has two front

ends to a certain extent.

It's got the subscriber facing front end that's like going to subscribe to someone's newsletter

or viewing their archives.

And all of that is kind of classic Django.

Like that is Django templating being served by CBVs, like very, very happy path.

And then the author facing application, which is you're an author, you want to log in, write

some emails, manage your subscribers.

All of that is a custom front end that's more like a conventional SPA and all of that's

powered by API views that we then serve as an external facing API.

So people can like, you know, call button down to like programmatically send newsletters

or chain subscribers and things like that.

And a lot of this stuff that you get out of the box

from whether it's DRF or Django Ninja

in terms of API generation and things like that,

that is where I've started to like pull really far

outside of what Django offers.

Because again, I think Django's charm and value

in many ways is they give you the 80%

or the 95% that you need for free.

And then it's really easy to opt out of the stuff

that you outgrow of like,

You don't have to go through a lot of hoops to be like, well, I'm not going to use Django CBVs.

I'm going to do my own thing.

Like you can always drop down to the primitives and skip what's out of the box without having to like really, really pay for it, if that makes sense.

That does make perfect sense.

And now I'm massively curious about what dirty API stuff you're rolling for yourself in there.

But I don't know if we'll go all the way there.

Yeah, no.

Well, Carlton and I want to just like tech talk the whole time, but I think it is also helpful to talk about the person behind it.

So I'm just curious for you, like I know you studied at William & Mary Computer Science.

I was in Yates too, by the way, back in 10 years before you, I think.

I had no idea you were also a William & Mary grad.

That is a small world indeed.

Yeah, they just took down the building, I think, right?

They just destroyed it.

They're redoing.

It was pretty grungy when I was there.

Like we had dehumidifiers going the whole time because I was in the basement and it

was, yeah, it needed a refresh.

But I, you know, so I'm probably, I think, 10 years older than you.

Like back then, nobody was doing really computer stuff.

I remember there was one guy who built his own email client and Microsoft was interested

and it was like this crazy, oh my God, like the West Coast.

Whereas fast forward and I guess the growth of tech in DC and just in general, it was

less crazy that someone would go work at a web company, right?

As opposed to a contractor in Northern Virginia or something.

So that, anyways, side note.

So I'm babbling, but I'm curious, when did you start getting into computers?

Was it in college or did you have a taste for it before?

Of course.

And so as context, like William & Mary, pretty small liberal arts college.

You know, even in the 10 years since you graduated, when I graduated from CS, I think there was

maybe 20 folks in the department who graduated with me.

So still a very small department.

I came into undergrad not thinking I was going to go into programming.

I wanted to be an English major and then like I had heard enough stereotypes about graduating with just an English major that I was like, all right, I'll supplement it with a marketing degree.

Maybe I can do copywriting or something along those lines.

You know, sophomore year after college, I interned at an ad firm in Richmond and I quickly discovered that the ad industry was not for me.

And in fact, my favorite part of the entire gig was like managing a couple of our clients like WordPress installation.

because i had to do like some basic html and css stuff and i was like this is actually like pretty

fun maybe i should think about this a little bit more seriously and so junior year onwards i kind

of took a couple of the basic 101 and 201 cs classes realized i loved it and then kind of did

a hard pivot into into cs um and so i had to make up a lot of ground in my final two years but

even even in 2013 the the scene as it was for cs at william and mary was pretty similar to what

you're describing will of like the vast majority of folks who were uh getting jobs after graduation

they were going up to northern virginia or dc they were doing public sector work maybe they

were contracting there were one or two people in every class that would kind of like uh go out to

the west coast and my sense was like i wanted to be one of them really aggressively because

i had no interest in going up to dc like it felt like the zeitgeist of what was happening in tech

and working at like big exciting novel companies was mostly on the west coast or mostly in new york

as opposed to virginia and dc so i worked really hard to try and like get myself either in the bay

area or seattle after graduation um just so i could learn from a larger culture of tech that

wasn't purely government-based yeah that's great well okay that makes sense because i was you know

reading through your, your personal site, you talk about writing poetry and reading poetry.

And I don't think I've ever seen that before. Yeah. Yeah. Which is great. I mean, you're sort

of like, you know, you, I wasted 10 years doing book publishing and getting an MBA, but, and then

also was like, I got to get off the East coast. I got to go West and like, get out of this old

world mindset. Okay. Wow. So that's, so was your first job out of, after graduation, was that at

Amazon. And it was, it was a really nice blend of kind of my, my former and then current passions.

I was working on Kindle, which, you know, Amazon, as I'm sure you two know, like there's a lot of

horror stories about the, the engineering culture there and how, how crazy it can be at times. But

it was, it was a perfect launching pad for me because I got to work on a topic and a vertical

that I was really, really passionate about, really, really knowledgeable about, but also got

to learn from folks who have been in industry for for decades at a time and then you went after a

number of years you moved over to stripe is that correct okay um that's that must be there must be

a war story or two in there like stripes both those both those companies are quite a little

high profile really no no oh yeah it was the stripe was an incredible experience i was very

fortunate in that i was one of the first few folks who kind of spun up the stripe seattle office of

um the the reason i originally joined is i was i was looking for a change of pace but i loved

living in seattle and had no desire to sort of move down to sf for the bay area and they were

starting to hire their first couple engineers to build out a seattle space and one of the things i

wasn't really expecting was how much of that role for the first say six to nine months was almost

more like um recruiting than anything of you you don't think about it until you're in it but

part of the the ambit and part of the mission of these rapidly growing tech companies is hey this

this engineering office has a dozen engineers we need that to be like a hundred by the end of this

year how do you do that without like sacrificing the quality bar and not just like letting anyone

in how do you do that while still shipping product and like maintaining a culture and all of those

things uh so much of what i look back fondly about that time was just uh going from we're in

a sublet of a sublet in like a random downtown a high rise like we've got four floors and like

uh i've chatted with you know at least half or two-thirds of like the hundreds of people working

here so really really fun uh high velocity time for for better and for worse did you get the big

corner office like on those oh absolutely not yes i was i mean there it was very um open plan

style right uh like we we had rows and rows of desks and you had a good amount of space but

there was a big emphasis on like collaboration and the only sort of closed off doors you're

going to have is for like meeting rooms or things of those lines so i okay i do have to ask how do

you hire quality engineers quickly because that's the thing that is both the company line and i do

honestly think is true is like there's no real magic bullet um you just have to like spend a lot

of time and spend a lot of effort and if you try and like uh sacrifice on one of those things it's

going to bite you throughout the process i think one of the things that stripe does in particular

really well that I am surprised more companies don't do is rather than having say like a bit

of a choose your own adventure where if you apply to most of the larger tech companies uh whatever

like interviewer you get they probably have a pet question that they ask all of their candidates and

like that's what you're gonna try and get Stripe has a very rigorous sort of interview question

creation system of like all of Stripe and you know thousands and thousands of engineers at this point

They had a corpus of maybe a dozen or two dozen very specifically calibrated questions.

That way you can enforce consistency of like, well, we know that a really good candidate

handles these specific edge cases and knows how to handle like this part of this problem

and so on and so forth.

And I'm surprised more companies in the industry don't kind of go with that standardization

approach because it just makes it easy to avoid implicit bias and have like a very strict,

very standardized bar for who is performing well and who isn't yeah no that's a good point because

i think people just make it up as they go along largely 100 did um so i did an interview in the

kindle office as an mba student in 2010 and at the time they had i did the whole full day thing

where you meet with like seven people and have lunch and they had like was it the level razor

basically the person who's a jerk to you the bar razor the bar razor did they do that in the tech

side as well? They did. I think it was, and again, it's, it's one of these things where

hiring is such a weird sociological problem because you have really perverse incentives.

Like if you're a hiring manager, regardless of what org you're in, like the standards that you

have for someone who's joining your team might be slightly different than someone who is completely

removed. Like, I think one of the things that Amazon did was whoever their, their bar raiser

would be it would

have to be a

completely different

org so they have

like no emotional

attachment to yeah

oh well this person

isn't great but we

do need to like ship

this product which

means we need to

like hire someone

quickly and get them

onboarded within three

months I think that

level of editorial

remove is always

smart um

But again, it's I feel like we're going to look back on how we do engineering, hiring and onboarding as an industry.

A hundred years from now is like this was the dark ages, like everyone was just kind of like throwing darts, trying to see what worked.

It feels still so early days and so unscientific.

OK, I'm going to ask one more question on that kind of thread.

They're like software engineering. There's this title gets thrown around, you know, but you compare it to civic engineering.

there's kind of a lot less engineering goes on do you think we're still a very young industry

from that perspective of having better systems better more more rigorous engineering practices

in place and i guess that's hiring practices as well absolutely i think you can look at this from

from a number of angles like uh i'm i'm the number one person to kind of bemoan and besmirch any kind

of uh software engineering like productivity metric or things along those lines but like

if you want to compare different disciplines of engineering like we should be able to do as an

industry a good job of saying like hey how productive is this corpus of engineers or this

given work stream and we're still not really there yet i think to go back to stripe like stripe as a

company and as an organization takes a lot of that discipline really seriously because you know it's

one thing i think it's different depending on what the role of the given piece of software is

strike from day one took really seriously that like hey if we have a bug in our software that

can mean billions of dollars of money movement even if it's just downtime like that downtime

means if you're offline for a couple seconds that's billions of dollars of volume that isn't

being processed. And they built out those rails from a very early stage of like, how do we make

sure that there's a focus on all of these kind of uptime and reliability and security angles

without sacrificing productivity. But, and I'm curious to get y'all's thoughts, but it feels

very much to me that one of the hallmarks of us being very immature as an industry about this

stuff is every organization has to figure it out from scratch to a certain extent. There's no like

omnibus best practice of like this is how we as a guild of software engineers handle these things

there are really good best practices but there's no formal like repository of knowledge around this

yeah i mean like i think that's bang on is that an engineer in almost every every field gets a

certificate because they've got a certain you know they've got a degree or they've got a certification

or they've got a you know postgraduate thing that says you know you are qualified here you've you

know the safety practices you know that and not that kind of bulletproofing isn't appropriate for

every project if you've just got an image carousel it doesn't you know if it's not super tested but

it's not the end of the world but again payment processing that needs more or the space shuttle

is the good example right and he's exactly well i know that um we'll move on from stripe but i

just recently i had some colleagues uh from a startup i worked at who moved to stripe pretty

much all of them moved to stripe actually and uh i know i just was emailing one of them i saw a bug

in the docs and i was like oh you you moved to open api and he's like yeah well you just just

do bugs at stripe and patrick's cc uh the ceo is cc'd on the those emails and you know of course

he's not responding but when the the boss is on this email list sure enough i got a response in

10 minutes you know because i was like hey there's a 404 in your checkout stuff like that does speak

to the importance coming from the top on on those things right because if the head person doesn't

care. Everyone else will slowly let those things slide. Absolutely. And I think one of the things

that I internalized most from my time at Stripe was just how rigorous and how thoughtful all of

the C-suite, all of the senior leadership really was in terms of like keeping a pulse on not just

like how are we doing at a top level as a company, but like individual, like how does it feel to

be an engineer like be a junior engineer and shipping code against this code base how does

it feel to be a new user running through stripe for the first time one of the things that patrick

the the co-founder and ceo did that i thought was mind-blowing and i again don't understand why

every company doesn't do this is he had what he called an engineer occasion every every quarter

which was he would parrot drop into a random eng team basically say give me a ticket i want to like

solve this ticket push code get it live to get a sense of like how things are working from an

engineering productivity standpoint like what are the rough edges because I think as companies grow

and grow and grow it can be so easy to get removed from like the day-to-day feet on the ground like

action of being part of that company or being a user that uses that company and I think there's

no magic bullet. You just, you have to be really disciplined and really strong willed about not

losing that visibility. And I think Stripe does that super, super well. Okay. Well, so all of

this, I think ties into, you know, your, your current job running an organization. Cause I

know you've talked about you, you, um, moved on to being an engineering manager at Stripe and

you've written about how you went from being proactive as an IC individual contributor to

reactive. What, what was that transition like? And then I'm sure that that's playing today,

you know, when you have to, again, do everything, but it's not, it's not easy to do. It's not easy

to do that. No, it's definitely not. I think I, I learned so much from my, my first transition

from being an IC to, to being an EM, um, large, and a lot of that has been incredibly, incredibly

useful. Cause even though I don't consider like what I do now as a, a literal engineering manager,

Like I do manage engineers and like being a founder requires so much of the context switching and so much of the reactivity that being a line manager and managing, you know, a small team or a couple of teams of engineers requires.

I think when I was developing as an engineer, so much of what I considered like getting better at my craft was around like figuring out how to get objective information and become more productive and like really manage both increase the amount of time I could spend in flow and make sure that that time was spent as productively and as usefully as possible.

which meant like spending a lot of time chatting with users to like get a lot of business information

and business value and like focus a lot on my tooling and a lot of what i loved about engineering

from my first days like modifying janky html and css on a wordpress installation to today was

the richness and speed of a feedback loop right of you you have a bug report you you write a test

you fix the test you instantly get the green check mark it's boom it's done and what i had

to unlearn shifting into management and shifting into like, uh, less IC oriented thinking was like

all of that stuff, like no longer really applies. And often the most rewarding parts about management,

both from a, uh, managing other people or managing businesses sense is the aperture is months or

years or weeks. It's not days or minutes or seconds. Like you might have a really good

conversation with a candidate that you're trying to recruit or someone on your team,

And you don't get to realize the value of that until like half a year later where they're like, oh, I got really better, much better at this because of this specific feedback you gave me or like, oh, I wasn't thinking about joining Stripe, but like or think about joining Button Down.

But the conversation we had over coffee, you know, back in September really changed my mind.

I think it can be hard, or at least it was very hard for me to context switch between those two modes, especially when, you know, most folks who first go into engineering management, unless you're at a really big company that's really strictly structured, you're going to be doing both.

Like you're going to be managing a couple engineers and you'll probably be a senior end or a tech lead on that team.

if not explicitly, then implicitly.

And getting comfortable with being in both areas at once

was really tricky, but also really rewarding

because I think that's what life is about.

Like it's really hard to maximize your impact in the world

by being a purely engineering focused,

like give me the tickets, I implement the tickets,

I move on to the next ticket.

Like that can be great.

And those are usually my most satisfying days

to a certain extent,

but they're rarely the most valuable ones.

There's lots of dopamine hits that you get.

Oh yeah, I fixed that one, I fixed that one, I fixed that one.

Do you have then in the engineering manager role,

do you have indicators that you track that they might be laggy

and that they don't come back for months later,

but months later you can say, oh, do you know what?

Retention's gone up, employee turnover's down.

Or do you have something like that that you can sort of say,

oh yeah, I did do well.

I think there, I wouldn't even consider them metrics,

but there are specific things you can look at to your exact point

around like my my goals as an engineering manager were and are always to like accomplish the

business goals of the team and this is a thing that varies from org to org but at stripe for

instance the engineering manager is responsible for the not just like the happiness and health

of the engineering labor within the team but also just the business goals of the team writ large

which is different from some companies might have ems be solely responsible for the end side but

there's like a PM assigned to the team that actually has to drive the business solutions.

And at Stripe, it was very much a balance of making sure the engineers are happy and healthy

and productive while also making sure we accomplish what we need to do from a business perspective.

But I think beyond the very concrete things around turnover and retention and up-leveling

or growth I think a lot of it was just learning to let go and listen to the folks who report it

up to me of like I can try and do all the spreadsheeting I want to like make my brain

feel happier about me doing a better job but like all of that kind of like washes out in the rain

compared to just the engineers saying hey yes we are shipping this like I am being challenged but

a good and healthy amount i'm growing i'm learning a lot i feel psychologically safe and healthy

within this environment like i really had to learn to lean on the qualitative feedback as opposed to

like again i have an engineer brain i want the quantitative feedback but unless you're looking

at a really really macro lens often that can just be noisy yeah and the qualitative word is the key

one there right it's like there are things that aren't they're not metrics they're not neat there's

qualitative data that's much more important and much more meaningful and yeah exactly good

oh isn't this about stripe i thought

what are what are some recent features you've pushed that you're proud of because i know

from the outside it's like oh you launched it um what 2016 2018 and one could think it's just the

same but of course you've been working away so what are some recent features you're proud of that

um you've launched in the last i know year or two yeah i think one of the the operating cadences

that i've really loved is like you you kind of have a big big expansion year and then a big

digestion year like 2023 for button down was we shipped a lot of new stuff and we grew a huge

amount and then this year is let's re-architect some of the internal systems let's make sure

performance and scaling and all those other things are really really good so that this this coming

year 2025 we can go back to another expansion year and really figure out what are the next

things to push the product forward the the biggest thing we launched last year uh which is one of the

uh really tricky things in this industry is naming so we call it automations which

are the equivalent of like drip sequences or life cycle emails or any of the things that uh

have kind of one name per company that's implemented them but the ability to do

instead of just one-off broadcast,

you're sending it to everyone.

You can send specific emails to a subset of folks

based on like, okay, they signed up on a Monday.

We'll send them an email on the Tuesday

and then a Friday.

And then depending on if they have a given tag

or they have like this bit of metadata associated with them,

we can customize the third email, that sort of thing.

And that was like a really fun systems problem

because there's a lot of UX concerns.

And then there's also a lot of just implementation level concerns

of like okay do we want this to be governed by a state machine like how do we want retrying to work

how do we want all the various moving parts to cohere with each other in a way that makes sense

especially because one of the things that i'm very very mindful of is i want button down as a system

to be like pretty dense and pretty stable so that it's really really important whenever we build out

a new piece of functionality it's not like oh well this is going to make the code base 20 harder to

maintain for eternity like whenever we introduce something new we want it to be as stable and as

coherent with the rest of the functionality as possible not just from a user standpoint but from

an engineer working on the code base standpoint and i can imagine that kind of workflow logic

state machine type stuff that that's got the potential to get quite ugly quite quickly if

you don't oh yeah think it through yeah one of the one of the i think breakthroughs that that led to

it shipping in in the way that it did and we're really really happy with the abstractions was we

took a step back and looked at the other pieces of button down that already kind of looked workflow

shaped like you said and it was like oh well if you if you think about it like web hooks are

basically like this of a thing happens somewhere in the code base and then we need to run some

logic based off of that rss to email is kind of like this where we have this external piece of

state that changes we need to detect that and then like spin up an email and send it out based off of

that and we were able to pull out some common threads and logic throughout the existing code

base build some abstractions around that and so before we even shipped the functionality we had

built a lot of the back end for it that was then powering existing features and then it was much

more easy and elegant to add a ui and add new functionality on top of those abstractions because

they already had traffic rolling through them. We knew it scaled from a performance and from a

maintainability standpoint, as opposed to just, well, we're going to graft on another big piece

of the code base that has a totally different way of looking at the world. And it almost sounds as

if it's like the one, two, three refactor type approach in that you've got a couple of built

cases, then you can extract the common patterns. That's much safer than, you know, writing something

fresh and hoping it works. Exactly. I'm curious at a high level, like who do you talk to about

these things is it just you like do you have a mastermind group like right how do you get a gut

check on or do you just block off some time and think it through and then and then do it right

that's always the hard part when you're running your own show that has definitely been i think

the hardest part about shifting from working at a big company to working at uh whether it's a a

solo sort of startup or a much smaller company is there there are fewer people who i can go over

and like kind of poke in the back and be like hey can we whiteboard this for for a couple minutes

i'm thankful to have like a couple friends and and former co-workers who i can at a high level

sort of talk about like hey let me just you know rant at you for 15 minutes and please let me know

if any of this is totally incoherent like you do get that kind of gut check from someone who

hasn't like sat and looked at the code base to the same extent you have and like there are a

couple engineers who work on button down who i can chat with about this kind of stuff but

a huge amount of it is especially in the early days just kind of thinking really hard for a

couple hours like i'm a big fan of sort of writing things down like writing down a prd even if it's

never gonna get read by anyone just to sort of like help cohere my thoughts it's the english

major in me right like uh i i can think best when i'm writing and so i've found a huge amount of

value in doing that but it's I think harder than it would be to say like all

right I'm gonna present this architecture diagram to my team I'll get

sign-off and criticism and feedback from them and reify that I think part of what

is difficult about starting something for the first time is you have to be

comfortable with the level of

like ambiguity or like lack of supreme confidence and just be like, well, I've done a sufficient

amount of de-risking for this. And if that's insufficient, then I'll get to a point where I

can bring in beta testers or bring in folks who can like help me benchmark things or things along

those lines. This episode is sponsored by MailTrap, an email delivery platform that developers love.

an email sending solution with industry-best analytics, SMTP, and email API SDKs for major

programming languages and 24-7 human support. Try for free at mailtrap.io.

So I imagine you have a lot of async going on in your application just because email is sort of

like the poster child for async. Carlton here has worked a lot on Django's async. So I'm curious,

what do you like and not like about how Django is doing things these days? Because I'm sure

you're kind of pushing the boundaries of async within Django. One of the things that I have

enjoyed doing is just like sort of piecemeal migrations in the early days. And like one of

the things that actually made the shift to Django being so async friendly, like a little almost

anticlimactic in a good way was I from day one was dumping anything that looked async shaped into

RQ which if you're unfamiliar or listeners are unfamiliar RQ is like a task queuing library

similar to Celery and and all of those and so a lot of the workflow shaped stuff where it's

we have to hit this external service like there's some state associated with it all of that was off

the main thread where I really got a lot of value from a lot of the acing stuff was things that you

would want kind of on the main thread but can be streaming or can be a little bit uh like more

async shaped stuff like pulling in initial batches of data or doing like really small remote checks

i think when javascript first brought in sort of async await stuff back in i don't know when that

was maybe a decade ago at this point um there was a lot of hysteria and a lot of like confusion

around what the migration path looked like and when javascript went through this this migration

a decade ago, it was pretty, I think, fraught, both from a imaginary standpoint and like the

actual process of bringing in async await and figuring out how to do polyfills and all that

stuff. Honestly, the best feedback I can give on how Django has been doing it is there hasn't been

like a lot of pain. Like I've been able to isolate specific views and pull them in. And it has been

a piecemeal project because it hasn't been a like, well, let's just adopt this wholesale across the

application and hope for the best but every time i'm like all right i think this view or like this

specific usage pattern would benefit from adopting it it's it's been like very non-dramatic there

hasn't been a okay i need to dig into the weeds and figure out why this behavior is happening the

way it is but that's the exact approach to introducing async into a django project that's

the way we want you to do it that's the best way to do it is yeah you know for this case you sprinkle

little bit of async yeah and then there's a difference between as you said throwing something

off to a queue where like that can happen anytime and then these sort of more async i'm going to

fetch a couple of apis and merge them together and exactly carlton you ask a question i've been

bombarding poor justin well okay but i i want to ask about the business side of email because

like there's it's quite a crowded marketplace right so it's it's quite like brave to go into

that marketplace and say right i'm going to do a new startup and you know to do you have a sort of

market insight that led you to say right i'm actually i'm going to do this one of the things

that is a double-edged sword about entering a really big really crowded market is yes from day

one you have a lot of competitors like you're going to have hundreds upon hundreds of competitors

and they're not little on the other side say that again they're not little competitors they're big

they've got resources yeah you know and like with every passing month like a new venture-backed

startup will launch that that's doing something with emails like some really big fortune 500

company will spin up like an email related sub vertical like there's always new people coming

onto the scene but the flip side of that is there's just a huge huge number of customers

that already have demonstrated like a willingness to pay and one of the things that i really liked

about email and i think i underappreciated when i was first building button down because i should

uh preface all of this with like i am not some sort of business genius who's like i've identified

this this little niche in the market that i'm going to go after like button down all came from

me being like well i want this tool that works for me and like let me back solve my way into

finding a market for it but with emails in particular one of the things that makes an

attractive industry for new entrants is the average user, like they might have some stuff

tied to a given provider. Like if you're using MailChimp, you probably have some automations

and settings that are very MailChimp specific, but 99% of what is actually valuable to you

are two things, which is your back catalog of emails you've sent and your list of email

addresses. And because email is decentralized and portable, you can bring those things with you

to whatever provider is most attractive to you.

Like it is not an industry

that has a lot of moats associated.

Yeah, right.

And that made it particularly easy

to try and find existing customers

who are using a tool that they didn't love

because you can credibly and legitimately say,

yes, you're already using MailChimp or Drip or whatever,

but it'll take you 10 minutes

to bring your stuff onto here.

Like you can drag and drop a CSV or a zip

and we'll pull everything for you.

It's not like you have to start over from zero.

that's not true of all industries but at least within email and i think it's it's true of many

industries like being able to reduce that friction of switching costs as low as you can is is really

really valuable the other thing too is button down i don't think is ever going to become like

a billion dollar business but the email industry itself is and being able to really approach

problems and approach differentiation in the space from a perspective of like well we're not

going to take over the industry, but if we can be the best product for 0.1% of everyone who needs

like email products, like that's a really good business right there. And having that level of

specificity and focus on a very specific niche, I think has been really useful.

Right. And so the, the, the sort of, Hey, you, you can write your emails in Markdown and they

just sort of go, that's, that's a nice specific niche. I've talked a lot about Markdown being

like kind of a weasel and i guess weasel word isn't the right phrase but like a really good

signifier because there are a lot of potential users who look at button down splash page see

a reference to like markdown and html and they they run fleeing for the hills and like that's

kind of fine because those people are probably not great customers for me anyway but the other

side of that is if you go to button down email and you see references to like markdown and you're

like, Oh, that's what I want. Like I'm sick of using a WYSIWYG. I want to be able to just write

markdown. Like it's such a good qualifier for potential users. Okay. That's good. Then the

other sort of side of it as well, I wanted to ask you about was the kind of pricing and how you're

pricing, how you sort of think about pricing, because we had Michael Kennedy on from talk

Python a couple of weeks ago, and he, we are, he's moved to self-hosting email because of the

costs that he had. And email does seem to be quite expensive, you know, AN automated marketing

package 100 quid a month just to start that seems quite a lot for small companies but obviously

that's where the big money is and so how do you think about pricing and what's your kind of

take there because button down is very reasonable to begin like that's another point i like i like

the footnote there yeah no but it is it's like start for free and you know small amount and then

slightly bigger and so how what's your kind of take there because we did we were talking with

michael about this so it'd be nice to get your view from the inside of course i think one of the

interesting things about the email industry as a whole is the vast majority of vendors myself

included we're not actually standing up and running the smtp rails ourselves like we're we're hitting

a even further downstream service like postmark or mailgun or one of those and that's true of

almost every major like newsletter email provider except for a couple few i think like mailchimp and

potentially cloveo now they've started to host and use their own rails in the past couple years

and what that means is there's really like a price floor and there's only so much experimentation

that you can do and it's also why i think uh self-hosted services like sendy are such a great

idea because you can pass that on to the user you can say well you can run this yourself if you feel

technically inclined and comfortable like standing up a docker container and all that stuff um when

i was first working on the pricing strategy for button down again going back to me not being a

marketing genius i think my logic was basically well here's a big google sheet that i've created

of like the eight other companies that i think people are using that i would like them to use

me instead and so what rough triangulation can i hit so that no one like i'm not uh undercutting

everyone but I'm somewhat like in the neighborhood and a lot of my logic in the early days was

based around like I didn't want people to choose or not choose button down solely based on price

like I wanted to make sure my unit economics were solid but I didn't want to like just advertise on

hey we're cheaper than whoever or like hey we're going to be more premium than whoever I wanted to

be roughly commoditized and that approach in general has has worked well though you see some

shifts over time like one of the things i did a couple years ago was i realized a huge amount of

my costs were coming from purely free users so i had to reshift the free plan a little bit push

people to pay like a couple bucks a month just to send more than like a thousand emails a day

things along those lines um i think this is a bit of a cliche but it's a true one like one of the

hardest things to do and also most valuable things to do is like experiment and change prices a lot

You know, in a way that is like not annoying or turning off users, but just like every couple of years sort of see like, hey, does this business model make sense?

Are there certain things that we can do to like better align with users?

I've actually been kind of bad at that to the extent that I've modified prices, I think, twice total since launching six years ago, largely because just the unit economics of having a tiered pricing like $9 a month, $49 a month, $79 a month fits so squarely onto how a lot of people look at these businesses.

But again, it's slightly different if you're not in a super crowded industry where every single customer is kind of expecting some level of pricing package.

And if you were to deviate wildly from that, you're kind of distinguishing yourself in a way that is not particularly good.

Okay, interesting.

So just to pick up one thing you said, a lot of it is about the reason why it perhaps looks expensive for email services is because the upstream cost of whoever's actually sending them, that comes back down.

Exactly, yeah.

The fun fact is button-down single biggest line item cost on a month-by-month basis is just straight up how much it costs for us to send the emails.

You pay the equivalent of a fraction of a fraction of a penny per email sent.

But that's a lot of emails.

Exactly.

When you're sending millions of emails a day, that little fraction of a cent adds up quickly.

Okay.

Interesting.

Good.

So I'm based in Boston, and maybe I'm saying it wrong.

Klaviyo just IPO-ed, and they're also Django-based, I think at like $8 billion or something.

But I'm curious to you, that's email-based commerce, I think, right?

Like I see now every e-commerce firm.

What are the buckets of email, right?

There is what you're doing, like newsletters, there's e-commerce.

Are there others, or are those transactional, I guess?

Like what are those layers abstracted above just sending straight emails?

Yeah, I think the three buckets that people usually talk about are transactional, which I always think of like password reset being the canonical example.

You as the user clicked a button, you get an email that like corresponds directly with that button.

And transactional emails are usually broken out by a lot of ESPs is like this is going to be very high volume, very high like open rates.

It's always going to be in the inbox. But if you like try and abuse these rails, we will offboard you from the from the platform.

There's broadcast, which is if you think about like J.Crew sending out coupons to like millions of people or you as just like a newsletter author sending out an email saying like, hey, I published a new blog article or something along those lines.

Just it's one to many, but you assume that everyone has opted in.

I think five, six years ago, double opt-in was like a bit more of a gray area.

And now, thankfully, we've ratified to the point where if you as a sender are consistently sending emails to people who didn't agree to get them or engage with them, like you're going to be so heavily penalized by the email overlords that it's really unsustainable, which is a great development.

And then the more e-commerce oriented, I think the current term du jour for this is omni-channel.

Meaning like we have a subscriber who has an email address, has a phone number, has like a WhatsApp or Telegram ID that we can hit.

Like we have a lot of data points around them and you can reach out to them through whatever channel you think is the most useful for whatever intent you have.

And that's really reserved for Cliveo. I never know how to pronounce them correctly or MailChimp or folks in that vein where it's like really, really heavy duty, really powerful tooling that's largely around purchase intent.

And going back to the pricing discussion a little bit, a lot of the larger players that have moved so upstream in terms of price is because they've started to anchor less on like SMBs or authors or people using it kind of in a more independent way and more like, well, you're a Fortune 500 company, you're a massive retailer, like you're spending, you know, $50 million a year on marketing ops in general.

And if we charge you 50K a month to like send your emails and do some automations, like that's a drop in the bucket to you because you've got like a bunch of people working full time on it.

And at that point, if you're a small developer or a small company with running a Django app, you've got no business using them anyway, right?

Exactly.

Yeah.

Well, I think your approach is smart, though. It's a little bit like boot camp, I would say, in that they've explicitly said they don't want a couple big enterprise customers because so many services, it does weight. I mean, what was it? Slack. When Slack IPO'd, you could see that like 60% of its money came from like a handful of companies. But then you're beholden to them. Whereas if you're more like, I'm indie and like, this is what it is, take it or leave it, you're kind of more stable in the long run, I would think.

Exactly.

Maybe make less money, maybe, but you're also, you know, even out a lot of churn that I'm sure if I'm a Fortune 500 CEO and I'm talking to one of these companies, I'm trying to squeeze them on cost for sure.

Right. And that's where the balance between pricing and product or pricing and positioning is really interesting, because on one hand, I can really sell button down to a lot of smaller, more SMB or more, you know, creator economy type folks is like, we don't include all of this stuff that the really big players do of like A, B testing across multiple campaigns and all of this stuff.

But you don't want that anyway.

So we get to pass on that savings to you because we're not charging you implicitly for the

cost of maintaining and developing those things that you don't want.

Like I'm sure everyone has some application that they use on a day-to-day basis that is

really, really important to their workflow.

But like 95% of what that application does is like completely not what they want.

Like I balance my book.

every month like using QuickBooks I have a CPA we have like a shared QuickBooks

thing and whenever I log in there's just so much stuff where it's like I'm not

trying to do any of this and I understand why you built it out but like

all I'm really trying to do is run payroll and like file receipts and like

the the bare-bones kind of like very basic stuff but there's all this product

baggage that is being passed on to me because it also has to serve a wide

swath of larger uh more uh heavy customers i imagine though that for you you you must have

some some whales and they're start asking for some of these features that some of these others

provide and then you have to internally balance that out right because you that must be a good

gut check when you know at what point do you let you know sort of like i know you're hosting on

heroku like at some point it's like i should make the leap um there must is there an equivalent for

you or how do you think about that because i would imagine that being the case philosophically

most of my largest customers use button down for a lot of the infrastructural and api pieces there

which means that like i have a really good opt out for lack of a better term like i can say

hey if you're trying to add this piece of functionality let's talk about like how you

might structure something that talks to our api one of the big parts of button down's philosophy

is anything that you can theoretically do in the app you can do programmatically if you were to

open up the the network tab for button down and just like look at all the requests we're hitting

the external facing api like the the button down front end the spa is like implemented as a third

party that hits the api and for the vast majority of sort of like whale style requests of like oh

well i really want to be able to do x uh i try and make sure they have the building blocks within the

api but also it's it's one of those things going back to your point of the pressure that larger

customers can bring i i make it very clear that there's never going to be any sort of like one-off

feature implementation if we ever build something within button down it the timeline might shift

because like one or two really big users want it but like it's not going to be something that

wouldn't have been built in the fullness of time anyway i think it's a really hard line to say like

no i don't want to add this amount of like top line revenue to to my balance sheet for 2024 but

like i have to um but i think if you take a really really long lens like not the scale of years but

like the scale of a decade the cost of like building and maintaining some ad hoc janky feature

that this one customer really wanted like that adds up really really quickly and it lasts forever

you too know how difficult it is to unship code like getting rid of code paths because as soon

as you launch it like there's going to be a couple other people who are relying on it too

and and there's so much detritus that builds around it and so it's difficult but like i think

you do have to exercise a little bit of discipline and say i understand that you want this like

here's some ways you could build it yourself but we're not going to adopt it within the product

because that's just going to be a long-term drag on our balance, not a long-term positive.

Yeah, I love that philosophy. I think that's very wise.

Well, I have one more, and then I'll turn it over to Carlton. I guess this is, again,

philosophical. How do you maintain your interest? Because you've written about this, and I would

agree, especially for a founder-led indie thing, in some ways, that's the biggest risk, right?

You prove traction. And I know you have Third South Capital and some other things, but what is

it for you that keeps you interested day to day? I think one of the... I would not have expected

this to be my answer, say, two years ago. But one of the things that is really, really fun and

really rewarding about having a company that's at product market fit and is growing is figuring out

all of like the meta work and like the systems work that you need to go from all right well this

thing has a bunch of customers like it's bringing in money it can pay a salary like it's doing well

to like how do i make sure that this thing can run on autopilot for like a month if i just want to

like throw all of my electronics in into the river and like go go to france or something and a lot of

that is really interesting architectural work of like okay how do we build out a knowledge base for

the internal support staff how do i write down all of my tacit knowledge about like how these

specific systems work that can't really be encapsulated within the code base all of that

like those are really fun interesting challenges that are they actually hit the same like dopamine

part of my brain that like solving a unit test does of like being able to offload some of that

into like a documentation base or into other people and like really building out the company

as opposed to just building out the code base.

I think that's been a huge part

of what keeps and captivates my interest.

The other part too is like,

despite all of that,

I'm still like a person who loves

like shipping and building software

and that's where I'm the happiest.

And part of kind of setting out on your own

and like doing your own thing

as opposed to working in the auspices

of a larger company

is optimizing for your own life.

And a lot of the time I will say,

screw the roadmap screw my responsibilities screw what is like quote-unquote best for the company

within this given week here's a feature that i just think would be fun for like my use case or

that i want to hack on like let me carve out some time and do that and the the like funny coda to a

lot of those work streams is that when i started button down it was it was purely for me and even

when i do these things where i'm like i can't really justify working on this but i want to

like i'm going to ship it and just see what happens often that's the stuff that resonates

most with users or is most successful because it's not necessarily obvious but being able to say like

i'm going to drop everything on a friday and like work on increasing load times by 200 milliseconds

like those sorts of things that are hard to justify in a larger framework but are still

satisfying is like why i love kind of being independent and getting to do what i do every

day it's like your 20 time for yourself exactly i think that's a good frame for it but those are

the things that have the flavor, right? What's the, what does it take? Well, it doesn't, I don't

know. It takes a button down. That's, it's, that's what gives it its character. That's all.

I love that.

So, okay. So change track quickly. You've talked about the, the API and then the SBA that eats the

API. I think that's a very sound policy and that's, you know, nice to see. I wanted to ask

you then, you're using React, I take it, and perhaps describe what your stack is, but how do

you feel about the the changes in front end that we're seeing at the moment and you know the likes

of the htmx is and where do you think it's going and you know it's been some complaints about react

and you know what's your view on that kind of that that ecosystem and world space for sure and i'm

using view technically not react but okay fine okay they're both they're both of a piece like

they have different philosophies in many arenas but i think the pros and cons of adopting either

are very very similar i think the biggest failure mode i see for a lot of folks who like go into the

front-end ecosystem for the first time is they they read something online that says like you

need to use react to like build your application don't really question it or interrogate it and

they're like well i guess i'm supposed to like spin up a next app or whatever and like that's

how I'm building this. I think React and Vue and Alpine and HTMX, they're all great tools depending

on what job you're trying to accomplish. I think for the median person starting a SaaS in 2024,

you probably don't need to start with like React or Vue or something that's super heavyweight.

You can start with no JavaScript at all or using HTMX or using like one of the very sort of like

lightweight, here's a bit of interactivity that's powered by JS. You can drop into your

applications. And I think when you adopt any piece of technology, not just like a front-end stack,

like you need to have a really good reason to do so because going from just one piece of tech to

an incrementally different piece of tech is such a big, heavy, heavy weight, whether it's bringing

in Vue, whether it's like bringing in Redis to manage like Celery or RQ or Rabbit or something

like that. I think that's the lens that people need to adopt more of as opposed to like, well,

this is the state of the art in 2024. You either have to go this way or you have to go this way.

I think you sort of asked about like the front end, like churn and the amount of like chaos on

a year to year basis. And like, I definitely feel that like, personally speaking, I think a huge

part of my philosophy has been, let me adopt things once they feel relatively stable and

relatively consistent and my my rough heuristic or metric for that is like when i google something

am i getting like stack overflow results because people have run into this before or am i am i

getting like blog posts this is now in beta from like the the team that built it out uh like i

think rscs or react server components and things like that where you know three years from now

that might be the state of the art that might be kind of permeated into the entire world of like

how complex SPAs deal with stuff.

But right now, it's just,

it feels like there's so much flux

and the amount of value

I would get into investing

in a new technology like that

is just outweighed by the level of friction

it takes to figure out,

okay, how do I do this now

as opposed to what it was three months ago?

And how do I like figure out

where to future-proof myself?

One of the things I guess in closing

that I feel really strongly about

is limiting your surface area with tech,

whether that's number of third-party packages, number of distinct technologies.

One of the engineers who was early at Etsy had this great blog post that was very influential on me

around spending innovation tokens of you as an org or you as a company.

You can only do so many things and hold up so many things particularly well,

so you need to be really, really tactical about where you choose those investments.

Yeah, okay. You can come on again, Justin.

That was the right answer. That was the right shift.

Well, it's what we think.

It doesn't mean it's the right answer.

Well, one final question is what we always end with, which is if you have a magic wand

and you can change something in Django, what leaps to mind?

Like no restrictions, just what would you do?

It's a great question.

And I cheated a little bit because I know y'all talked, I think maybe it was last week

about the roadmap stuff that came out of the January working session.

And so I think most of my answers are in that.

um i think the biggest one the biggest single one would probably be off of uh and this is kind

of like a blessing and a curse there there's a number of third-party packages that i basically

consider for my purposes core django uh one of them is all off because like the the all-off

abstraction and i talked about how much i love django's built-in auth but with the rise of things

like 2fa with the rise of social login like i feel like any maybe not any but the majority of

serious django use cases need that stuff at some point and being able to fold that into standard

django just makes sense or increasing the rails or increasing the ergonomics of adopting um frameworks

like that um i think the other one and this is really selfish and i also know it was covered in

red map admin is an incredible tool i when i was spitting up support staff for button down

the amount of work i had to do in terms of building out tooling was basically zero because

it's you get all these model views and all this permissioning and all this stuff for free which

is great um one of my pain points with admin i guess the two pain points one is like the styling

of it i just feel like it could be faster and more modern and like have omni search then the other

would be the escape hatches that admin affords you is very limited. You could get 98% of what

you want for free. But then if you need to build out a custom view that has state or is touching

multiple models at once, you kind of have to start from square one. And so some investments

in that ecosystem, I would say, would be really, really nice. Yeah. Yeah. So I'm all with you on

the auth. I think it's time for that battery to be modernized. And I think we'll get there. There's

lots of threads going there's about pass keys and you know web authentic and those things so i think

things are going to happen there as well jangle wall auth has been um given a grant to pursue

working on things in this space as well so that's an amazing thing um on the admin i'd love to be

able to just sort of embed a view more easily a custom view it's a custom view but just embed it

in the admin that would be lovely yeah i mean it's possible but even like even being able to

because there's a lot of built-in support for like here's a detail view you can drop in an

arbitrary inline or drop in an arbitrary widget being able to have and maybe there are some some

rails for this that i just haven't found but being able to do that in arbitrary like list views or

arbitrary filtered views like that would be tremendously useful because the alternative is

well okay now i have to build out all this scaffolding again from scratch and like the

including story on admin is like kind of hard to navigate and so just some easier escape hatches

there would be great yeah i mean it's possible but it's not documented and it's not officially

supported and you're into you know weird and wonderful things that you find on the internet

to give you ideas and no that's not that's not the jangle way so no totally that's not

that would be a good magic one wave well is there anything that we haven't asked you or anything you

want to call out as we close up i think we we touched it all i would say like the i get a lot

of questions from folks outside the the django ecosystem because i think at this point especially

in like the the sasser startup world a huge amount of the zeitgeist is really around like rails or

around like full stack javascript stuff and like every now and then when i'm when i'm chatting with

another founder chatting with just anyone they're like why did you go with django and part of the

reason was i was just comfortable and familiar with django i've been using it for for years and

years on end but the the other part of it now in hindsight is like button down would not have

progressed nearly as quickly as it did if it weren't for all the things that the django offers

you both in the the early days the stuff like uh here are all these views and here's the off model

and here's all this stuff for free uh that you just get to hold on to and you don't have to build

out and you don't have to like spend a lot of cycles not not delivering value but just doing

table stake stuff but even now like there's no way we would be able to iterate on features and build

a application as quickly and as reliably as we do if it weren't for the django orm like the django

request request lifecycle the django admin like all these things are so tremendously useful tools

that i think people you can almost take for granted when you're sitting within django for

for so long until you look at other ecosystems and look at other landscapes out there and you're like

they have to do that from scratch we just get it it's just part of the django thing so i'm

tremendously grateful uh for for everything that uh the maintainers and the journal sponsors and

everyone involved in the django ecosystem has contributed over however many years it's been

at this point. It is something that I owe my business's success to. Okay, super. You can

definitely come on again. Well, Justin, thank you so much for taking the time.

It's a wonderful service. It's so great to hear someone using Django from scratch. And

yeah, these are the podcasts I like best. Someone who can talk through that journey. And you haven't

left the Django nest yet, and maybe you never will. So that's always nice to hear.

I would be shocked if we were ever unshipping Django.

And again, the fact that you can opt out of certain parts of it

without having to leave the entire Django nest

is, I think, a feature in and of itself.

But thank you two so much for having me.

It was a great time.

Thanks for coming on. Really good fun.

All right. Well, thank you, everyone, for listening.

We're at djangochat.com, and we'll see you next time.

Bye-bye.

This episode is sponsored by MailTrap,

an email delivery platform that developers love.

Try for free at mailtrap.io.