SEASON 2 - EPISODE 190 - April 1, 2026

Pencils down

Knowing when to stop is harder than it sounds. In this episode, Jason Fried and David Heinemeier Hansson talk about the moment when more work stops helping and starts getting in the way. They share how to recognize when something is done, why chasing perfection can do more harm than good, and how putting the pencil down at the right time leads to better results.

Watch the full video episode on YouTube

Key Takeaways

00:11 - The “pencils down” phase of product development
01:24 - Testing by the entire company
03:17 - AI Workflow & vibe coding
09:58 - Speed vs durability
15:08 - Refinement & cutting features
18:08 - Full launch strategy
20:00 - “Give It Five Minutes” Mindset

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, joined as always by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. We’ve been saying for a while that we are working on Basecamp 5 and as we are approaching that finishing touch, I wanted to talk a little bit about what our next steps are. So Jason, you recently just shared with a company that we are about to wrap up new development. Tell us a little bit about what that means in terms of where we’re stopping and where we’re going to get to next.

Jason (00:35): Yeah. So we’re using the term pencils down, which actually was something that I think Brian mentioned, which I really liked as a name, which is basically like the test is over, pencils down, which basically means for us, no new feature development after this certain date, which is what we’re very closely approaching. And then all of our energy can go into refining, tightening up, polishing, still tweaking. We’re still changing things, but we’re not adding new things because when you add new things, you add new untied loose ends and you got to tie those up at some point. Now is the time where we’re done with that. And now it’s just all about tying everything up and making everything just right. So we’re about to enter that phase and after that we’ve got it, I’m just going to call it weeks, not months and months, to polish and tighten everything up, and then we can release it to our customers. So that’s kind of what the phase shift we’re approaching right now.

Kimberly (01:24): Okay. So we’re pencils down first. And then I think you said the next stage is everyone in the company being on Basecamp 5. It’s funny, I was doing a live recently and someone asked, “Are you guys internally on Basecamp 5?” And Ashley and I were like, “Yes?” But I kind of switch, I know for me, I switch back and forth between 4 and 5 a lot. There’s a lot of different beta channels as well, so I’m switching between all of those. There’s going to be a hard date where the entire company moves over. Tell me a little bit about that and what you imagine that kind of feedback to look like versus what the product team has just been doing without everyone else involved.

Jason (02:00): Yeah. So currently there’s, I think we have 12 or so different betas set up internally, which means that there’s… the product Basecamp 5 is in about 12 different states, you could almost say. We’re testing out this feature and testing out this feature, and testing out this feature. What we’re trying to do soon-ish, we’re all going to consolidate on branches together, all these different betas together essentially, and having like one canonical version of Basecamp5, which the whole company is going to move to internally to use while we’re finishing wrapping everything up and polishing everything up. We want to put all the possible pressure we can on the product to get it just right. Right now, as you mentioned, some people are using 4, some people are using 5, some people are using 5 and different versions of 5. It’s now time when pencils go down for everybody to basically pile in one version of 5 so we can press it, push it, prod it, and get it just right.

(02:51): And we need everyone in the company to be doing that. So people run into things that are uncomfortable, people run into things they’re not used to. Just like our customers are going to run into things they’re not used to and their customers are going to run into changes. We want everyone internally to do the same thing. So while I don’t know what percentage of people are currently using 5, very, very soon everyone will be and 4 will be just what our customers are using. And we’ll still go back to that if we need to troubleshoot or whatever, but internally we’re all going to be moving to 5.

Kimberly (03:15): David, are you already on 5?

David (03:17): I’ve been switching back and forth. So as Jason says, we have a lot of different features that are in different states and I go to check those out and I use the different betas and then sometimes I’m just on the regular version 4 as well that our customers are using. But I think what’s really key about this version versus so many other things and improvements we’ve made to Basecamp in the past is that this is the first major push that is heavily AI accelerated in terms of its development. And that means we actually have even more loose ends than usual because we’ve been able to explore so many things at a very different pace than what we’re used to doing, especially because our designers have been able to go much further with their prototypes of different features and seeing them come alive more easily with less support from programmers than was true in the past.

(04:13): But that also means that we have a fair backlog of, let’s say, vibe-coded stuff that needs a new set of eyes because it’s one thing to get something working on a private beta, it’s something else quite entirely to roll it out to hundreds of thousands of millions of people who have to not just find something that works, but also something that scales, that doesn’t take down the servers, that doesn’t overload the databases. And that process is going to require some adjustment. We’ve been playing with a bunch of different ways of trying to deal with the increased productivity that you can have in these ways. And one angle we’ve tried is like, well, let’s just merge it all in and then we’ll fix it up. And that process has been creaking a little bit. It’s actually quite hard to keep up from the senior programmer side when we have a bunch of stuff going into the code base all at once because designers and junior programmers can make so much stuff now that holding the line on quality, making sure the architecture still hangs together and isn’t undermined is a challenge.

(05:23): It’s a great challenge because I mean, we should all be so lucky to suddenly find all these new pockets of productivity, but it’s nonetheless a challenge. So one of the things we’ve been trying very recently, in fact, is a method I actually heard about at Shopify, which is use all the vibe coding capabilities you can, figure out as many answers to the question of what should it do and how should it work by just throwing things at the agents, just getting it working. Because in the past for us, that was a very collaborative process and therefore a bit of a slow process. You’d have a designer who’d make a sketch in HTML, not necessarily in a different program, but in HTML, and then they really needed to work with a programmer sometimes for even a few weeks to just get something working. And then once there was something working, you’d go like, “That’s actually not quite what I want.

(06:19): I want something different.” A lot of times that meant throwing out a bunch of work that we had created in unison and obviously that’s a waste. Not only is it just a waste in terms of time and productivity, but it’s also a waste in terms of motivation. I mean, parts of the job I hated the most working both with Jason and Ryan and everyone else stretching all the way back to the earliest days was when I would spend like two weeks or three weeks or sometimes even four, creating something that I thought was really nice. And then Jason or Ryan or whoever would say like, “Eh, it doesn’t work.” And I’d be like, “What do you mean it doesn’t work?” “No, no, no, it works. I fucking made the whole thing. It has to work.” And that kind of investment in, we made something, therefore we should ship it or therefore we should keep it.

(07:05): It’s not good, right? You end up then settling for something that’s less than your best because either you run out of time or you run out of, in my side, sometimes patience for just redoing the same feature for the oomph time. You know what’s created by agents? Endless patience. You can simply run around in rings with them all day long and they will produce one new instance of your idea after another, and then you can find out exactly what you want. So then when you know what you want, the process of turning that into code we want to keep, pull requests we want to merge, becomes a whole lot simpler. It’s actually bizarrely a little bit like the early days of software development where you’d have people go away, they’d write a spec and then they would throw that spec over the wall and then some programmers would go implement it and it worked like shit because no one is able to just in their mind conceive of what a great piece of software should look like and should work and write it down on a piece of paper and a set of sketches.

(08:09): That didn’t work, right? But now you can come up with this spec of how the feature is supposed to work in collaboration with an AI, which is actually real working software. And then that process of turning that into production software that ships has some of those characteristics and fulfills that initial or early ideal of the waterfall development. Well, if we could write everything down exactly as we wanted and then hand it over to a program, that’s a very efficient ladder. But of course it only works if the programmers are given something that you actually want to ship. So that’s the kind of process we’re pursuing now more where we have this vibe-coded stuff that then gets handed to programmers, then turned into something that is production ready and worthy, and then we ship it. And I think that’s just been really exciting to see that because the last thing we shipped, Fizzy, didn’t have any of this.

(09:01): Fizzy was developed the 18 months leading up to somewhere around the summer of last year. That was before the agent revolution. It wasn’t before AI, but it was before the agent revolution. It was before Claude Code and OpenCode and all these other things took off. So it was like 95% hand coded. And if you look back upon that process, like the size of the product and the time we took to build it, it already seems quaint. It already seems like, wow, that was from a different era. A wonderful product came out of that. Fizzy’s amazing. But holy shit, that took a long time to get to where we wanted to be because we wanted it to be just right and we had to have a lot of this. Can you make it? Yeah. Okay, let’s talk in two weeks when the thing works. What? Now that seems completely foreign that that would be a development process. So Basecamp is now going to be in a phase where all of that has been part of the process and that’s just super exciting.

Jason (09:58): One thing I want to add too is like, obviously it’s incredible how fast you can make things these days, but with something like Basecamp, you have to also worry about durability, which is like, does this thing work? We have like a million people using this thing. We can make things fast, but it can also be incredibly sloppy. And if you’re making something for yourself for the first time and it doesn’t matter so much, that’s one thing, but we can’t throw that at our customers. We have to make really durable software. So this just isn’t something that’s talked enough about, I don’t think. Yes, you can move faster, but it doesn’t make things more durable. You still have to have that careful attention to little small things. What’s this going to feel like? Does this work? What are these edge cases like? You can’t be like, “I’ll just deal with that stuff later.” I mean, you can if no one’s using the thing, but to develop software for a huge audience and a well-established product still requires a lot of diligence, human diligence that is different than just running fast.

(10:48): So that’s kind of the phase we’re about to enter right now, especially, which is like we have to be very, very diligent now, very detail oriented and make sure that everything actually works. And there’s a lot of screens in Basecamp and there’s a lot of things we’ve been changing. So there’s a lot of things that look bad right now because we didn’t realize that this change would affect this change. And so there’s still a lot of human work here. And I just want to make sure that people understand that. To make great software, currently at least, if you want to really release something that’s really durable, I think you still need to have people using these things and paying very close attention to how they work, because at the end of the day, humans are going to use them too.

David (11:23): The flip side of that is also, yes, you can make a lot of things real fast, but that’s also a bit of a danger. You can shove a lot of stuff into a box that just can’t hold all that stuff. And suddenly there’s things springing out right, left and everywhere, and that’s not a box you want, right? So I think there’s a bit of a switch where software development gets cheaper to some extent, but then taste and product direction and cohesiveness and all these other attributes, they actually become rarer. They become more valuable. When suddenly you have a hundred features you could potentially ship, the price of figuring out which 20 or which 10 or which seven should actually go out the door just goes way up. So I think that factor is big, but then as Jason says, it’s so easy right now to just sprint ahead and think the agents are already doing everything, because you get these glimmers where they really do everything. On one feature, on one angle, it just does the whole thing and you go like, “Wow, is this everything now?” And no, it’s not.

(12:28): I mean, we’ve been working on this agent accessibility where the first version of the command line interface, the CLI, that’s the basis of all this was done in no time at all. And we were like, “Well, I mean, it’s 90% there. How long can it take to get it to 100% of something we could release?” Ah, way longer than the first 90%. And that was sort of already true, right? We always knew there’s like, well, the last 10% takes another 90% of the time that meme have been around software development for a long time, but it’s been 100 X’d. The cost now of getting from, maybe not to 90%, from zero to 75% has literally fallen by 100X, maybe even a thousand X, but the cost of getting from 75% to 100%, do you know what? In some ways, it actually goes up because you are able to cover so much territory in sort of a rudimentary way so quickly that the backlog of everything you have to go through to check it out and make sure it’s not just working, but that it’s right, that it’s ergonomic, that it’s convenient, that it’s good, takes so much longer and it’s so much more shocking because you see all of this code, you see all of these features exist in some form, right?

(13:45): And then you think like, “Well, we always could be there.” I mean, I’ve had that several times over the last few weeks where we’ve been polishing this agent accessibility where I’m like, “I mean, we had the demo weeks ago. Why can’t we ship?” And then I start working with them like, “We could, but I don’t want to.” This thing doesn’t work right. This is inconsistent. The agent just says, “Yes, yes, yes.” But it doesn’t say like uhhhh no. One of the things the agents can’t say right now is no, you’re being inconsistent. Have you actually thought this through? There’s not a lot of that going on. Maybe we’re six weeks away from a new model turn and then that’ll solve, but we got to live in the present. And in that present, agents don’t finish beautiful, ergonomic, desirable software. They just don’t. That human finishing at the end is not just necessary, it’s essential.

Kimberly (14:37): Okay. We’ve talked a little bit, David, you were mentioning refining things that we’ve developed. I’ve noted with Basecamp 5, because there’s so many people working on it, actually I said this to Brian recently, I don’t know how you guys were keeping up with all the updates that are being made. Jason, at this point in the process, now that pencils are going to be down, are you pulling things out of the product as well, like deciding like, “We like this, but we’re just not going to ship with it now?” Or is it just like cleaning things up because we’re going to ship everything that we’ve built so far?

Jason (15:08): Well, we’re in a constant state of refinement, which means that things that aren’t done by this drop dead pencils down date will not make it into 5.0, the initial version that we’re releasing, but they could make it in two weeks after. It’s not like we’re throwing it away.

Kimberly (15:24): Right

Jason (15:24): It’s just if it doesn’t make it, it doesn’t make it. It’s kind of like probably a physical product. You need to send it to the factory to start making the things, things make it or they don’t make it. That’s kind of where we’re at right now, but we’re constantly refining things. So we’re trying to make everything simpler. Everything we look at, this is what I’m sort of obsessed with is I’m looking at something up, there’s one too many things here. How do we get rid of this thing? There’s one too many things there. Eh, this isn’t clear enough. There’s too many words here. There’s not enough words here. It’s all that stuff. So there’s a constant flux. Everything’s in flux in refinement, but the aim is to just like you’re finishing a piece of wood if you’re building furniture, it’s like you sand it, you look at it, you sand it, you look at it, you finish it, you might put another coat on, whatever, you try to get that right thing.

(16:03): And so it’s a process of elimination. And then also addition. You sand to get rid of material and then you add finish. So it’s a very similar thing where we’re trying to refine things by tightening stuff up, but sometimes you go a little bit too far and you need to put some finish on there or sometimes you need to put some finish on there anyway or another coat of finish because something’s not quite the right shape or feel yet, that kind of thing. So sometimes it feels additive even though you’re subtracting. It’s kind of just depends what it is that you’re adding and what you’re subtracting. But there’s a lot of that going on right now. So it’s a lot of bubbling chaos. But I know we’ve been through this out. We just had a team call this morning and there’s like 10 people on the call or something and only four of those people have been around for multiple versions of Basecamp.

(16:44): So we have a lot of new people here who’ve never seen what it’s like to launch a new version of Basecamp. And there’s a lot of nervous heads around the screen because they’ve never been through this before. And then it was like me and Jeff and JZ and Scott who’ve been here for many, many, many, many years, 15 plus each. We’re like, “Yeah, this is just how it is and it’s all going to be fine and we’re going to get through this.” And actually all told while there are hundreds of improvements in this version of Basecamp and there’s some significant changes, it’s all going to be okay. It’s a lot less of a drastic change than previous versions that we made in some ways. And also we’re going to prep people really well by making videos and walking them through and explaining the benefits of the changes and giving everyone plenty of time to get a feel for it before we unleash it on everybody. Unleash is probably the wrong word. I don’t mean it like a vicious attack dog, but like reveal.

Kimberly (17:29): Yeah

Jason (17:29): Reveal, give. We give the new great stuff to everybody, but yes, things will be different. So we want to make sure we prepare people for that. And that’s actually another thing that’s kind of hard right now is I want to make some videos and some walkthroughs of things because I want to give people ample time to see what’s coming, but not everything’s in the right place yet. So we kind of have to wait. Kimberly, you do videos, you know what this is like. You have to wait for the UI just to be just right because you don’t want to immortalize it in the wrong version. When people are looking at the video, it’s like, well, that’s not actually how it is right now. So I find it to be a very fun, chaotic time right now. Not like nervous, stressful, but just there’s a lot going on and it’s kind of exciting to see it all come together.

Kimberly (18:08): Okay. So you mentioned unleashing this to customers, which this one is a little bit different than how we’ve released other versions of Basecamp in that they’re getting all the changes at one time, which is not how we did Basecamp 3 to Basecamp 4. That one was like, here’s new features kind of gradually over time and now we’re calling it 4. This one is like, you’re getting them all at the same time.

Jason (18:28): Yeah. Three to four was originally going to be all at one time.

Kimberly (18:31): Oh.

Jason (18:31): And then we made some decisions post or prior to that and then we started rolling it out. But yeah, this is everything at once because there’s a lot of fundamental changes that need to come together altogether. And it’s a big, massive improvement. The product is much, much, much, much better. It’s a really modern product. It’s got a lot of great stuff. And to release a little bit here and there, it wouldn’t feel like it’s adding up to some big, huge new thing. There’s downsides too, like people have had to wait for a year for new stuff in some cases, but that’s okay. We’re good. It’ll be here soon enough and then time moves on and everyone will get used to it and enjoy it and then we’ll keep making it better. This is one of the exciting things about AI, as David was mentioning, is like we can make things better really fast.

(19:14): And actually, I think what’s going to happen is because we’re making so much at once really fast, it can be a bit sloppy until this final stage here we really clean it up. But moving forward, we can release things individually very quickly that don’t touch 50 other things at once. Right now we have a lot of fast development happening in a lot of different areas of the product. So it’s kind of globally, there’s a lot going on. It’s very bubbly, but I think moving forward, it won’t feel that way. We’ll just move faster and release new things and improve the product really, really quickly, individually, one thing at a time, every few days, every few weeks, whatever it might be.

Kimberly (19:46): And then I know we always say give it five minutes when there’s big changes happening. Give us that blurb and what other people who are in similar positions, running software companies or other companies who are making changes, kind of that give it five minutes philosophy that you guys have.

Jason (20:00): Well, I think what’s important when you ship something that’s very different from what you have, first of all, I mean, do people have to use it? Are you essentially forcing it on them? If that’s the case, people are naturally going to recoil in some cases because things have changed in a way that’s just different from what they’re used to. Obviously, everyone’s already in the middle of something when they get this new version. Maybe it’s a Tuesday morning at nine o’clock. There’s a point where we have to ship this and there’s a point in which not everyone’s going to align with what they’re in the middle of. So there will be a little bit of that chaos, that little ripple for a minute here. And then people who are really in the middle of something like, “Where’d that go? Why is it over here now?” There’s a lot of that that’s going to happen that’s perfectly natural and completely reasonable for someone to be like, “Wait a second, I was right in the middle of writing this message and this just changed on me. What the hell?” There’s really no way to really make sure there’s a perfect time for a massive change like this. So part of it is just being understanding and recognizing that there will be some inconvenient changes at inconvenient times for some people.

Kimberly (21:01): I mean, especially that makes me think with a global audience, it’s not like you could just be like, a lot of times you see this, we’re going to be down at 2:00 AM your local time. We can’t do that when we have customers all over the world. There is no middle of the night to make it more convenient for people time that works.

Jason (21:17): Sure. And so there’s some of that. And there’s also just change like, “Oh, I was used to it this way. I liked it this way.” And having been through this many years, you go, what’s interesting is the things that people initially recoil against are things that they will defend two years later when you change the new thing that they didn’t initially like. So it’s a matter of people just getting used to things and understanding things and seeing how things have changed and then giving them time to get used to them. So we’ve taken a ton of feedback. There’s going to be just like thousands and thousands of things that people are going to say about the new version of Basecamp. And I think the best thing to do is just to accept them all and just listen to them and hear them and then just sort of let it be for a little bit.

(21:58): Unless something’s broken, you got to fix that. But in general, let it be for a little bit. You want to see what the feedback’s like 30 days post because that’s what people have had a chance to actually use the thing, get used to the thing, play with the thing, learn the changes, learn the differences, see what’s better, see what might not be better for them too. But we’ll all know more in 30 days than in 30 seconds. 30 seconds is a lot of just natural what just happened. And you don’t want to then fall into this place where you begin reverting or going backwards because people are upset about something. You just got to give it all time to settle out. There’s a great saying, I forget who, I thought it was like Alan Watts or some philosopher or something. It’s just like the best way to clear muddy water is to let it just be. If you keep stirring it, it stays muddy. You just have to let it settle and then you can see what’s left and you can see where you really are. So I think that’s what we kind of need to do is like let the mud settle out, let the silt settle out and let’s see where we’re at and then we can make some more conscious decisions about what changes we might want to make post launch.

David (22:55): I think what helps this process from our end is this is not our first rodeo. Basecamp has been around for 22 years. That is an insane amount of time for a software product to survive, to be resilient and change and thrive in that entire period. And during that time, we have done even more radical changes. I mean, the original switch from the first version of Basecamp to the second version of Basecamp was everything up in the air. The data model wasn’t even the same. The features weren’t the same. You couldn’t move one project to the new version without having some slightly lossy interactions there and it was a bit cumbersome. So even though this new version is tremendously better in all the ways, it’s still the fundamentally same data model. So none of the data anyone has in their existing projects is sort of lost or inaccessible or there’s a manual step where you got to move all your stuff and pack it into boxes and all of that stuff.

(24:02): So that has also been a bit of a break perhaps, if you would say that on some of the more complete redesign thoughts you could have when you’re starting a new design process here, that we were not going to do that. We were not going to say, “Well, there’s no more to-dos. We’re just converting everything into cards” or “we’re dropping some of these features.” We didn’t do that in part informed by those earlier transitions. Going from an entirely different code base to an entirely new one is great if you completely reconsider everything. We didn’t have to do that. The original Basecamp 3 chassis, as we like to call it, has been shockingly sturdy, shockingly adaptable, both from a code perspective, as in we’ve not ended up with a big ball of mud. We’ve not ended up with something that’s really hard to change and the programmers hate working in it.

(24:59): That’s a very common affliction for any code base that survived a decade plus. We didn’t end up in that situation, but what’s even more remarkable to me is that the product design didn’t end up there, that we did not end up with a Basecamp where 10 years in, we felt the need to throw out half the ideas we had and just stuff in brand new ones. No, there’s a ton of new ideas that we picked up over that time, but it’s more along that we can bend this existing piece of wood in a new way. It doesn’t have to snap. It is actually a little more like bamboo than it’s like just a two by four, right? There’s some given this. And I’ve found watching that process just riveting, I was like, I didn’t know it would bend like that. When we put out Basecamp 3, the current chassis back in 15, I thought it was going to have the same life cycle as the other versions we’ve done, which survived between three and seven years, I think. And now we’re more than twice that out from the longest lasting prior version we have, which is just kind of remarkable that it goes that way.

Kimberly (26:05): Okay. Well, with that, we will keep you guys posted when Basecamp 5 is nearing completion. For now, it’s pencils down and I’m sure Jason and David will be sharing when they can on their Twitter. Rework is a production of 37signals. You can 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, leave us a video recording. You can do that at 37signals.com/podcastquestion or send us an email to rework@37signals.com.