Superintelligence CouncilСовет гения · sim.im

Jason Fried · 2025-06-12 · source ↗ · whole document (5)

When to ship vs. when to keep building

`0:26:50`

to be a great day. I don't subscribe to that either. some days just like are there like, "Oh, this is just one of those days." Fine. I just don't want to have one of those days so many days in a row. How do you prioritize? Like we're we're building an internal tool at our company right now. How do you think about when you're when you should just ship something and get it done and maybe have an imperfect version versus when oh there could always be one more thing that you add, one more thing that you improve and you kind of overthink it and maybe you're actually using as as an excuse to not get it out there like when Yeah, that's a hard I mean it's a great question and and there's no there's no real answer to this uh that's like a scientific answer, you know, that I can

`0:27:36`

tell In every situation, here's what you do. At the end of the day, what I'm going to tell you is very unsatisfying, but it's it's just a feeling. You have to cultivate this feeling for when something is done. You have to first of all, you have to be using the thing that you're building, and that will give you a really good sense of like, does it do what it needs to do? Is there something that's lacking here that really needs to be there that isn't? Sometimes you build features that like you're not going to use very often, but like are just exciting to build and will help round out this concept. Like there's this feature in Fizzy. We're building this new product called Fizzy, which is a a bug tracker, issue tracker, idea tracker kind of thing. And there's this one feature we're going to be adding to the product probably for version one, which really doesn't need to be there. I mean, I'm going to admit it doesn't need to be there, but it's such a cool thing. And it signals that

`0:28:23`

this product can be used in a different way than most bug tracking tools. It's basically a instead of like, you know, it for most issues, you describe the issue, right? you'd write down the issue and every issue and pretty much every bug tracker is text. But if you are um trying to report some issue, let's say I again I go through these like real world projects. So I'm renovating some stuff in my house and I'll do a like there's like an issue with the way this fits or these tiles don't line up or whatever. Like I can describe that and I can also take a picture of that of course and you can of course in all bug trackers describe it and then attach a photo. But I just want the photo to be the issue. I just want a picture of the tiles not lining up to be the issue. And so I want to be able to