Justin is the founder of Buttondown, a newsletter service built with Django. We discuss scaling the code and the team behind the project, the email space in general, new developments in web development, and Django features he’d like to see.
Will Vincent 0:00
This episode is sponsored by mail trap, an email delivery platform the developers love try for free at mail trap.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.
Carlton Gibson 0:18
Hello Will
Will Vincent 0:20
And we're very pleased to welcome Justin Duke from button down. Welcome Justin. Welcome Justin. Thank
Justin Duke 0:23
you both for having me. I'm excited.
Carlton Gibson 0:25
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.
Justin Duke 0:35
So button down is a email tool similar to, say, MailChimp or tiny letter substack, the rich ecosystem of ways you can just blast out emails to 1000s of subscribers, 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 back end, how We send our emails. How people view those emails? All that is running through Django and running through Python,
Carlton Gibson 1:05
there you are. So I just
Will Vincent 1:06
have to jump into it. A recurring theme on the 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, you know, maybe the grass is greener over there, you
Justin Duke 1:19
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, 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 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 I haven't really fantasized about. Like, oh, let's just take this little subsystem and rewrite it in go or rust like that. Would have to be motivated by something other than pure performance. Seems a very mature outlook.
Will Vincent 2:39
Well, can I ask how many, how many, how many people are working on button down now, because I know you have some support staff. Is it just you and engineering or what? What's the team size
Justin Duke 2:47
right now? We're around five to six folks who are working roughly full time hours, and then a a legion of very lovely contractors doing stuff like support documentation and writing that sort of thing. Like, the goal has always been, keep it really tight knit and keep it really, I guess, 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 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 level of velocity and focus that you get out of that is really, really rewarding. Okay, I
Carlton Gibson 3:39
want to jump in there, because I'm, 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 HTML 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. 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, 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,
Justin Duke 4:20
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 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. 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 be,
Carlton Gibson 5:38
yeah, brilliant, brilliant. And then that begs the question, which bits are you starting to think? Well, yeah, we might need to replace that bit. We might need to roll around our own there,
Justin Duke 5:49
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. 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 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 SBA, and all 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.
Carlton Gibson 7:43
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. We'll go all the way there.
Will Vincent 7:53
Yeah, no. Well, 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 William and Mary computer science. I was in Yates too, by the way, back in 10 years before you, I think.
Justin Duke 8:08
And I had no idea you were also a William and Mary grad. That is a small world of deep, yeah,
Will Vincent 8:12
they just, 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, it was, yeah, I 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 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?
Justin Duke 9:00
Of course. And so as contacts 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 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 into CS. 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 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 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, just so I could learn from a larger culture of tech that wasn't purely government based. Yeah, that's
Will Vincent 11:08
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, a major, 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 gotta get off the east coast. I gotta 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.
Justin Duke 11:37
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, 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 have been in industry for decades at a time,
Will Vincent 12:06
and then you went after a number of years, you moved over to stripe. Is that correct? Yeah, okay,
Carlton Gibson 12:12
um, there must be a war story or two in there. Like, straight both those, both those companies, are quite high profile, really. No, no.
Justin Duke 12:19
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 the reason I originally joined is 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 recruiting than anything. Of 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, 100 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 you do that while still shipping product and, like, maintaining a culture and all of those things? So much of what I look back fondly about that time was just 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, I've chatted with, you know, at least half or two thirds of, like, the hundreds of people working here. So really, really fun, high velocity time, for better and for worse. Did you
Carlton Gibson 13:48
get the big corner office, like, on those? Oh, absolutely
Justin Duke 13:50
not. Yes. It was very open plan style, right? Like, 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 things of those things. So
Carlton Gibson 14:08
okay, I do have to ask her, How do you hire quality engineers quickly? Because that's the thing
Justin Duke 14:15
that is both the company line and I do honestly think is true is like, there's no real magic bullet. You just have to, like, spend a lot of time and spend a lot of effort, and if you try and like, 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, 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 strength, you know, 1000s and 1000s 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.
Carlton Gibson 15:37
Yeah, no, that's a good point, because I think people just make it up as they go along. Largely, 100%
Will Vincent 15:42
did, um, so I did an interview in the Kindle office as an MBA student in 2010 and at the time they had, they, I did the whole full day thing, we meet with like seven people and have lunch. And they had, like, was it the level raiser, basically, the person who's a jerk to you? Bar raiser, the bar raiser. Did they do that in the tech side as well? They
Justin Duke 15:59
did. I think it was, and again, 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 had, 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. But again, it's, I feel like we're gonna look back on how we do engineering, hiring and onboarding as an industry 100 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.
Carlton Gibson 17:00
Okay, I'm gonna ask one more question on that kind of thread there. 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 rigorous engineering practices in place, and I guess that's hiring practices as well.
Justin Duke 17:24
Absolutely, I think you can look at this from from a number of angles. Like, I'm the number one person to kind of bemoan and besper any kind of 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 these kind of uptime and reliability and security angles without sacrificing productivity? But, and I'm curious to get y'all 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
Carlton Gibson 19:06
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 where 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 auto space shuttle is a good example, right? That needs exactly, well,
Will Vincent 19:39
I know that we'll move on from stripe. But I just recently, I had some colleagues from a startup I worked at who moved to stripe. Pretty much all of them moved to stripe, actually. And I know I just was emailing one of my saw bug in the docs, and I was like, Oh, you, you moved to open API. And he was like, Yeah, well, you just, just do bugs at stripe. And Patrick's CC, the CEO is cc. Uh, 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
Justin Duke 20:21
absolutely and I think the 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 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 paradrop 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 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,
Will Vincent 21:47
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 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,
Justin Duke 22:13
it's definitely not. I think I learned so much from my first transition from being an IC to being an EM 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 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 speed of a feedback loop. Right of you have a bug report, 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, 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 managing other people or imagining 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 gonna 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. 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.
Carlton Gibson 25:22
There's lots of dopamine hits like that you get, oh yeah, fix that one. I fixed that one. I fixed 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 retentions gone up with employee turnovers down? Or do you have something like that that you can sort of say, oh, yeah, I did do well, I
Justin Duke 25:45
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 ENG 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 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 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 by 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, Okay, 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,
Carlton Gibson 27:27
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,
Justin Duke 27:38
exactly good.
Carlton Gibson 27:40
Oh, isn't this about stripe?
Will Vincent 27:45
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. 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 you've launched in the last year or two?
Justin Duke 28:02
Yeah, I think one of the the operating cadences that I've really loved is, like, 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 of those other things are really, really good, so that 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 biggest thing we launched last year, which is one of the really tricky things in this industry, is naming. So we call it automations, which are the equivalent of like drip sequences or lifecycle emails, or any of the things that 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 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 buttondown 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. Functionality as possible, not just from a user standpoint, but from an engineer working on the code base standpoint. And
Carlton Gibson 30:05
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,
Justin Duke 30:14
yeah. One of the, one of the, I think, breakthroughs 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 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
Carlton Gibson 31:27
it almost sounds as if it's like the 123, 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 writing something fresh and hoping it works exactly.
Will Vincent 31:40
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.
Justin Duke 31:55
That has definitely been, I think, the hardest part about shifting from working at a big company to working at, whether it's a solo sort of startup or a much smaller company, is 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 a couple minutes? I'm thankful to have, like, a couple friends and former coworkers who I can, at a high level, sort of talked 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, 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 going to 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
Will Vincent 33:43
episode is sponsored by mail trap, an email delivery platform that developers love, an email sending solution with industry best analytics, SMTP, an email API, SDKs for major programming languages and 24/7 human support try for free at mail trap.io, so I imagine you have a lot of async going on in your application, just because emails are like the poster child for async. What? Carlton here has worked a lot on Django 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 of async within Django.
Justin Duke 34:17
One of the things that I have enjoyed doing is just like sort of piecemeal migrations in 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 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. 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 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, there was a lot of hysteria and a lot of like, confusion around what the migration path looked like 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 asyncawait and figuring out how to do polyfills and all that stuff, honestly, the 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 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
Carlton Gibson 36:18
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 a bit of async, yeah. And then there's the difference between, as you said, just throwing something off to a queue, whereas, like that can happen anytime, in any sort of more asyncy. I'm going to fetch a couple of APIs and merge them together. And exactly,
Will Vincent 36:41
Carlton, you ask a question I've been bombarding
Carlton Gibson 36:43
for Justin, well, okay, but I want to ask about the business side of email, because, like, there's, it's quite a crowded marketplace, right? So it's quite like brave to go into that marketplace and say, right, I'm going to do a new startup. And you know, you have a sort of market insight that led to say, right? I mean, actually, I'm going to do this. One of
Justin Duke 37:04
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
Carlton Gibson 37:17
they're not little. On the other side,
Justin Duke 37:19
say that again, they're
Carlton Gibson 37:20
not little competitors. They've got resources.
Justin Duke 37:24
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 preface all of this with, like, I am not some sort of business genius who's like, Oh, I've identified this, 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 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, 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, and that's not true of all industries, but at least within email, and I think 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 going to take over the industry, but if we can be the best product for point 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
Carlton Gibson 40:01
so the sort of, hey, you can write your emails in Markdown, and they just sort of go, that's a nice, specific niche.
Justin Duke 40:08
I've talked a lot about markdown being like, kind of a weasel. 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 buttondown splash page, see a reference to like Markdown and HTML, and they run fleeing for the hills and like, that's kind of fun, because those people are probably not great customers for me anyway. But the other side of that is if you go to buttondown dot 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,
Carlton Gibson 40:45
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 your 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 he's moved to self hosting email because of the costs that you 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 seems very reason. Button down is very reasonable to begin like, that's
Justin Duke 41:21
another I liked. I liked the footnote there.
Carlton Gibson 41:24
Yeah. No, 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. It'd be nice to get your view from the inside. Of
Justin Duke 41:37
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 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. 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 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 want 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 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, 1000 emails a day, things along those lines. And 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 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, since launching six years ago, 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 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.
Carlton Gibson 44:44
Okay, interesting. So just to pick up, pick out, 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. That's exactly,
Justin Duke 44:58
yeah, I. The fun fact is, button down, 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 pay the equivalent of, like, a fraction of a fraction of a penny per email sent exactly when you're sending, like, millions of emails a day. Like that little, that little fraction of a cent adds up quickly.
Carlton Gibson 45:23
Okay, interesting, good. So I'm
Will Vincent 45:25
based in Boston, and maybe I'm saying around Klaviyo is just went, just iPod, 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, like, right? Like I see now every e commerce firm are, what are the buckets of email right there? There is what you're doing, like newsletters, there's e commerce. Is there? Are there others? Or are those, those transactional, I guess, like, what are those layers abstracted above just sending, sending straight emails?
Justin Duke 45:53
Yeah, I think the 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 Coveo. 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.
Carlton Gibson 48:19
And at that point, if you're a small developer or small company with running a Django app, you've got no business using them anyway, really,
Justin Duke 48:28
exactly, yeah,
Will Vincent 48:30
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 one, a couple big enterprise customers, because so many services it is does weight. I mean, what was it slack? When slack iPod, 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, you're kind of more state, 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 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,
Justin Duke 49:12
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 this stuff that the really big players do, of like AB 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. Be 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, more heavy customers.
Will Vincent 50:33
I imagine, though, that for you, you must have some some whales, and there 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 there must. Is there an equivalent for you? Or how do you think about that? Because I would imagine that be the case. Philosophically,
Justin Duke 50:58
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 buttondowns 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 buttondown, and just like look at all of the requests, we're hitting the external facing API, like the buttondown front end, the SBA 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. I try and make sure they have the building blocks within the API. But also 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 going to be any sort of, like, one off feature implementation if we ever build something within buttondown 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, 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 two 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 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.
Carlton Gibson 53:12
Yeah, I love that philosophy. I think that's, yeah, very wise.
Will Vincent 53:17
Well, I have one more, and then I'll turn it over to Carlton. I guess this is, again, philosophical. Like, how do you mean you're in maintain your interest? Because that you've written about this, and I would agree, like, especially for a founder led indie thing, in some ways, that's the biggest risk, right? Like, you've proved traction. 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.
Justin Duke 53:42
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 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 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 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 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. It's 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,
Carlton Gibson 56:17
but those are the things that that have the flavor, right? What's the what does it take? Well, it does, I don't know, it takes a button down. That's, it's, that's what gives it its character. That's all.
Justin Duke 56:28
I love that.
Carlton Gibson 56:30
So okay, to change that quickly. You talked about the the API, and then just 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 to take it and perhaps describe what your stack is. But how do you feel about 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 ecosystem and world space,
Justin Duke 57:00
for sure, and I'm using view technically, not react, but 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 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 the median person starting a SAS in 2024 you probably don't need to start with, like, reactor view or something that's that's super heavyweight. You can start with no JavaScript at all, or using HTML, 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 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 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 team that built it out, 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 SPS 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 technology. Is the one of the engineers who's 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.
Carlton Gibson 1:00:19
Yeah, okay, you can come on again. Justin, that's that
Justin Duke 1:00:24
was the right answer.
Will Vincent 1:00:26
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 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?
Justin Duke 1:00:41
It's a great question, and I cheated a little bit, because I know you 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. I think the biggest one, the biggest single one would probably be off of 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. One of them is all off because, like the the all off abstraction. And I talked about how much I love Django is built in auth, but with the rise of things like two FA 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. I think the other one, and this is really selfish, and I also know it was covered in the red map admin is an incredible tool. I 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 this stuff for free, which is great, one of my pain points with admin. And 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, 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,
Carlton Gibson 1:02:34
yeah. So I'm all with you on the author. I think it's time for that battery to be modernized. And we'll I think we're getting there. There's lots of threads going there's about PASS keys and, you know, webauthn and those things. So I think things are going to happen there as well. Django wallauth has been given a grant to pursue working on things in this space as well. So that's an amazing thing 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
Justin Duke 1:03:03
mean, it's possible 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
Carlton Gibson 1:03:38
mean, it's possible, but it's not documented, and it's not officially supported, and you're into weird and wonderful things that you find on the internet to give you ideas. And no, that's not what, that's not the Jagger way. So no, totally that's not that would be a good magic one wave.
Will Vincent 1:03:55
Well, is there anything that we haven't asked you, or anything you want to call out as we close up? I
Justin Duke 1:04:00
think we touched it all. I would say, like, the I get a lot of questions from folks outside the Django ecosystem, because 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, 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'd been using it for years and years on end. But 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 Django offers you both in the early days, the stuff like, here are all these views, and here's the off model, and here's all this stuff for free 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 I. 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 of these things, are so tremendously useful tools that I think people 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 Django thing. So I'm tremendously grateful for everything that 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, it is something that I owe my businesses success to.
Carlton Gibson 1:05:49
Okay, super you can definitely come on again.
Will Vincent 1:05:56
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 who can talk through like that journey. And you know, you haven't left the Django nest yet, and maybe you never will, so that's always nice to hear. I
Justin Duke 1:06:15
would be, I would be shocked if, if we were ever unshipping Django like 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
Carlton Gibson 1:06:30
was a great no thanks for coming on. Really
Will Vincent 1:06:32
good fun. Well, thank you everyone for listening. We're djangochat.com and we'll see you next time bye bye. This episode is sponsored by mail trap, an email delivery platform that developers love. Try for free at mail trap.io, you.