Good, Fast, or Cheap: Pick Two

Good, Fast, or Cheap: Pick Two

When it comes to building products (or anything, really), there is an old saying: You can build it fast, cheap, and high quality, but you can’t have all three at once. You can have all three eventually, but the first version of the product can only be two of the three.

It’s just not possible, without killing our people off, to build products quickly, inexpensively, and top notch quality. Each of the different combinations of “cheap, fast, good” has an appropriate time and place. None are inherently bad. Our job, as managers and leaders, is to recognize what the business needs right now, and make sure that our teams are focusing in the right areas.

Good, Fast, or Cheap

If we need to get something out to market quickly, we don’t have the time to refactor our code a dozen times or have perfect unit tests in place before we ship. Likewise, if we’re building mission critical systems, we can’t afford shoddy work. Depending on the budget and number of people available, we’ll either have to go with “fast and good” or “cheap and good”.

To add some context, here are a few situations where each combination is appropriate.

Good and Cheap

It is definitely possible to build a high quality product on a shoestring budget, if you have enough time on your hands. Its perfectly viable (and sometimes necessary) to choose this route when first starting out. This is often how bootstrappers or hobbyists get started. The danger for bootstrappers is focusing too much on the “good”, without being sure that what they are building is actually what customers want.

Even products in mature companies need to be careful about choosing “good and cheap” over “fast and cheap”, when it comes to first testing out their ideas. Just like bootstrappers, they run the risk of taking too long to deliver a first version of their product before their project gets the axe for taking too long (or your people being pulled away for a “more important” project.

“Good and cheap” is best suited for projects where it is critical that you get it right the first time, and where you have limited resources. “Good” is synonymous with “high quality”, so things like proper testing, scalability, and reliability are baked in. “Cheap” in this case refers to few resources (people and hardware or equipment) to get the job done. It is best for situations where you feel more pressure to get it right versus get it done.

Good and Fast

If you need to get something done quickly, but it also must be the highest quality, then “good and fast” is what you’re looking for. The problem with “good and fast” is that it is what bosses are usually asking for. Our job is to help them understand that “good and fast” doesn’t come cheap. Its not necessarily a matter of having more cooks in the kitchen either. Often, adding more people to the mix can slow down progress rather than speed it up.

“Expensive” may mean that you have to take your best people off of another project to make this one happen. It may mean throwing more expensive hardware at a problem. It may mean adding more people and dividing up responsibilities so that people only focus on what they know best (for example: rather than the team owning QA responsibilities, you have a few individuals that do nothing other than write unit or automation tests).

Good and fast is not fun, but it is often necessary. When you’re competing against an established competitor, you often have to attack them with a superior product, before they have time to react. Its expensive, but sometimes it buys you time to take care of the other things later on.

Fast and Cheap

If your boss just needs something done quickly, he’s probably asking for “fast and cheap”. It comes at a substantial price though: lack of quality. This is not a knock on the caliber of people working on the project, however, and it is our responsibility to communicate this clearly when we are asked to deliver something “fast and cheap”. This approach often comes with the cost of higher support needs and lower customer satisfaction later on.

If you’re in the learning phase of building a product, this approach is idea. Building an MVP or proof of concept should be “fast and cheap”, because you don’t want to waste effort on anything that isn’t going to pan out.

It is technically possible to build high-quality products, quickly, on a shoestring budget, but you run the significant risk of burning your people out very quickly. Sometimes, when stakes are high and the business or product is at risk, it is necessary to push our teams to the limit for the sake of survival, but this should never be taken lightly. In fact, it should be an absolute last resort. It is not sustainable, and you will lose people over it.

There are only so many hours in the day, and quality takes time. You have to ask yourself if delivering a high quality feature quickly (and on an impossible budget) is worth the cost to morale and perhaps some of your best people. Sometimes, for the sake of survival, it is… but you had better make darn sure that you can explain why you are going to be asking your people to do the impossible. It had better be worth it, and it had better pay off, or your reputation will be history.

Our job in general, is to remember the reality of “good, fast, or cheap” and decide what you need right nowIf you go with “fast and cheap”, that doesn’t mean you can’t improve the quality later, once you know that the thing is worth keeping around. If you aim for “good (high quality) and cheap”, that doesn’t mean that you can’t add more resources later and move faster. What you have to decide and communicate is what does the product and company need right now.

This is a concept that will be forgotten time and time again by the leadership above you. You will have to be patient and seek to understand what it is they’re really looking for, and what they can wait on. This is something that you must always be on the lookout for, because if you don’t, your poor teams will try to deliver on all three, burning out in the process.

You May Also Like...

If you like what you see, sign up below to get additional insightful and thoughtful posts right in your inbox.

Spam sucks. We won’t abuse your trust. Unsubscribe with one click at any time.

Howdy. Glad you're here! A word of advice: If you’re looking to pick a fight in the comments, don’t bother. I welcome disagreement because it encourages healthy discussion, but I’m not going to allow personal attacks or angry trolls to distract from the message.


  • Nick says:

    To your last point about seeking to understand what your leadership wants, I think it’s equally as important for them to understand where you’re coming from and to set realistic expectations for completing the work. Yes, they will forget time and time again, but it is your job to remind them. You are the advocate for your team and the one they are relying on to communicate their point of view. If leadership is expecting the project to be fast and good, they need to know (i.e. don’t assume they know) that it will be expensive.

Leave a Reply

Your email address will not be published. Required fields are marked *