Subscribe
Share
Share
Embed
Software engineering is getting weirder by the week. AI is reshaping how teams work, processes are breaking, and org tension is real - and the best lessons aren't coming from keynote stages or polished LinkedIn posts.
The Hallway Track is a podcast for engineering leaders who are building teams, navigating complexity, and looking for ideas that sound like the world they actually live in. Real stories from real teams. No recycled FAANG playbooks. Just honest conversations with the people in the trenches - about what's changing, what's breaking, and what's actually working today.
Hosted by Chris Vannoy, founder of Axiomatic Consulting and a 20-year veteran of software teams at startups, agencies, and B2B SaaS companies. New episodes every other week.
Connect with Chris: https://www.linkedin.com/in/cvannoy/
Learn more about Axiomatic: https://getaxiomatic.com/
[00:00:00] Benedikt Deicke: Focus is super important, especially talking about like bigger project and bigger features, we will say no to a lot of things while we work on those. And we put a lot of time and energy and care into building it the right way because we know Like, whatever we build today is the basis for what we're going to build tomorrow.
[00:00:24] Chris Vannoy: Hi, I'm Chris Vannoy, and this is The Hallway Track. My guest today is Benedikt Deicke, Technical Co-Founder of Userlist, an email marketing automation platform for softwares and service companies. Newsletters, lifecycle messaging, transactional email, all of it built and run by an engineering team of three.
[00:00:44] Chris Vannoy: Benedikt and his co-founder pre-sold Userlist off a single-page website before they built so much as a login screen. Then they spent years running sales demos that were really customer interviews in disguise. Nine years later, they've never needed a big rewrite. We get into how the way a company makes its money shapes the software it builds, why Userlist is perfectly happy on Ember, and why not every background job needs to be fast.
[00:01:09] Chris Vannoy: And for once, we barely mention AI at all. If you're running a small team across a big surface area and you've ever wondered whether you're building for your customers or your next funding round, this one's for you.
[00:01:21] Chris Vannoy: Howdy, folks. my guest today, this is morning for me when we're recording this, but it's afternoon for him, because my guest today is Benedikt Deicke.
[00:01:29] Chris Vannoy: he leads engineering at, uh, Userlist. Benedikt, why don't you run the people through, like who you are, what you do, and what Userlist does a little bit?
[00:01:37] Benedikt Deicke: Sure. Well, first of all, thanks for having me on the show. happy to be here and talk to you about, uh, interesting stuff hopefully. So, uh, my name is Benedikt. I'm the Technical Co-Founder of Userlist. I've been a software, like full stack software engineer for about 20-plus years now. It's hard to draw the line of where it became professional
[00:01:57] Benedikt Deicke: after like doing it as a hobby and eventually, I don't know, it turned into a job.
[00:02:02] Benedikt Deicke: And as you said, I'm based in, uh, in Germany near Frankfurt, the company I work at full-time, I co-founded with my, co-founder Jane in 2017. We incorporated in 2018, launched in 2019, and, full-time on it since 2020, so it's been a little bit of a journey. Userlist is an email marketing, uh, automation platform for software as a service applications.
[00:02:26] Benedikt Deicke: So we basically provide everything you'd need from, newsletters, lead magnet, automations, life cycle messaging, transactional emails, anything messaging related that, that might be, uh, useful in your SaaS products. maybe for the technical audience, it's a Rails application. Fronted as an Ember.js.
[00:02:47] Benedikt Deicke: It's on PostgreSQL, and there's a lot of Sidekiq in there, so a lot of the stuff runs in the background. So sometimes I joke it's more of a Sidekiq application than it's a Rails application.
[00:02:58] Chris Vannoy: I've worked in a similar space in a lot of my career. I spent like five years doing marketing technology stuff. So I was at a company called Sigzer where we were doing, email signature marketing. So
[00:03:09] Benedikt Deicke: That used to be a thing for a while,
[00:03:11] Chris Vannoy: Yeah, it was.
[00:03:12] Chris Vannoy: Um, it was very fun. It's actually a lot of fun data to play around with that. but then also did some work at a account-based marketing company. So I'm, I'm really familiar with like the space Userlist is playing in, and we'll probably talk more about that a little bit later. as far as engineering goes, how many folks are you, at this point?
[00:03:29] Chris Vannoy: what has sort of the growth of that been?
[00:03:32] Benedikt Deicke: we're a super small company when it comes to, team size. We're just a team of five. Like it's the two founders. We have one front-end engineer, one customer support engineer, and a marketing manager. we handle day-to-day business like that. the engineering side is basically just the team of three.
[00:03:48] Benedikt Deicke: me leading this and my co-founder is mostly doing, uh, sales and marketing these days
[00:03:53] Chris Vannoy: but for the, the space you're in, like specifically the, like send email newsletters and I think y'all do, like pretty much any time you need to send an email, it can go through Userlist.
[00:04:03] Chris Vannoy: So that's a pretty wide surface area for just three people.
[00:04:06] Chris Vannoy: Like, how do you manage the team such that, like, you can cover that much ground with that small of a team?
[00:04:13] Benedikt Deicke: well, for one, we started in 2017, so it's coming up on nine years, so it's been a lot of time to just add a thing there and add a thing there and add a thing there. So when we started out, we didn't do most of the stuff that we're doing today. Like, we had a very, very narrow focus.
[00:04:30] Benedikt Deicke: stuff evolved from there, mostly around, based on feedback we got from customers, feedback we got from leads,
[00:04:36] Benedikt Deicke: that's basically the driver of our, product roadmap, I'd want to say.
[00:04:40] Chris Vannoy: that's interesting. Lots of times when I'm doing either consulting work or, like, companies I've worked with in the past, right, engineering can often be sort of disconnected from the customer, right? You have some product person somewhere that's, like, talking to a customer sometimes, if you're lucky.
[00:04:55] Chris Vannoy: and then they'll write requirements, and they drop 'em in a Jira somewhere, and then you as the engineering half of the problem will actually, like, look at what's in the description, and then you'll go build the thing, right? And you don't really get a good connection with the customer in the course of doing all that.
[00:05:08] Chris Vannoy: Obviously, like, with a smaller team, it's a little bit odd because you have, probably, I would imagine, greater access to the customer. There's not a lot of layers between you and the customer necessarily. But also because you've got a relatively small team, like, that's something you have to juggle alongside of actually doing work.
[00:05:26] Chris Vannoy: can you talk a little bit about, like, how Userlist, how engineering interfaces with customers? Like, you mentioned it influences the roadmap, but, like, how mechanically does that sort of work? even philosophically, like, what led you to this place, and has it always been this way?
[00:05:41] Benedikt Deicke: it has always been this way. I even wanna say it's probably less, this way these days than it was in the early days, because in the early days, I mean, we were an even smaller team. We started, uh, with three co-founders, when we started we didn't build anything before we did, uh, some customer interviews.
[00:05:57] Benedikt Deicke: from past experience with working on other software products, we had some rough idea of what we wanted to build and what the problems might be. But before we did anything, we, did a round of customer interviews with people who we thought might need this or have similar problems and just validated that this is actually the right direction to go into.
[00:06:15] Benedikt Deicke: Because even at the time, there were other solutions out there that you could use to do this, but none of them felt like a really good fit for the SaaS use case. So we started there and then, those early conversations informed the vision or like the roadmap. And, uh, based on that vision, we then did a pre-sale.
[00:06:37] Benedikt Deicke: Like before we even started writing code, we started selling the product just to see like, sure we know this, those are the feedback we got, like those are the problems, this is what we imagine a solution should look like, but does that actually entice people to buy? I remember like back then we had a lofty goal of like 10 pre-sale customers.
[00:06:57] Benedikt Deicke: We got in the end, we got like five.
[00:06:59] Benedikt Deicke: we felt like it was enough validation to start building I mean, these days MVP is like frowned upon a little bit, but I feel like it's still a good concept because it's minimum, it's viable, which is the important part. And I guess the problem is that viable evolved over time the minimum viable product and we launched that to early access customers and then just continued building from there based on feedback we got from the customers and feedback we got from potential leads.
[00:07:28] Chris Vannoy: going back to that early sort of stage, right? That requires a tremendous amount of discipline, like, to not go build stuff. especially, like, we're software engineers. the urge to like, "Oh, that's a great idea.
[00:07:39] Chris Vannoy: I'll just go build it," right? you weren't actually launching it until you had five people, but, like, were you actually building it, like, along the way? Or were you just like, "Doo, doo, doo, doo, doo. Like, I could just wait."
[00:07:49] Benedikt Deicke: I don't remember exactly, but I wanna say that we only really started building it afterwards. I think there were some research and like experimentations and prototyping,
[00:08:04] Benedikt Deicke: but as far as I remember, we really only got serious at, with building it after the pre-sale.
[00:08:09] Benedikt Deicke: it was more like build out the vision then validate the vision internally of like, can we actually do this?
[00:08:15] Benedikt Deicke: Like, or how would we approach this? I'm sure there wasn't anything other than a couple of Ruby files that
[00:08:21] Benedikt Deicke: would do some automations and stuff like that. No UI, no login, no nothing. And we only built that stuff afterwards, after we had the pre-sales.
[00:08:29] Chris Vannoy: you're also right that like the age we're in now, like the floor for what an MVP is, right? 'Cause what you were probably selling back then was probably like a mock-up, or a slide deck or something like that, that's like, "This is the thing we're intending to go build," right?
[00:08:44] Chris Vannoy: And now I think the amount of time it takes you to build the mock-up and slide deck, you could have a like functioning prototype almost, right, of a lot of stuff.
[00:08:54] Chris Vannoy: depends on the app, right? Your app in specific, probably not, because you've got a lot of like wiring and plumbing.
[00:09:00] Chris Vannoy: Again, I'm a little familiar with this world. Like there's a lot of ins and outs and what-have-yous that you have to actually connect together to be able to do all the email
[00:09:08] Chris Vannoy: sending stuff.
[00:09:09] Benedikt Deicke: also want to point out is like we're dealing with our customers' data and we're sending our customers' customers emails. Like
[00:09:15] Benedikt Deicke: there's like the viable is a, is a pretty high bar.
[00:09:20] Chris Vannoy: Well, it's the, the downside risk, right? Like, it's the style of business you ended up picking because you are dealing with, like, customer data. the downside risk of making a mistake is relatively high, right? for some mistakes, like specifically like data security, like all that sort of stuff has to get very important.
[00:09:36] Chris Vannoy: And then again, from past experience, the email deliverability, you also probably have to have locked down pretty tight, to be able to make it all work. So that creates a higher bar for like where the minimum is. But for a lot of business ideas this time, you could throw it into Replit or something like that and get something, okay.
[00:09:55] Chris Vannoy: Especially for these like line of business applications and things like that,
[00:09:58] Benedikt Deicke: I think the problem with that is because it is so easy, the minimum also increased, right? Like, because if you can just write and wrap it and get something out in like an hour, that your customers can do that too. So why would they buy this, right? So I think it's just getting more complicated and more complicated.
[00:10:16] Chris Vannoy: I do think it is also different between if you're trying to get a fun-funding versus bootstrapping, right? I know in talking with, venture capital sort of circles here in Indianapolis, whereas where the refrain I hear over and over is that the bar for actually getting, like, initial funding keeps getting higher, right?
[00:10:35] Chris Vannoy: Because in the old days, you used to... Kinda like we were talking about selling to customers earlier, like, you could show up with a slide deck and a dream, right? And sort of an idea of how this works, and you might be able to get somebody to give you a check to actually go build the thing or something like that.
[00:10:48] Chris Vannoy: but at least at the funder level, if they're wanting to see a prototype, right? You've actually built something, right, at this point, and you actually have revenue coming in, and you have customers, and you... Essentially, what probably used to be, like, a Series A signal back in the day is now to get any funding at all.
[00:11:03] Chris Vannoy: You kind of
[00:11:04] Chris Vannoy: have to be at that
[00:11:04] Chris Vannoy: point. I think it's interesting for bootstrappers or folks with different business models, though, where, like, as a solo person, you can build something fairly impressive fairly quickly, right? Where you can then try and sell directly to customers for a while and sort of build it up that way, which is also interesting.
[00:11:23] Chris Vannoy: It's a flavor of what user list probably started off as, like, where you were mentioning, like, don't build anything until, like, we have five customers signed up for it, right? It's build ver-very little
[00:11:35] Chris Vannoy: until you get to that. It's essentially the new version of the slide deck you probably started off with.
[00:11:40] Chris Vannoy: I don't think there was even a slide deck. I think it was just a single-page website with text on it. I'm not even sure there were screenshots
[00:11:49] Chris Vannoy: That's also a good reminder, though. Like I mentioned, I play a little bit in, like, the venture capital sort of circles, and that's on both sides, both the people who write the checks and the people seeking the checks lots of times. And lots of times, the folks who are trying to create their own business, what I'm walking them through is, like, do less.
[00:12:05] Chris Vannoy: you don't need to go hire a developer right now. you just need a, a Google form, and, like, it's fine. Like, have people go sign it up or throw something together in Lovable and throw it up on the internet and, like, just see if anybody signs up, right? Try and
[00:12:17] Chris Vannoy: get people to sign up. these days, though, how do you still stay connected to customer?
[00:12:22] Chris Vannoy: Like, you mentioned both customers and prospects are your gathering feedback from. how direct is that? What mechanisms do you have to have engineering actually get that feedback directly from a customer or prospect?
[00:12:34] Benedikt Deicke: it has evolved a little bit. Like as I said, like to this day, we have a, hybrid sales approach to, to sell Userlist. so we do both offer self-serve sign up where you can just like click on sign up, enter your details, get started by yourself, and the other way is like go through a sales process with us.
[00:12:52] Benedikt Deicke: So you can book a demo with us. And especially in the early days, I wanna say the earliest five years, something like that, six years, those demo calls were basically covert customer interviews. so instead of just like jumping right in and showing the product and, trying to get the sale, we would spend, I wanna say, at least half, maybe two-thirds of the call just understanding the problems of the customer.
[00:13:15] Benedikt Deicke: , What's the challenges you're facing, what doesn't work in your current setup, and stuff like that. And a lot of times, once we've done this a couple of times, you'd see some patterns, right? Like the same stuff would pop up over and over again.
[00:13:27] Benedikt Deicke: that would inform what we'd focus on next. in the very early days, we didn't keep a roadmap. We didn't keep a list of features. Or actually, in the very early days we had that, but eventually we decided, ah, whatever,
[00:13:40] Benedikt Deicke: just throw it
[00:13:40] Benedikt Deicke: all away.
[00:13:41] Benedikt Deicke: because the important stuff just kept coming up over and over again.
[00:13:46] Benedikt Deicke: so it was easy that way. later on we transitioned into still doing that, but also doing customer interviews, like dedicated customer interviews with our existing customers, just to learn like from their experience, what's still lacking in the product, what would they like to do more. that's basically how we added all of those different ways to message people over time.
[00:14:09] Benedikt Deicke: Because in the early days, we're basically a lifecycle messaging tool for post-sign up communication, but eventually we added like marketing emails, sign up forms, stuff like that. And recently, well, almost a year ago, we added an API endpoint for transactional messages and allowing people to consolidate and, uh, use Userlist for more.
[00:14:29] Benedikt Deicke: And those learnings basically came from interviewing customers and figuring out what else we could do
[00:14:35] Benedikt Deicke: for them
[00:14:36] Chris Vannoy: And how involved is engineering with those customer interviews? Like, are you on the call?
[00:14:40] Benedikt Deicke: In the very early days, I was even doing the sales demos. we were basically splitting this in half. And that's why I said, like, it evolved a little bit and we're maybe doing less than that. These days I'm not on the sales calls anymore. It's my co-founder doing these. And we also shortened them so they are more sales-driven by now.
[00:15:01] Benedikt Deicke: Because sometimes in the last, I don't want to say, like 24 months or so, we started noticing that there are no clear winners anymore in terms of like stuff that comes up regularly, which we still have not quite decided what we make of that. But I, I think one signal is that the product is mature enough that the, the majority of things it needs to do are taken care of.
[00:15:27] Benedikt Deicke: in the early days, I was super involved with this talking to the customers directly. these days it's mostly my co-founder doing these, but we also, we always get like, summaries from her we also do, uh, like screen recordings and transcriptions for those calls.
[00:15:40] Benedikt Deicke: And so these days if there's an interesting thing coming up, I'll go in there and look at the, look at the recording, figure out what part of the conversation was talking about a specific thing, and then re-listening to it. And then if we need to, we will just re-engage with that customer or that lead and learn more and, get their feedback and stuff like that.
[00:16:02] Benedikt Deicke: So in a way, at least me as an engineering leader of sorts, I'm still deeply connected to this. As well as customer support, I'm also leading the customer support effort, so when stuff comes up in customer support, I'm not the first person to read it, but probably the second.
[00:16:18] Chris Vannoy: that's one of the key things, like, even at larger companies, right? Like I kind of hinted at earlier, software engineering can get disconnected from the user, right? From the customers actually using the thing. one of the techniques I used lots of times was like when I was leading an engineering team of, I had like, I don't know, between 8 and 12, something like that,
[00:16:35] Chris Vannoy: And what I would say is like, we'd have like a goal set for everybody that they're on one customer support or prospect call a month,
[00:16:42] Chris Vannoy: or a week. the way I would put it to them is like, "You don't have to turn your camera on. You don't have to say anything.
[00:16:47] Chris Vannoy: Just show up, do your regular work, be on mute. It's fine." because I want them to like sort of soak in to like who's actually using the product so that they can connect to that. the other benefit I got lots of times is like they'll hear them fumble around with something in the UI
[00:17:03] Chris Vannoy: And so then I get some ticket the next day that fixes whatever little nuisance or problem they happened to discover. and it worked really, really well. it's interesting. It's why I was excited to talk to you generally is like lots of times when I talk to software engineering folks and leaders and stuff like that, like what I just described seems very weird, right?
[00:17:23] Chris Vannoy: It's like, " What? I'm gonna take time out of my day for a meeting?" Right? But it's like what you've built at Userlist feels like it's heavily influenced by working almost directly with customers and prospects to build what it is that they need. And it feels like you're finding a way to continue to do that even as the platform has sort of grown over time, and the team has grown at least a little bit, since then.
[00:17:44] Benedikt Deicke: Yeah, that's at least what we're trying to do, and I think it always sounds like so grand and everything, but like, I feel like it's part of our culture of sorts, right? Like, I think everyone on the team knows that we're not building this for the sake of building it, but like to solve an actual problem that someone's actually willing to pay for.
[00:18:01] Benedikt Deicke: by being a small team, I think everyone is acutely aware of the fact that it needs to be useful and needs to help our customers. that makes it easier, I guess.
[00:18:11] Chris Vannoy: So is Userlist still bootstrapped or are y'all taking funding at this point?
[00:18:15] Benedikt Deicke: we started out bootstrapped, but we got a little bit of funding in 2020, which allowed us to go full-time. Before that, we were basically doing this as an ambitious side project, so at that time, the two of us were freelancing on the side to pay the bills and, doing part-time work on the product.
[00:18:32] Benedikt Deicke: And then we got a little bit of funding, a tiny seed round, like a super small seed round, which allowed us to go full-time for an entire year and have some extra money left that we could invest on other stuff. And, unfortunately, we didn't grow quite as much to sustain us afterwards, so we raised another little friends and family, a round after that.
[00:18:53] Benedikt Deicke: But after... Since then, we've been able to hire. That was, good with the second round. so we built a team because after, what was it, four years of building this, I think we were all pretty burned out. and then building the team, like, getting the money helped us build a team, which then, made it less stressful and more sustainable.
[00:19:13] Benedikt Deicke: And, we've been riding on that ever since. these days we are somewhat profitable, and can sustain ourselves.
[00:19:19] Chris Vannoy: the burnout one is an interesting sort of thing, right? It's, in my own career oftentimes, like I would work in cycles of it takes like a year and a half to get bored,
[00:19:29] Chris Vannoy: And I imagine in that sort of environment where you've got like two people building a thing and like you're working on this thing and you're also hustling to do freelancing on the side, like that has to be very draining at the end of that.
[00:19:43] Benedikt Deicke: I think it only got really draining after we got into this full-time. before that the stress level wasn't as high because you knew, it doesn't have to be successful necessarily or, like, It was okay to not be super successful because the money was still coming from elsewhere.
[00:19:59] Benedikt Deicke: but once this was our only income stream, the
[00:20:03] Benedikt Deicke: pressure is on, right? Like,
[00:20:04] Benedikt Deicke: you have to make this work. You don't necessarily wanna go back to the freelancing and, like, make it back to being a side project, especially we grew the product, right? Like, we had more customers.
[00:20:14] Benedikt Deicke: There was more stuff happening. We had to do customer support. Like, well, I had to do customer support for the most part because it's a super technical product. Like, my co-founder's amazing, but, like, when it comes down to the nitty-gritty of, like, how to set up a specific automation, I was the one debugging this.
[00:20:31] Benedikt Deicke: And that would take me out of product development and would take me out of thinking about the next feature. And at some point, just dealing with all of that, just too much and too draining. And with it being not successful enough to pay us well, That is not a good combination.
[00:20:48] Chris Vannoy: I feel a little bit of that stress even on my end. Like, I, like outside of podcast, I have a consulting company that's just a one-person thing, right? I started because I got laid off, from a software startup, right? And it's been very much like just, you know, keep making payroll month after month after month.
[00:21:04] Chris Vannoy: Let's try and stitch stuff together. And like, those ups and downs when it is like you're building your own thing one way or the other. yeah, it does get very stressful.
[00:21:13] Chris Vannoy: like when you're building something, at least has been my experience, right? There's a universe of things I could possibly do, right? But I don't know which one of these is the right thing to do that will actually move this forward And I imagine building product, in this case, like I'm supporting one person doing a consulting company.
[00:21:29] Chris Vannoy: When you're building product, it's probably even more so true, where you've got a million possibilities of things you could go build, and probably a huge backlog of like all the stuff you know is kind of broken or slightly wrong or needs addressing. how do you prioritize all that work when you're such a small team?
[00:21:46] Chris Vannoy: Like, is it all customer-driven, or do you have some other way of prioritizing all that work, or did you back in the day, I suppose?
[00:21:54] Benedikt Deicke: It's basically exactly this because the, talking to the customers it makes it obvious what you should spend your time on, right? Like if you're losing customers or like even not necessarily customers, if you're losing leads because you don't have feature X, you better
[00:22:09] Benedikt Deicke: build feature X, if they don't sign up because of feature then you better build feature Z. And that doesn't mean that you have to build every single customer ever requests, but like, especially if you see patterns, it's always the same thing.
[00:22:23] Benedikt Deicke: Of course, you prioritize that and work on that.
[00:22:25] Benedikt Deicke: So, that's why we're doing this, to, to even know what we should be prioritizing, right? sometimes we build a quick thing because someone asks for it. Like if it makes sense and moves the product forward or like we have like a backlog of a million things we wanna do, and sometimes we have it that a lead or a customer's like, can it do this?"
[00:22:45] Benedikt Deicke: And we're like, "No, but we've been thinking about this for a while. We know this is a good idea." Good thing someone finally asked for
[00:22:51] Benedikt Deicke: it because we can now just like spend a week or month to actually ship it. so we do that from time to time as well.
[00:22:58] Chris Vannoy: I would actually use that sometimes for bugs, because like I'd been working at this app for long enough that like I knew all the bugs, right? I knew all the broken stuff. I knew the entire codebase backwards and forwards and that sort of thing. And so I would stumble on bugs occasionally, like stuff that isn't working, right?
[00:23:14] Chris Vannoy: And I'd be like, "I'm gonna wait until somebody else points it out." Right?
[00:23:19] Chris Vannoy: And so then once a customer does, like I know exactly where it is and I know how to fix it and that sort of stuff. But like when we've got-- In that case, like I said, I had a team of like eight to 12, and so we built a lot of product.
[00:23:30] Chris Vannoy: and we would have things break here or there, right? That if-- might be in some corner of the app that some customer is actually using right now, right? So it's like, I know it's broken. I'm gonna just hold that until somebody stumbles on it. So like that customer feedback loop ends up being sort of the most important prioritization tool you can have,
[00:23:52] Chris Vannoy: the other signal that's interesting that I wanna pull out a little bit is the way a company is funded and/or the way the company culture is built also impacts and changes how engineering works, right?
[00:24:06] Chris Vannoy: the way Userlist primarily gets money, I imagine, is from customers, right? Customers are paying you, and that's the bulk. Like you've raised a couple of small rounds, but that's
[00:24:14] Benedikt Deicke: That money's gone.
[00:24:15] Chris Vannoy: Yeah, yeah. That's what the money's for. Like don't feel bad about it.
[00:24:20] Chris Vannoy: So the way it works is like customers are the funding source, right? That's where the money comes in and that sort of stuff. Oftentimes, this is much more difficult when you're at a, a fully venture capital company, right?
[00:24:31] Chris Vannoy: Like your, your money source is not necessarily customers. It is VCs writing you checks, right? And so a lot of what you end up building is not necessarily for customers. They are for how do I get the next check?
[00:24:46] Chris Vannoy: the other thing I would often ask folks when I was working at VC software firms, right?
[00:24:52] Chris Vannoy: Is like, how long does this need to live, right? Like, are we just going to sell this to some other company in two years from now, right? In which case it becomes their problem.
[00:25:03] Chris Vannoy: where I imagine for Userlist, like you're not having that conversation, right? You're building something that's already lasted 10 years almost, and is probably the plan is like keep going for as long as you can.
[00:25:14] Chris Vannoy: How does that influence and change how you make decisions technically?
[00:25:18] Benedikt Deicke: it very much influences how we build software earlier I listened to the conversation you had with John Nunemaker, and he was like, "I don't do focus anymore. I just do whatever I
[00:25:26] Benedikt Deicke: want." And I feel like, I can sort of relate to that, but for us, focus is super important, right?
[00:25:33] Benedikt Deicke: especially talking about like bigger, bigger project and bigger features, we will say no to a lot of things while we work on those. And I'm not sure, like, if that's to our detriment, but, like, we put a lot of time and energy and care into building it the right way because we know Like, whatever we build today is the basis for what we're going to build tomorrow. And especially if it's like stuff, like more fundamental stuff that will then power other things. We spend a lot of time trying to get this right and, sometimes it, it hinders us in, in shipping stuff quickly. But on the flip side, we did not have to do a big rewrite yet, and I'm not sure we will ever need to, right?
[00:26:15] Benedikt Deicke: we are rewriting parts of the application from time to time as it, as is necessary, but, like, the product is very solid at this point.
[00:26:23] Benedikt Deicke: by being a small team, by not having huge...
[00:26:26] Benedikt Deicke: a lot of money to throw at these things, we slow and steady, right? Like that's basically the mantra. Like
[00:26:32] Benedikt Deicke: we'd rather spend a little bit more time, but build a better solution that is, A, better for our customers and better for ourselves in terms of like having to deal with
[00:26:40] Benedikt Deicke: it long term.
[00:26:41] Chris Vannoy: The, rewrite one, I want to pull on that a little bit because way back at the beginning, you mentioned a particular technology choice, Ember, which can be a little bit difficult to hire for these days, right?
[00:26:52] Chris Vannoy: I've tried.
[00:26:53] Benedikt Deicke: We too, successfully.
[00:26:55] Chris Vannoy: yeah, yeah. Well, it's, it's one of those things where,
[00:26:58] Chris Vannoy: Sometimes I work with clients that would have like a, an Ember front end and like there's no one there that knows how to do Ember anymore. Or like they wanna hire more people, but they don't necessarily wanna train them on that.
[00:27:09] Chris Vannoy: for the style of company you are, right, you're not gonna go and hire like 50 engineers tomorrow, right? Like, you don't have to go hire commodity talent necessarily, right? so the style of company means you don't have to rewrite that.
[00:27:23] Chris Vannoy: You have folks on the team who already know Ember, right? And you have a working environment where you could probably find another one if you needed to, right? But you don't necessarily need to,
[00:27:33] Benedikt Deicke: yeah, exactly. it's less of a concern for us ... Because we're good with like just one or two extra developers, right? Like, It wasn't that hard to find another good Ember
[00:27:41] Benedikt Deicke: developer.
[00:27:41] Chris Vannoy: Yeah, if you only need to find one, it's not hard, right? The problem is when you have to find 12, right?
[00:27:46] Benedikt Deicke: Yeah, that, that, that might be trickier. Yes
[00:27:49] Chris Vannoy: It goes back to that sort of like the business you're in changes the architectural decisions you're making in a lot of cases, right?
[00:27:56] Chris Vannoy: Lots of times, software decisions and architectural decisions reflect the business they're operating in, right? So oftentimes, front-end frameworks especially, in my mind, are solving business problems and not technical problems, they are things like how do we get as many undifferentiated software engineers for as cheaply as possible working on something?
[00:28:20] Chris Vannoy: And that is how you get things like microservices, because you can split up the work across a whole bunch of different things, and a whole bunch of different work streams, and as long as you have strong contracts between them, you don't actually have to have them talk to each other all that much.
[00:28:33] Chris Vannoy: So you can get a whole bunch of concurrent work done, going. I actually built a microservice one time specifically for that. I had a very short
[00:28:40] Chris Vannoy: deadline and I had a team of folks in India, at the time, and it's like, well, I can do with me like a list service and like all these little tiny things that I could hand to them and get them all stood up,
[00:28:51] Chris Vannoy: it's one of the interesting things the longer I've been doing this, is realizing that the business you're in ends up influencing pretty heavily the architectural decisions you're making, And in your case, like you mentioned a lot of it in Sidekiq, I imagine for the business you're running, the like retry ability why don't you tell me rather than guessing? Like what you mentioned, you have a bunch of stuff in Sidekiq. Why is that? What about the business means that you have to do a lot of stuff in background jobs for those who aren't aware of what Sidekiq is?
[00:29:21] Benedikt Deicke: Sidekiq is a, I wanna say one of the default background queuing systems for Rails. I mean, there's more these days, but,
[00:29:29] Benedikt Deicke: it's one of the big ones, right? I think it's just natural for a system like ours where we do like automation, right? That implies that no one's actually in front of their computer clicking on stuff.
[00:29:40] Benedikt Deicke: That stuff has to somehow work in the background. that's exactly why, why a lot of stuff just happens in, in those background services. Like data changes, we reevaluate stuff, we send out requests to webhook endpoints somewhere, we send emails, there's so much stuff happening at all times, happening in the background queue that it just makes sense to do it
[00:30:01] Benedikt Deicke: like this. Yeah.
[00:30:02] Chris Vannoy: how do you monitor Sidekiq? There's a whole class of errors that pop up occasionally where, like, some background queue gets hung up, right? Like some job that used to be really quick is now very slow, and now it's stacking up everything.
[00:30:14] Chris Vannoy: how do you monitor Sidekiq at this point? especially because, like, you're dealing with, like, email deliverability and automations that probably have to fire relatively quickly, right? So if something is lagging or a little bit slow, that's probably a problem.
[00:30:26] Chris Vannoy: So what tools are you using, or what approaches?
[00:30:29] Benedikt Deicke: I wanna push back on the it needs to be quick notion a little bit. Yes, it is true,for transactional messages, sure. But like for that educational newsletter you send every Monday, does it matter if it happens now or in five minutes? Probably not. So that's one thing.
[00:30:45] Benedikt Deicke: the other thing, if we talk about how we monitor this, we are big fans of AppSignal, which is like a monitoring tool. Initially for Rails only, I think. These days they do a lot of stuff. and we basically feed all of our metrics into, into that. that includes, performance metrics on a, job level, so we know what the average execution time for a certain type of job is.
[00:31:07] Benedikt Deicke: We can drill in and look at why it is slow. And the other thing we actually do alerting on is queue size and queue latency. So either there's a lot of work in the queue, that will trigger a notification and prompt me to look into it, or if stuff takes longer than we want it to take, right?
[00:31:26] Benedikt Deicke: Like there are certain things where I said like it's okay when it takes a couple of minutes. I think on one of the queues the limit is an hour or something like that, where we know it's going to be slow, but it's fine, like doesn't matter. But other stuff needs to be like within a minute or so. so when stuff happens and those metrics exceed certain thresholds, we get alerts, look into it, try to fix it.
[00:31:49] Benedikt Deicke: maybe on top of that, we also do-- heavily do auto-scaling on Sidekiq. So, we use a product called Judoscale It monitors the queue metrics and then fires up more workers, and more processes based on how much work there is.
[00:32:05] Benedikt Deicke: As one example, we have a queue just for message rendering, and by default that queue is just monitored by a,process that does a lot of stuff. Like message rendering, message delivery, reporting, I don't know.
[00:32:20] Benedikt Deicke: But if you send a broadcast to several thousand people, suddenly the queue will be full, the auto-scaling will kick in and just start a dedicated worker queue for that, and then have a massive fleet of processes just working on that queue to drain it as quickly as possible.
[00:32:38] Benedikt Deicke: But once that's done, we scale it back down because if no one's sending a huge broadcast, stuff just trickles out and the other stuff can just handle it.
[00:32:46] Chris Vannoy: just one quick note. this is again a point of like technology is a very small world. The last podcast I recorded was with Adam at Judoscale.
[00:32:54] Benedikt Deicke: Nice
[00:32:56] Chris Vannoy: it's been fun to find all the interconnective tissue between all the folks I'm talking to,
[00:33:00] Benedikt Deicke: you're making your way through the Ruby community, I feel like.
[00:33:04] Chris Vannoy: Like I hinted at, like I've been a Ruby dev for 20 years at this point. when I moved here to Indianapolis, I was working for the newspaper here, which is the Indianapolis Star. And we were building social networking sites in Rails for like moms and pets. I built photo gallery management applications to help photographers and like stuff like that, all in Rails.
[00:33:24] Chris Vannoy: I've been doing it a long time. And my English major brain just like latched into it and went like, "Oh, no, this is just like writing. This is fun." anyway, cool. thank you so much for joining me today. I just realized this is the first one of these, I think, where we didn't talk about AI at all.
[00:33:41] Benedikt Deicke: I think we hinted at it at
[00:33:42] Benedikt Deicke: some point,
[00:33:43] Chris Vannoy: So that might be refreshing for folks who are listening. where can the folks listening or watching keep up with you, like follow you online, or follow what UserList is doing?
[00:33:51] Benedikt Deicke: So Userlist obviously at, uh, userlist.com. it's our website. There's our blog if you're, like, specifically interested in, like, email marketing for SaaS applications. my website is, uh, benediktdeicke.com. You probably don't know how to spell it, so go to the show notes.
[00:34:07] Benedikt Deicke: that's also my handle on Bluesky and, uh, you can find me on, on LinkedIn. I'm not on Twitter anymore these days. there's an account, but it's not active. And if, like, super, super interested and really wanna follow along, I run a podcast every other week called Slow and Steady. It's at slowandsteadypodcast.com
[00:34:26] Chris Vannoy: and you should definitely give that a listen. Thanks so much. Enjoy the rest of your day today.
[00:34:30] Benedikt Deicke: Thank you.
[00:34:31] Chris Vannoy: Three things I'd like you to take out of that conversation. One, sell it before you build it and keep listening after you do. UserList pre-sold five customers before there was a UI. Then for years, their demo calls spent more time on the customer's problems than the product. The roadmap wrote itself. They eventually threw the feature list away because the important stuff kept coming up on its own.
[00:34:54] Chris Vannoy: Two, who pays you shapes what you build. UserList is funded by its customers at this point, so it's built to last. Nine years in, no big rewrite, and still on Ember. Because we need to hire one more developer instead of twelve, the unfashionable framework is fine, especially if it's good. Before you copy someone else's architecture, ask what business it was built for.
[00:35:16] Chris Vannoy: Three, not everything needs to be fast. Know which things do. A transactional email has to go out right now. The Monday newsletter can go out five minutes late and nobody will notice. Benedict sets alert thresholds queue by queue anywhere from a minute to an hour based on what a customer would actually feel.
[00:35:33] Chris Vannoy: If you want more of this, the newsletter is at axiomatic.com. That's where the stuff between episodes lives. Go find Benedict at userlist.com. If you do email marketing for a SaaS product, the blog is worth your time. He's on Bluesky and LinkedIn, and his name is easier to say than to spell, so the links are all in the show notes.
[00:35:53] Chris Vannoy: He also co-hosts his own podcast, Slow and Steady, every other week at slowandsteadypodcast.com. The name tells you a lot about how he builds. Thanks for listening. I'm Chris, and I hope you're having a wonderful day