Transcript: Buttondown - Justin Duke

Try for free at mailtrap.io.

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

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome, Justin.

I'm excited to be here.

So tell uh for the you uh listeners who perhaps don't know, tell us what Button Down is and how you that's on a Django show.

So Button Down is an email tool similar to say MailChimp or TinyLetter Substack, uh, 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 um experimenting with, you know, some of the more modern web stuff for the the front end, but the core back end, how we send our emails, how people view those emails, all of that is running through Django and running through Python.

There you are.

A recurring theme on this show is people always say, uh, but maybe Go is better.

Um what are you what are your current thoughts on when you see something slow in your application and you know, maybe the grass is greener over there?

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

Well, can I ask how many how many people are working on Button Down now?

Because I know you have some support staff.

Is it is it just you in engineering, or what's what's the team size?

Like the goal has always been keep it really tight-knit and keep it really um, I guess, uh small in terms of headcount.

Like 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 like the uh the startup hedonic treadmill of like hire as many people as possible, spin them all up, like 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.

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 sort of working on it, is that really it's a force multiplier.

Like, there's no way I could have done this with you know in another project, in 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 the in that keeping it tight, keeping it small?

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

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

So I think some of this varies.

Like to talk about some stuff that has fallen 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 Django and like the request lifecycle, I think third-party packages like DRF, and now more recently stuff like uh Django Ninja or Fast API, 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 that is a custom front end that's 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 uh you know call button down to like uh programmatically send newsletters or chain subscribers and things like that.

And a lot of the stuff that you get out of the box from whether it's DRF or Django Ninja in terms of uh 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 gonna use Django CBVs, I'm gonna 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 uh really, really pay for it, if that makes sense.

And now I'm I'm massively curious about what uh dirty API stuff you're rolling for yourself in there, but uh, I don't know if we'll go all the way there.

Well, I Carlton, 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 uh William and Mary Computer Science.

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

And I had no

That is a small world indeed.

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 it was yeah, it needed a refresh.

But I remember 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 uh a web company, right, as opposed to a contractor in in Northern Virginia or something.

So that anyways, side note, so I 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?

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

You know, even in the 10 years uh 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.

Um, I came into undergrad not thinking I was gonna 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 uh the ad industry was not for me.

And in fact, my favorite part of the entire gig was like managing uh a couple of our clients' like WordPress installations 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 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 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.

Yeah, which is great.

Um Okay, wow.

So that's and so was your first job out of after graduation was that at Amazon?

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 uh 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 had been in industry for for decades at a time.

Is that correct?

Yep.

Okay.

Um that's that must be there.

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 or the Bay Area.

And they were starting to hire their first couple engineers to build out uh 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 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 high-rise to 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.

It's a really, really fun uh high velocity time for better and for worse.

Did you

Oh, absolutely not.

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 gonna have is for like meeting rooms or or things of those lines.

Because that's the thing.

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

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

100%.

The bar raiser.

The bar raiser.

Did they do that in the tech side as well?

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 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 I feel like we're gonna 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.

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.

I think you can look at this from a number of angles.

Like uh I'm I'm the number one person to kind of bemoan and bespurch 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 it's different depending on what the role of the given piece of software is.

Stripe 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 uh of like, how do we make sure that there's a focus on all of these kind of uh uptime and reliability and security angles without sacrificing productivity?

But anyway, 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.

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, well, it's not the end of the world.

But again, payment processing that needs more, or the space shuttle is a good example, right?

And it's exactly.

Well, 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 was like, Yeah, well, you 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.

And I think the one of the things that I internalized most for 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 uh 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 engineerication every every quarter, which was he would paratrop into a random edge 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 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.

Well, so all of this I think ties into you know, your your current job running an organization, because 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.

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.

Because 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 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 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 that stuff like no longer really applies.

And often the most rewarding parts about management, both from a uh managing other people or managing business's 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 the value of that until like a 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 thinking about joining Button Down.

But uh 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 uh 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 gonna be doing both.

Like you're going to be managing a couple engineers and you'll probably be a senior edge 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 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.

Oh, yeah, I fix that one, I fix that one, I fix that one.

So, do you have then in the engineering manager role, do you have like indicators that you track that they might be laggy and that they don't come back for months later?

But you could months later you can say, Oh, do you know what retention's gone up, we've we've employee turnovers down, or do you do you have something like that that you can sort of say, oh yeah, I did do well?

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

Um, but I I think the beyond like the very concrete things around like turnover and retention and like up-leveling or growth, I think a lot of it was just learning to let go and listen to the folks who reported up to me of like I can try and uh 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 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.

It's like there are things that aren't, they're not metrics, they're not meeting.

There's qualitative data that's much more important and much more meaningful.

And yeah.

Exactly.

Good.

Well, I thought we

were just trying to.

Because I know from the outside, it's like, oh, you launched it um what, 2016, 2018, and you 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 don't know, year or two?

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 of 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 we call it automations, which are the the equivalent of like drip sequences or lifecycle 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, uh, okay, they signed up on a Monday, we'll send them an email on a 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 of 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 gonna 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.

One of the I think breakthroughs that that led to it shipping 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 webhooks 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 backend 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 gonna graft on another big piece of the code base that has a totally different way of looking at the world.

So that's much safer than you know, writing something fresh and hoping it works.

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.

I I'm thankful to have like a couple friends and and former coworkers 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, 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 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 can think best when I'm writing, and so I've found a huge amount of value in doing that.

Uh, but it 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 a 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.

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.

What Carlton here has worked a lot on Django's async.

So I'm curious what what do you like and not like about how Django is doing things these days, right?

Because I'm sure you're you're kind of pushing the boundaries of async within Django.

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 uh, if you're unfamiliar or listeners are unfamiliar, RQ is like a task queuing library similar to Celery and all of those.

Um, 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 async 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 an 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 the best feedback I could 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.

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 a bit of async.

Yeah, like and then there's the difference between, as you said, just throwing something off to a queue where like that can go happen anytime, and then these sort of more async-y, I'm gonna fetch a couple of APIs and merge them together.

I've been bombarding.

So it's it's quite like brave to go into that marketplace and say, right, I'm gonna 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 gonna do this.

Like you're gonna have hundreds upon hundreds of competitors.

Say that again.

They're they're big, they've got resources.

Yeah, you know.

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 I should uh preface all of this with like, I am not some sort of business genius who's like, ah, I've I identified this little niche in the market that I'm gonna 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 it 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 emotes associated with it.

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.

And 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 really, really valuable.

The other thing, too, is button-down, I don't think, is ever gonna 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 gonna 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.

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

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

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.

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

Because we had Michael Kennedy on um from TalkPython 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 quids 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 seems very reasonable.

Button down is very reasonable to begin, like that's another point.

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.

Like we're we're hitting a even further downstream service like Postmark or Mailgun or one of those.

Um, 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 of 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.

So and so what rough triangulation can I hit so that no one, like, I'm not uh undercutting everyone, but I'm 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 gonna be more premium than whoever.

I wanted it 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, and I think this is a bit of a cliche, but it's 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 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 like kind of bad at that to the extent that I've modified prices, I think, twice total since launching six years ago, um, largely because just the unit economics of like 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 it's slightly different if you're not in a super 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.

So just to pick up pick out the one thing you said, a lot of it is about the a lot of 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.

Yeah.

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

Like you you pay the equivalent of like a fraction of a fraction of a penny per email sent.

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

Good.

Clavio is uh just went just IPO'd, and they're also Django based, I think at like eight billion dollars or something.

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

Like, right?

Like I see now every e-commerce firm.

Are the what are the buckets of email, right?

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

Is there are there others or are those are there's transactional, I guess?

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

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

Um, and transactional emails are usually broken out by a lot of ESPs, is like this is gonna be very high volume, very high, like open rates, it's always gonna 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 uh 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 uh 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 reified 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 gonna be so heavily penalized by by the email overlords that it's it's really unsustainable, um, which is a great development.

And then the more e-commerce-oriented, I think the the current term de 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 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 uh Cleveo.

I I I never know how to pronounce them correctly, or MailChamp, or uh folks uh 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 you're a Fortune 500 company, you're a massive retailer, like you're spending you know 50 million dollars 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.

It's a little bit like bootcamp, I would say, in that they've explicitly said they don't want one a couple big enterprise customers because so many services, it is does weight.

I mean, what was it?

Um 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 you're kind of more stay uh more stable in the long run, I would think.

Maybe maybe exactly maybe make less money, maybe, but you're also you know, even out a lot of churn that the 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.

And 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, uh, more SMB or more you know creator economy type folks is like we don't include all this stuff that the really big players do of like A B testing across multiple campaigns and all 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 books 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 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.

Because you that must be a good gut check when you know at what point do you let, you know, sort of like you're 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 be the case.

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 network tab for button down and just like look at all of the requests, we're hitting the external facing API.

Like 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 make it very clear that there's never gonna 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 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 gonna 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.

I think that's yeah, very wise.

Um I guess this is again philosophical.

Like, uh, how do you main your in maintain your interest?

Because you've written about this, and I I would agree, like, especially for a founder-led indie thing, in some ways that's the biggest risk, right?

Like you prove traction.

Um what and I know you know you have third South Capital and some other things, but like what is it for you that keeps you interested day to day?

But one of the things that is really, really fun and really rewarding about having a company that's at like 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 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 interests.

The 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 Bundone, 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 gonna ship it and just see what happens.

Often that's the stuff that resonates most with users or is most successful because it's it's not necessarily obvious, but being able to say, like, I'm gonna 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.

I think that's a good frame for it.

And it you what's the what does it take?

Well, it does, I don't know, it tastes a button down.

That's it's that's what gives it its character.

That's all I love that.

You've talked about the the API and then the just the SPA 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 to take it and perhaps describe what what your 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 HTMXs 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?

And I'm using View, technically, not React, but in my mind, okay.

They're both they're they're both of a piece.

Like they have different philosophies in 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 View and Alpine and HTMX, they're all great tools depending on what job you're trying to accomplish.

I think for the the median person starting a SaaS in 2024, you probably don't need to start with like React or View or something that's 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 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 that people need to adopt more of as opposed to like, well, this is the state of the arts in 2024.

You either have to go this way or you have to go this way.

I think you you sort of asked about like the the front end like churn and 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 gonna am I getting like blog posts?

This is now in beta from like the team that built it out.

Uh 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 where to future proof myself?

One of the things I 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.

The uh one of the engineers who was early at Etsy had like this great blog post that was very influential on me around spending innovation tokens of like you as an org or you as a company, like 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.

You can come on again, Justin.

That's uh

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

Well, one final question is what we always end with, which is if we have a magic wand and you can change something in Django, what what leaps to mind?

Like no restrictions, just what would you do?

Um and I I cheated a little bit because I I know y'all talked, I think maybe it was last week, about the 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 auth of uh and this is kind of like a blessing and a curse.

There are there's a number of third-party packages that I basically consider for my purposes core Django.

Uh, one of them is all auth because like the the all-auth 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, and 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 it 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's covered in the red map, admin is an incredible tool.

I uh when I was spinning 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 of 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 the other would be the escape hatches that admin affords you is like very limited.

Of you could get 98% of what you want for free, but then if you need to build out like a custom view that has state or like 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.

I think it's time for that battery to be modernized, and we'll I think we'll get there.

There's lots of threads going about pass keys and you know, Web Auth N and those things.

So I think things are going to happen there as well.

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

You can drop in an arbitrary inline or drop in an arbitrary widget.

Being able to have, and maybe there are 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 is like kind of hard to navigate, and so just some easier escape hatches there would be great.

So, no, totally that's not written.

That would be a good magic one wave.

I I would say like the I get a lot of questions from folks outside the the Django ecosystem because I I think at this point, especially in like the SAS or 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 or chatting with just anyone, they're like, Why 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 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 that 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 delivering value, but just doing table stake stuff.

But even now, like uh there's no way we would be able to iterate on features and build an 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 you can almost take for granted when you're sitting within Django 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 the Django thing.

So I'm tremendously grateful uh for everything that uh the maintainers and the original sponsors and everyone involved in the Django ecosystem has contributed over however many years it's been at this point.

It is uh it is something that I owe my businesses success to.

Okay, super.

Um I it's a wonderful service.

It's so great to hear someone using Django from scratch.

And um yeah, these are the podcasts I like best, someone who who can talk through like that journey.

And you know, you haven't uh left the Django Nest yet, and maybe you never will.

So that's always nice to hear.

Like uh and again, this is 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 of itself.

But thank you two so much for having me.

It was a great one.

No, thanks for coming on.

Well, thank you everyone for listening.

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

Bye bye bye this episode is sponsored by Mailtrap, an email delivery platform that developers love.

Try for free at mailtrap.io