← All Episodes ← Prev Next →
SEASON 2 - EPISODE 176 - DECEMBER 10, 2025

When is enough, enough?

Listen now

There’s a moment in every product where you have to stop tweaking and actually launch. This week, Jason Fried and David Heinemeier Hansson reflect on how 37signals decides when a product is truly ready for its first release. They share how they think about simplifying, sharpening, and ultimately knowing when it’s time to ship.

Watch the full video episode on YouTube

Key Takeaways

  • 00:12 - Recognizing when a product is ready to meet the world
  • 02:55 - Strip things back to the essentials first
  • 07:32 - Weighing real-world feedback from early users
  • 10:03 - Add the final layer of polish without overdoing it

Links & Resources

Sign up for a 30-day free trial at Basecamp.com

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m your host, Kimberly Rhodes, joined as always by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. We are putting the finishing touches on a product called Fizzy. It actually might be out by the time this podcast episode is live, but I thought we would talk a little bit today about how we know when it’s done. You could continue building and polishing and tweaking forever, but at some point you have to rip the bandaid off. I think that’s probably a challenge a lot of people find themselves in. So let’s chat about it. Jason, I know there’s a lot happening in the product in these final hours, final days. When do you stop?

Jason (00:42): I’ve been thinking about this a lot actually, because I’ve been trying to visualize the way to explain this. Other people have asked me this because they usually go, well, you just kind of figure out what you use and what you don’t and then you stop and there’s some of that, but it doesn’t really tell a story. The way I’ve been thinking about a recently is I want version one to be the most aerodynamic version of this thing that we’re making.

(01:02): In that, every little extra thing sticks out. It just sticks out of this object and screws up the airflow. So version one should just be extremely aerodynamic. What is the tightest, smoothest shape of a product we can make? That’s kind of how I tend to think about it now, or I’ve been trying to think about it that way now. And so part of this is when you use something that you’re building and you go through it and you keep going through it as you near the launch, you’re like, do we need that little thing? Is that thing creating drag? Do we need that? And you try to get rid of all the little burrs and all the little things that are just getting in the way, and that to me is how you do it. So it’s about smoothing this object out. Not saying that we can’t add stuff later, but version one has got to be very, very aerodynamic. So that’s how I’ve been thinking about it.

Kimberly (01:51): I love it. Put Fizzy in a wind tunnel.

Jason (01:53): Kind of, you know, when you think about it that way. David brought up something about we have this feature called saved views or saved filters basically. And he asked, you know hey, how many people are using this? And there’s only a few people using it, and I think it’s a nice thing to have, but I actually at the last minute here, I’m wondering, do we need that? Is that a bur? Is that creating drag? Do we need it for V1? And there’s been some other things that have come up that I know we want in the product, but we don’t need it for V1 necessarily. It’s just going to create drag. It creates more surface area. And I’m just trying to think about things in terms of a physical object because I think it’s easier to visualize what that physical object would be, would look like. The software is so virtual that it’s very, very hard for people ultimately to visualize because you can just keep shoving stuff in there and there’s no natural pushback. But if things are sticking out and you imagine it in a wind tunnel, you’d see that white fog or whatever, you’d see the wind and you’d go, ah, that’s sticking out. We got to get rid of that. So that’s my take.

David (02:55): This harks back to one of the very first principles we pinned down on product development, which is half, not half-assed. That the half that’s left after you smooth everything out is invariably likely to be better than if you have a bunch of stuff that you didn’t have time to smooth it all out. That is all a little rough, and I often look at these products that managed to do that half, not half-assed thing, which is such an admiration. Jason, in fact, you wrote about the Concept 2 rower I think last week, which a perfect distillation for me. Anyone who didn’t know it, look it up afterwards. It’s called the Concept 2 rower, and it basically dominates the home high-end exercise equipment for rowers. If you’re into that stuff and you’re not using water, and it’s just a product that has barely changed in I don’t know how long they’ve made it, I think at least 20 years or something like that.

(03:54): It has this LCD screen on it, not a fucking touch pad, an LCD screen with big fat rubber buttons that you have to press. You can press when you’re both sweaty and exhausted and whatever and just doesn’t do that much. It’s just high quality, no accessibly, high quality, not luxuriously, high quality, just really well made and very few parts, and then some thoughtful little touches like the way you can lift it up and it has wheels on the front to easily move it. And these other aspects where I’ve tried a lot of exercise equipment and very little of it, especially these days, feel like it has the Concept 2 quality to it. So when Jason was blogging about it, it was like, yes, that’s exactly it. Can we make software products that feel like it’s a Concept 2 rower? Where it doesn’t do more than that.

(04:48): In fact, so many of the things that I end up really enjoying comes from that simplicity of it. There’s a bunch of different domains too where actually having to work a little harder to be able to accomplish some things is part of the enjoyment. I’ve been shooting Leica cameras for many years. They don’t have auto focus, which is something I think most people certainly these days would take as an essential feature of a camera. What do you mean I have to move this little lever otherwise the picture isn’t in focus? That sounds pre historic or barbarian. And then you use it and you use it and you like, oh, huge part of the appeal, the joy of shooting a Leica camera is exactly the absence of all of this, the absence of menus, the absence of auto focus, the absence of a million other things. And I think it requires actually a fair amount of arrogant conviction to go like, you know what?

(05:41): I know we’re going to get, we requests for all these different things. We know it already. I mean, you don’t even have to say anything. We could fill out a top 10 list of what people are going to ask for and we’re not going to ship with that. V1, the aerodynamic version, the Concept 2 version, the just less version, the manual focused version. The other thing, and we’ve shipped a lot of things over the years, including HEY which we shipped about five years ago. There’s several things in HEY that I look back upon now and think like, man, we should just smoothen that out. Jason, you remember the Magic Door, the magic key? You had a special email address that could get around your Screener.

Jason (06:20): Speakeasy Code, yeah.

David (06:21): Speakeasy code. Now the problem with that feature was it had such a good name that it was almost a darling too cute to kill, and therefore we couldn’t get rid of it. But I’ve never used the speakeasy code. I don’t know if you’ve ever used it.

Jason (06:34): Nope.

David (06:35): But it was one of those things that you get excited about at the moment, and then you look back upon it after and we’re like, oh man, we could have smoothened that out. And then there are other aspects of the feature sometimes that feels like it’s such a simple thing that turns into basically be the thing, the major thing. We were quite late into the development of HEY before we came up with the Screener.

Kimberly (06:54): Oh!

David (06:54): which is now perhaps the single most defining feature of HEY. There’s a million things that work together in beautiful harmony, but whenever I tell people about HEY, I always explain the Screener first, that no one gets to reach your inbox unless you’ve said you want to hear from that person. It’s a very simple concept. It was not something that was difficult or hard to make, but it was essential to it, and you actually accentuate some of those features more, the few things, a handful of unique elements if you take all the other stuff away.

Kimberly (07:32): Okay, so a couple of weeks ago we talked about bringing in some beta testers or early adopters into Fizzy before the public launch. Tell me a little bit about getting feedback from those folks and then deciding whether to move forward with that feedback or like, okay, that’s a V2, we’re ready to launch with V1 version.

Jason (07:51): Yeah, I mean, we’re getting a good amount of feedback from people, and some of it is stuff that we know. Yeah, it doesn’t have that. We know it doesn’t have that. And maybe down the road it will, but right now it doesn’t. And that’s getting back to the what is the smoothest version of this? What does it really need to have? That would be nice to have. It doesn’t need that though. What’s been interesting, I was talking to Brian about this yesterday, so one of the really interesting things about Fizzy is, so it’s a Kanban tool. Basically every other Kanban tool I’ve ever seen has all the columns open all at the same time. All the cards revealed all at the same time. That’s like what Kanban historically is. With Fizzy, you can only have one column open at a time. The other ones collapse, and this seems like it could be controversial. I believe in it very strongly. I’ve been pushing for it and I really like the way it works. He was surprised that no one who’s been beta testing has complained about it.

Kimberly (08:39): Interesting

Jason (08:40): Because it is such an unusual approach to Kanban, and it would be the natural first thing for people to say, why can’t I open two columns at once? Technically, you have two at once. You have the maybe column which is always open, which is another thing that other Kanban tools don’t have. Anyway, long story short is we made this very conscious distinction between open, closed one at a time kind of thing. And it seems like it would be the controversial thing. So far though, it has not been. It might be when the public gets in, 20– 50– 100,000 people try it, but so far not come up once. And then it’s usually the things that come up are these little nitpicky things, which are totally fair game for anyone to notice because I’ve noticed them too. It’s just we’ve decided not to do them. But most of the beta feedback initially is not about mining for new features. It’s closing little gaps, little holes, busted things that we didn’t know about. It’s making sure that our house is in order prior to opening it up to everyone else, that kind of thing. And that’s been now working out quite well so far. I think we’ve invited maybe six or 700 people at this point.

Kimberly (09:40): Oh, that’s a lot.

Jason (09:41): Yeah, I mean, we invite them in. People sign up, we invite them in. You get a fraction of those people actually signing up. But we’ve sent about six or 700 invites so far.

Kimberly (09:50): Okay. David, on the technical side of things, are there other things that you’re considering of like, nope, we’re not ready, versus this can wait, we can make this tweak to the code later?

David (10:02): It’s interesting because Fizzy in particular, we had a mission to try some really novel new architectural ideas out, and we actually ended up yanking them in the 11th and a half hour. Just before launch some of the audacious ideas we had on the database side of things, we got a little cold feet. And I think it’s one of those magic things that happen when you just before launch, just before launch, you look at some of the features you were having and go like, do you know what? We should get rid of them before we launch, or it needs this thing, otherwise it’s not ready. It’s not as common that that happens on the backend, on the technical side of things. But in this instance, we had had this audacious science project-y, requires a bunch of new tech approach to some of the database stuff where it just wasn’t ready.

(10:56): We did not have high enough confidence that it was going to go off without a hitch, and we did not want to take that chance, even though we had spent an awful lot of time working on it. Now that doesn’t mean we can’t bring it back. It doesn’t mean we can’t take some of the ideas in. But in the 11th hour, we actually pulled the plug on an audacious way of doing it and went back in some ways to something that was just a little more tried and true, mixed into some of the insights we had picked up along the way working on this other novel stuff. But that’s a key part of it. The other thing for me is I’ve been reading through the whole Fizzy code base. We’ve had a wonderful team working on it. I have not been writing the majority of the code.

(11:36): I did some of the early work on it, and then I did a bunch of other things for a long time and the team did great work on it. And then I get the privilege of sitting down and reading this thing like it’s a book end to end and just going like, oh man, I really like this. You know what? This part maybe could use a little do over. And I love that polishing, that editing phase. It’s like when in the rare circumstance, I have the patience to put an essay aside instead of just fucking hitting publish on HEY world as soon as I’ve written the last character, which is my normal M.O., if I occasionally leave it for the next day, I always have edits and I always make the essay better. It’s just my impatience wins out over my perfectionism.

(12:18): But in this case, it was forced upon me. So I get this privilege of doing this editing phase where I can just carefully massage a few lines of code. In fact, just a few days ago, I had the really satisfying experience of clicking with a wart that I did not like, and I had looked at it a couple times over the few months. I was like, I really don’t like this. Oh, it seems like such a long way around to fix this problem because I don’t like four lines of code. So I’ve been noodling on it for literally months. And then the epiphany as it often is, just arrived in the shower. Oh, I could just do the, and I go into the keyboard and I do the thing and I have this little commit that says minus seven lines plus two. And you know what?

(13:03): It’s funny how these things can be so satisfying. You think this is a code base of thousands of lines of code and you’re getting excited about five lines of code you were able to remove. Yeah, I do. I really do. It’s about that smoothening aspect of it. The code has drag in very much the same way as the product itself does, and you can see that smooth surface. Sometimes, in fact, when I’m reading these things, a favorite tactic, it’s, you know what? I lean back and I halfway squint at the code and sometimes I could just see, you know what? That’s not the right shape. There’s just too many lines up here in this method, and it’s using too many other things. There’s too much indirection. Where’s this getting referenced from? I don’t have this piece of context now that I’m reading it, that needs to be better.

(13:51): And the act of polishing and massaging the code in this way is actually one of my favorite parts of writing code at all. Making any kind of product is exactly this phase where you’re just going, you look at it and then you smooth it out a little more and then you look at it again, and then you go like, yeah, right there, right there. There’s not a character. There’s not a comma. There’s not a colon that I could move inside this piece of code that would make it better. So satisfying, so satisfying, in fact, so satisfying that I would posit, that this is the main reason I still bother programming. At this point I’d say, you know what? I’ve written enough programs. I’ve been writing programs for damn well 25 plus years. I don’t need to write another piece of program. I do need to smoothen programs and therefore we must write new ones or occasionally bring out the old ones and they just keep smoothing them, make them more aerodynamic, make them more of a pleasure to read.

(14:52): I dunno why it is. I do know there are other programmers who share this satisfaction of deleting lines of code rather than putting them in. And then there are other programmers entirely who just get excited about solving problems. And I, over the years, I’ve gotten more excited about the polishing than I have necessarily about solving the problem. And part of it is because we’re solving problems in recurring ways. Much of what we do is an embrace of the crud monkey identity. We write to a database. We read from a database, we update a database, we delete a record in the database. That’s it. And that’s enough. That’s enough. That problem is able to then power the solution to that problem is able to power something as beautiful as Fizzy. I was looking at it at Fizzy a few months back after I hadn’t looked at it for a couple months, going all in on Omarchy, and it just kept finding these little touches. One of the things, I don’t know, we have a couple of Easter eggs and some of them include sound and the one Easter egg I found or didn’t find, but was instructed to look for with the sound. I just went like, isn’t that delightful?

(15:58): We’re little crud monkeys dancing here in the background, doing the little monkey dance for the create and update and delete, and then there’s a fucking harp playing in the background from what we built. How is that not just the most amazing thing you’ve ever seen? These are sort of those small joys for perhaps some of it is literally getting older and smelling the flowers. I used to think of it as cliche, like, stop and smell the flowers. You know what? I fucking stop and smell flowers now. I look at trees and I go like, man, that’s a beautiful tree. I wonder how old that tree is? And part of it is like I have this recurrent model going, do you know what? If you were 20 year olds, you’d laugh at yourself right now? And the other part goes like, yeah, that’s right. That’s the process of aging. You start appreciating new things, different things. And I now appreciate trees and I appreciate smelling flowers, and I really uniquely appreciate polishing code.

Kimberly (16:56): I think that’s the first mention of the Easter Eggs in Fizzy. So I’m excited when people actually find them.

David (17:01): I didn’t fully reveal it, I just said, sound, harps, music.

Kimberly (17:05): I love that. Well, with that, we’re going to wrap it up. REWORK is a production of 37signals. You can find show notes and transcripts on our website, 37signals.com/podcast, full video episodes 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 question. You could do that at 37signals.com/podcast question. You can also send us an email to rework@37signals.com, and I’ll link in the show notes to the new Fizzy product.

This is an episode title

00:00 / 00:00