SEASON 2 - EPISODE 184 - February 18, 2026

Move fast when you can

Sometimes speed matters more than polish. In this episode, the team shares how a HEY Calendar feature went from idea to shipped in about a day — and what made that possible. It’s a look at when moving quickly helps, when it doesn’t, and how writing clean code gives you room to change your mind later without breaking everything.

Watch the full video episode on YouTube

Key Takeaways

00:11 - Shipping a new feature in roughly a day
03:14 - Catching the moment while it’s hot
08:02 - Shortening the path from idea to implementation
12:04 - Making change easier with clean, thoughtful code
19:42 - Designing things that hold up and are easy to fix
22:51 - Building for the future

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes from the 37signals team joined as always by the co-founders, Jason Fried and David Heinemeier Hansson. Well, we are often talking about the importance of moving quickly when it comes to software development. We recently released a new feature in HEY Calendar, that happened so quickly even I was surprised by how quickly things happened. I thought we would talk a little bit about that. Jason, why don’t you kind of talk us through, this is a HEY calendar feature, what the feature is, kind of how the inspiration started and the process. And then David, I’m sure we have technical things to add as well.

Jason (00:37): Yeah, so rewinding, I remember on Twitter or X, someone mentioned, posted this full year calendar, but with the full year but only showing spanned events, which is like a vacation or a birthday or something that doesn’t have a time. And I saw that and I’m like, that’s really clever layout. It’s very useful and helpful and it’s nice if there’s not appointments on here because you don’t need to see your appointments eight months in advance, but like spanned stuff is just really easy to see and you can kind of get a sense of your weekends and what’s going on or whatever.

Kimberly (01:07): Across the whole year. One big picture.

Jason (01:11): And I just thought it was pretty cool. And so I mentioned it in our HEY project that I thought this is cool. I shared the post on X and I said we should do this, this is cool, or something like that. And then I kind of left it there. And the next day Michelle, Michelle was somewhere else around the world. She’s always somewhere else around the world and she’s one of our designers. And so when I set it, I went to bed and she was up and she just did it and basically overnight and put it together pretty quickly, which was pretty great. She worked on the HEY Calendar also, so she was kind of familiar with the code base and how it was all laid out. So she built this thing in one night and that was very exciting because I felt like there’s this momentum gathering online about this idea that this guy posted, that there’s a lot of posts about it.

(01:52): People are like, oh my god, yeah, totally. We should have this or my calendar should have this or why don’t we have this? And so I felt like it was this really nice sort of call and response kind of moment where it’s like someone just said something, it’s like, okay, we have 24 hours to answer the call and this would be a great moment. It’s a new year, full year calendar looking ahead, perfect timing, great opportunity for HEY C alendar to get out there again and make some noise and be visible. And so we did that in one day and we got it out there very quickly. But the thing that was interesting was that whenever you see something like this, other people chime in, they go, oh, could we add this? Or It would be nice if we had this or if we had that, it’d be even better.

(02:27): And there’s a tendency for everything like that to just turn into a snowball. By the way, these are all good ideas in a sense, but also we would’ve lost the moment. The moment was within the first 24 hours to get this thing out there and be able to respond the next day, hey, we did this. And that’s what we ended up doing. So we kind of slowed down the roll on all the other things we could do with it and just got that thing out there. What was cool is that a lot of other people then began to build similar things. This took on a life of its own for the next few days. Other products came out with calendars, other people vibe coded a version of this and it had this week long sort of momentum behind it, which was fun to be part of right from the start, I guess.

Kimberly (03:05): And Michelle wrote, I’ll link to it in the show notes, she did a writeup on HEY World, like how this came together in 24 hours, which is amazing. So I’ll link to that so you guys can write it. David, I’m sure on the technology side there’s always the idea of moving quickly and building momentum, getting things out the door. Is that true on the tech side of things?

David (03:23): I’d actually say the opposite is true. Almost everyone, almost everywhere have a million reasons for why you cannot launch a feature like that in a day. As Jason says, there’s additional features you want to add on to something. There’s QA processes, there’s product management, there’s getting things signed off, they’re showing it to perhaps someone on another team. There’s just always a million reasons for why you can’t do something in a day, but those reasons are all just made up and you can choose at any moment to just ignore them and just ship stuff. Now, if you keep doing that on literally every feature, including major stuff, especially if the vibe coding is involved, there’s a high change you’re going to snowball into a ball of mud with your codebase and then it’s going to be really hard to maintain and so forth. But even that a cop out most of the time because there is usually always a judo way of doing something.

(04:20): A judo way for us is using this energy that we have, these enthusiasm we have for a new feature and then throwing it around and making it fit within the constraints that we have, making it fit within the existing structure of the code base, make it fit within the existing structure of the design. Michelle was able to do this because she was building upon a calendar feature that was already there. If we had had the impulse to, hey, should we add a calendar and do it in one day? That’s probably a step too far. We spent, I don’t know, two months at least a whole cycle on that calendar in the first place. But there’s just so many opportunities like this where what people want is not an enormous new thing. They want this, they want this slice, they want this twist on it, and very often you can take components you already have and bend them in slightly new ways and deliver that, which is really exciting.

(05:13): And it’s even exciting for us. I mean I think in the early days, far more of our features would happen in this way because we had less mass. We had a far smaller team, we had a much smaller code base, we had much simpler products, we had far fewer customers, and that makes all of that easy. The natural momentum as you get more successful, as you get larger, as your code base survives longer is for all that to bog down. And I think that’s why even inside of 37signals, we move pretty fast on a lot of things, but not often that fast. Not often Jason drops an invitation to do this and overnight there’s something new. But whenever that happens, it’s always a magic moment and it reflects incredibly well on Michelle and on anyone else who’ve taken this up. I’ve seen this inside of 37signals before, especially with new employees, nothing creates just that enthusiasm as making things happen.

(06:12): Jason didn’t say, hey, we need to have this and the deadline is tomorrow and just go, go, go, just summon everyone, you drop everything, just go. It’s this planting of a seed and it’s seeing it super sprout in a night or in some cases even just a couple of days, that just invigorates everyone, reminds everyone that software is so malleable. We can change almost everything, not everything, but almost everything quite quickly. And you know what? We should remember that. Why don’t we work like this more of the time? Why are we not willing to make those trade-offs more of the time? Which is when I say trade-offs, mostly about cutting scope. Mostly as Jason says about, yeah, yeah, yeah, we could do all that, but here’s the kernel of the idea. Here’s the epicenter of what we’re trying to do. Can we get that out first and even see if it resonates at all?

(07:02): This really did resonate, right? Which by the way, I find interesting because I think the reason this really caught the attention of this corner of X was a bit of a throwback to how UI used to be. Way more information dense, being able to see tons of data in the entire year on a single screen. So much of the critique of modern design is that it’s the opposite. That information density is just going way down. You have to constantly scroll. There’s no way of getting that big overview and that sort of just massive information in a single glance and this was that. So I also just liked it from that perspective that this was throwback feature done in this throwback super quick way. And then you’re part of a conversation which is always good marketing. And half of that participation as Jason says is about the moment. If you had shipped this a week or two later, do you know what? No one would’ve cared.

Jason (08:01): Yeah, it also was other people responded, but we were sort of first to respond, which is a leadership kind of moment. These are all of little subtle things by the way, none of this really matters, but it’s nice to not be the sixth calendar tool to roll this out in four days. It’s nice to be the first. And we gave the guy credit, I quoted his original X post and be like, great idea, we just did it too. That kind of thing. And then he responded back later, he is like, and I did it also. I think someone else did a print version and it was just super fun to keep improving on each other’s work actually. And even the initial version we shipped wasn’t quite where we wanted it actually. The weekends were kind of scattered. It was kind of a bit of a mess.

(08:41): And then that day later, Michelle cleaned it up one more time, so it was fine to ship it even as a bit of a mess because we got to make some noise, talk it up. People weren’t paying attention to the messiness. It wasn’t the point. The point was that it existed and then within eight hours we made it like 2x better. And then we were done with it, by the way. We moved on, because it’s also very easy to get stuck in this honey trap where it’s like gooey and you’re stuck to it. And we spent the next three weeks perfecting this thing that really, it’s a side show feature in many ways. You don’t often need this, but when you do need it, it’s great, but we don’t need to spend weeks on it. A day is plenty. Got it out there, made some noise.

(09:17): It was fun to trade barbs with people, to get other people to do this. We actually even for a moment, started working on a print version of this. I dunno if Dave even knows about this. We’re going to do a big huge print version which we’re going to sell in our store. And then we just lost momentum because other things came up and I’m kind of glad we did because we didn’t need to go there and we just moved on. But it was a fun 24 hours for sure, and it actually did inspire me. I was just talking about this with the Basecamp 5 team this morning. We have a call on Tuesday mornings about some features that we’re working on, and there was one thing that someone did sort of on a whim to clean just one screen up. It took like an hour and it was just so much better.

(09:52): And it reminded me of those days that David was talking about where we just shipped something much better very quickly and it wasn’t a huge change, but it was a change enough to make a big impact. It’s easy just to get stuck in only big releases and big stuff like big thought out, conceptualized things that take days or weeks versus something that takes an hour that makes something considerably better. And so I’m just kind of pushing the team to get back into that realm of like, there’s a lot of quick wins here. Where are the quick, quick, quick, high power, low effort, high value wins. Not just quick wins actually, because quick wins you can make some changes that don’t matter, but there are things you have certain leverage over where you can really make a major change with a small amount of work that makes a big difference quickly. I want to get more of that rolling and in fact, don’t quote me on this, but I would love to get to a place where we could make a promise that Basecamp gets better every single day at least one way. And it kind of usually does anyway with bug fixes and stuff, but I would love to be able to release something every single day that someone’s going to see that and go, yeah, that’s better. Yeah, that’s better. Yeah, that’s better. And so this collection of one hour fixes, one hour improvements would be a nice thing to do. So anyway, that’s just something that’s on my mind.

Kimberly (11:04): You just gave every designer and programmer a little anxiety right now.

Jason (11:07): You know what though? Yeah, maybe. But so what? it’s good anxiety. Also, there’s this guy online, his name’s Soren Iverson I believe is his name if I’m pronouncing it right. He’s great. He’s on X. I think he might be on LinkedIn, might be other places too. Those are the only two places I pay attention to, but every day he posts an interface idea for someone else’s product that’s usually quite funny. It’s just really funny interface ideas and obviously he doesn’t have to make these work. These are just full mockups, but really high quality, but full and funny kind of mockups. That’s actually what inspired me in some part. Yeah, he doesn’t have to make these things work, but it’s our product. We can make these things work and they don’t have to be massive changes. They can be subtle, small things that matter, and there’s definitely 365 of those in the product, so let’s just pick one off a day. So yeah, maybe it gives people anxiety, but I think it’d actually be really fun, a fun challenge, these one hour improvements basically is what I would call them.

David (12:04): I think the reason this can work too is that the anxiety often comes when you set a deadline and then set a fixed scope. This is something we talk a lot about. This is what Shape Up is based all about. But if you just go, do you know what? Let’s make something cool, awesome, better in a day, the main constraint is the day. There’s a real liberation in that. There’s a real liberation in just going, I have this fixed amount of time to improve something and let’s see what I could come up with. The human mind is incredibly efficient at paring something down when you put those kinds of constraints on it. I think the anxiety really comes from here’s a fixed body of work that I don’t quite know how I’m going to solve, how long it’s going to take, but I’m just imposed this deadline upon me.

(12:55): That’s the death march culture that often occurs in the gaming industry where you just have these month long crunches. We don’t do any of that, but you can still embrace that acceleration of doing something quickly. This is something actually back in especially the early Rails days, there was this thing called, what was it called? Rails Camp or something? 24 hours, a sprint, 24 hours come up with an entire app and put it out there and make something real. It’s incredible what people can make in 24 hours. Again, part of the magic of moving quickly is sometimes when you just start from a clean sheet of paper and when you’re working with a code base like Basecamp, in this case that is literally at this point with that going to be 14 years old since the first commit, it’s not quite as easy. But I also think it is one of the rewards of keeping a clean workspace.

(13:51): 14-year-old code bases have a tendency sometimes to get a little creaky because they haven’t been kept in a nice state. There’s just endless amount of deferred maintenance. People have been pushing just new features and never going back to revisit some of the core fundamentals. And when I look at the Basecamp code base, the 14 years, I’m actually quite happy with how little creaking there is. There’s some give, there’s some take, there’s some scars that this is a code base that’s lived the real life with real customers and gone down some technological blind alleys that we then reverted from. And there’s still some traces there, but overall, the reward for keeping your workspace clean, keeping your code base in a good condition is that you can do this kind of stuff. And the most anxiety producing predicament that I see for programmers over and over again is this willingness to want to do that, to want to fast, to want to be part of the conversation that’s happening on X, to put in a feature and ship it right away and feeling like I just can’t. The ball of mud has grown too big. If I touch this part over there, I really need a bunch of eyes on it because otherwise maybe I’m going to break 15 other things. So in many ways this is a bit of a reward for doing a good job over a long period of time when you can do this with an existing code base.

Jason (15:17): We actually talked about this, I think it was in Getting Real, this idea of lowering the cost of change, I think is what we called it. In BC5 as we’re working on it now, there’s some CSS that’s just like, I’m like, this is more complicated than it needs to be and I’m kind of afraid to touch this ‘cause I don’t know what else I’m going to tweak when I tweak this. And there’s some of that and we’re going to actually go through and clean all of this stuff up. But it’s funny, it doesn’t take much to make you go, uhhh maybe not. Maybe I shouldn’t do this. It’s barely anything, but it can be like, this is going to be a major problem if I screw something up, so I’m just not going to touch it. And that’s how you sometimes leave things around that aren’t quite right. So yeah, I am totally on board with David’s point about code hygiene and clean workspaces and stuff. It makes a big difference, just makes things easier to tweak and change and allows other people to do things who might not be as skilled as everyone else, but as long as you can make sense of it, you can figure it out versus something that’s very convoluted and very difficult to figure out, you just stay away from it.

David (16:09): And I think this is the part that sometimes is lost on folks. When you talk about something that seems almost like an inaccessible luxury, like code quality, like code size. There was just a post, was it yesterday where someone was looking at our code bases, especially the ones we’ve released in public and go, how can they make them so nice? How can they make them so polished? Why does all the code look so pretty? And then they were coming up with all these coping realizations. Well, it’s because they don’t make a lot of features, no. Part of, sort of, but not really. The whole thing works together. You commit early on to the idea that you’re going to produce quality software that’s easy to change and you might take it a little longer. In the beginning, I don’t even think that’s true, but even if it was that investment is just going to pay off tenfold, both in terms of actual defects, customers finding bugs also in terms of being able to explain your product if it isn’t vastly bloated.

(17:15): But in this example, giving you the agility to be able to do something like this in a single day. That happens when a single developer, in this case, the designer, Michelle, is able on mostly her own to go in there and get something done and have some confidence that it’s not just going to explode everything. So it all works together. And this is where when folks from the outside sometimes look at our engineering culture, they think like, do you know what? There’s some exotic stuff going on here. They’re doing things that no one else can. And then usually there’s a bunch of bullshit reasons. No, it’s really not that. We don’t have that many people. We don’t have that much capital compared to most of the enormous shops out there, and yet we’re able to produce something of high quality quickly that can be iterated upon.

(18:07): Those things are more tied to a sense of it’s been overused, but this word of craftsmanship that the time you spend on the internals of the machine, as I think Steve Jobs talking about the inside of the layout of the print boards that even need to have aesthetic qualities. It seems so silly. It seems so frivolous to someone who’s like, well, how’s this going to convert into business? How can this code quality turn into conversions? Well, this is how, being able to be part of a conversation, having people who are inspired and empowered enough to be able to make changes right away, all that will convert. No, not the I’m fiddling with the line noise of every single little thing that in itself, but all these derivative benefits from it absolutely do. And I find it fascinating that that is still a difficult argument to make.

(18:59): We didn’t come up with this notion that software is better when it’s easy to change. That was the core premise of agile development, but that was how you defined good software. That was software that could change because you realize that software always changes and therefore that’s a property to optimize for. Yet it is so rare. And I find that this is just one of those fascinating things where it could be easy to say, oh, code quality is important for agility and employee satisfaction who are then inspired to do something like this. But actually putting that to use? Much more difficult, you can sum up so much of the wisdom of software development and software methodologies in just a few lines, but living them? Much more difficult.

Kimberly (19:42): I would also think with we’re building Basecamp five right now, this idea, Jason, of making daily fixes is easier when you’re starting something new because we’re not putting every idea into it. I’m sure there’s a place where there’s ideas that are being logged somewhere that could be a quick fix, but it’s not essential for launching the new product.

Jason (20:03): Well, the good news about having a product that’s as big as Basecamp is that there’s a lot we can make better. By the way, these features, these one hour features, these daily improvements, it can be just as much as like David talking about increasing the data density on a particular widget on a little thing, now there’s more information on this card or now the proportions are better, so this is clearer. Or we added a time to this, not just a date. They don’t have to be life-changing things. They can just be little subtle things that add up over time and make the whole system better. But to see that kind of momentum on a daily basis, calling out one like, hey, this — before, after. I like to do these little before afters basically, and every day. Anyway, this is what I’d like. We haven’t committed to this, but let me just jump back for a second.

(20:44): There’s one thing that occurred to me. I’m reading this new book by Stewart Brand called Maintenance, which is a really awesome book about maintaining all sorts of things from sailboats to guns to motorcycles to stonewalls. It’s a fascinating look at the art of maintenance. And one of the things he talks about is that durability is an important term, which we haven’t really used yet, but something’s durable, it means it can last a long time, but it also typically means it can be repaired fairly easily. So things that were hard to repair tend not to get repaired, and those things tend to wear out. And then you get afraid. We used to call this code smells, I think, right? Where you’re like ooh. I don’t want to get close to that. So part of this is building durable software makes means the cost of change is low. You’re not afraid to get in there to make the changes and to make things better.

(21:30): There is a place where you’re like, I’m not going to touch that anymore. It’s too complicated. I think Highrise is a good product with an unfortunate story here actually, where it just became this big ball of mud and it’s kind of a total mess. And other teams have gotten involved with it that weren’t our core team and we’re like, we just are afraid to touch it frankly. Not that we’re really interested in touching it again, but even going back in there, you’re like, I don’t really, yeah, I’d rather not. It will decay because we’re afraid of maintaining it because it’s hard to improve, it’s hard to fix, it’s hard to understand, it’s hard to reason about. The parts aren’t interchangeable in a sense. Everything is bespoke and custom and it’s very difficult to deal with things like that. So this idea of maintenance and software, it’s ringing true, comparing it to physical objects, he’s just talking about the Model T, how it was just very easy to repair these things because all the parts were interchangeable versus bespoke parts that were other cars in the early days were all super custom.

(22:24): And so people couldn’t even work on them because they didn’t know if they changed what this would happen to that and that sort of thing. And so those kind of didn’t make it while the T, for a variety of other reasons, made it and allowed people to work on their own car and it got people excited about that whole thing. So anyway, long story short is making durable products is not just about making something that doesn’t break, but it’s about making something that’s easy to repair. And a big part of that, I think, is making sure the code is readable and easy to deal with and not too convoluted or complex.

David (22:52): Now, what I love about that metaphor is how well it applies to the open source work that we do at 37signals because it’s exactly that. When we release applications like Fizzy or Campfire and people get a chance to look at the code, sometimes I think there’s perhaps an appreciation that’s really simple, but also maybe a hint of disappointment that there’s this belief that it should have been more sophisticated when the sophistication is in its simplicity, is in the fact that so many of the parts that we need to build something like Fizzy or Campfire have come from genericizing everything that we’ve built over the last 20 years, that we’ve taken all these things that started out life as very bespoke, one-off inventions, creations to create either a Highrise or Backpack or Campfire or whatever, and then putting it into Rails. That process transforms the bespoke part to the generic part, which then means when someone encounters a code base 20 years later, like the Fizzy code base, it all seems so incredibly familiar because it’s using all these generic components that we’ve built up over 20 years, which is what gives it a huge part of its ease of maintainability.

(24:10): This is something I’ve seen time and again when I contrast the Ruby on Rails ecosystem with other ecosystems, and especially when it comes to dependencies. A lot of folks working in JavaScript for example, use something called NPM, which is the node package, what modular, I don’t even actually know what the M stands for, a package repository, and they just use a gazillion bajillion dependencies, all these little nuts and bolts that are too small, in my opinion, to be distributed as one ups, right? They should fit into a larger perspective. And I think when you start working like that, it doesn’t seem like a big problem. So what if I have 2100 dependencies here? And then when you work on something for a few more years, you realize that’s not durable, that’s not easily maintainable because all these little bits, the folks who work on ‘em come and go, and sometimes the incompatibilities just stack up.

(25:07): Versus in the Ruby on Rails world, we really focused on having a proportionate mass to when something becomes a new package and having more of those packages under single umbrella and therefore building up a body of knowledge and tools that feel truly generic where an investment both in their use and your learning about that use your knowledge of how to use it best can accumulate over time. Now, you don’t always get that luxury because some things move very quickly. I think AI right now is a great example of that. Jason and I were just talking this morning, actually overnight about the MCP standard. This is something that we played with in a bunch of different contexts. I even got halfway started on a framework for it for Rails, and it only premiered I think in spring of last year. So it’s not even a year old.

(25:57): And already there’s a sense that you know what, this perhaps probably isn’t the future direction of how agents should be using tools. Now there’s something called Skills, and they work very well with CLIs even though there’s still some MCP usage to, there’s some domains that just move really quickly. The web mostly is not one of those. Whatever investments you made in, I don’t know how to handle cookies back in 2002, they’re still there. Cookies are still largely the same. There’s some security layering that’s happened on top, but the fundamentals of how to interact with that core technology of the web is still as it is. So any investment you made 20 years ago, you got to withdraw dividends on the entire distance. And this is when I’m often reminded of my favorite Bezos piece of advice that Jason and I got. I mean, he’s given it to anyone, but he also gave it to us in person, which was invest in things that don’t change.

(26:54): Again, you don’t always have that luxury. Sometimes you have to be on the new things and you don’t know where the new things are going to last. But when you look at the overall picture of where your time should be spent, more of the time should be spent on the things that don’t change. More of your investment should go into that both personally and as you’re developing a business and as you’re making technology, which is a little bit like books. Like there’s this great saying of it’s better to read old books than new books because the reason old books are still around is because they’re really good. If something has survived a hundred years, do you know what? There’s some real wisdom in it. If it’s survived 2000 years, I mean Hall of Fame classic versus you look at any given year, 80, 90, 95% of all releases in that year will be either just not that good or obsolete shortly thereafter.

(27:42): So I think maybe also, this is something about getting old, and Jason and I are projecting a little bit of this kind of like, do you know what? When you hit 40, there’s certainly this magic appeal to trees. You could have told 22-year-old self like, oh, here’s a nice tree, and it’d be like, it’s a fucking tree. And I know this because I have three kids and I often tell them, wow, look at this tree. And sometimes they’ll placate me like, yeah, yeah, that’s a nice tree. But I can tell. They’re not yet at the stage where they generally appreciate the longevity of a beautiful tree. But then you get passed 40 and you suddenly start caring about trees. You start caring about the durability of a stonewall, you start appreciating that the pantheon still stands. So this is why it’s good to have a little bit of both, that if you veer too much in that direction of the durability and the long lasting and whatever, you can get kind of old and crotchety and just about the past. And the magic of software is that you’re also forced into the new stuff, at least if you want to still be relevant, if you want to still be taking advantage of everything that we’re making.

(28:50): And this is what I’m really finding with AI, we talked about this on another episode, it’s infusing all of this newness into all these crevices, and we have to wrestle with not throwing out everything we’ve learned over 50 years of a software development understanding and in also taking care of all the new stuff. And some of that helps simply by age, right? Like Jason and I both over 40, closer to the 50. Actually, you’re 50, aren’t you?

Jason (29:17): 51.

David (29:18): You shit old man, don’t trust anyone over 50. I have at least three and a half more years to go, so you trust me three and a half more years. But this sense that even in hiring too, we should have something for both ends, right? So I’m always really happy when we end up with that nice mix that we have people who appreciate trees and then people don’t give a shit.

Kimberly (29:37): Okay, well, with that, we’re going to wrap it up. Rework as a production of 37signals. You find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube, and if you have a question for Jason or David about a better way to work and run your business or their favorite trees, send us a video question. You can do that at 37signals.com/podcastquestion. Or email us at rework@37signals.com.