Rootstrap Blog

Don’t build the best quality possible software

Whether you’re an entrepreneur building a prototype or an enterprise company building a software problem, chances are, you’ll want to build it as fast, cheap, and high-quality as possible. But you know the old saying: you can only pick two.

  • Fast and cheap isn’t high quality.
  • Cheap and high quality isn’t fast.
  • Fast and high quality isn’t cheap.

Yes, it’s a cliché, but it’s a cliché for a reason. Most clichés are true.

But let’s dig deeper.

This cliché rings true due to the nature of value. As a working definition, we can think of “value” as Quality/Price. Even if a product is super high quality, if you paid too much for it, you didn’t get much value. Even if a product is low quality, you might still be getting a lot of value if you paid relatively little for it. Both low and high-quality products can be low or high value — it’s a matter of the math and the ratio of both variable.

With this understanding, we can see how sometimes it makes sense to deliberately choose to build a lower-quality product. Because at the beginning of a project, we need to understand two things in order to make the right choice on the quality and type of product we build:

  1. Minimum quality standards of the company.
  2. Business goals

Let’s go through both of these.

As a company, Rootstrap needs to be accountable for what we build, no matter what. We have a baseline, minimum quality standard that’s high. We employ tools to ensure this like mandatory automated testing, integration with CI servers, zero warnings on multiple static code analysis tools, high scores in tools like CodeClimate, we require the approval of at least two reviewers, and so on. All this, together with a strong team and strong leadership, ensures that any project we build meets these standards. Is it possible for us to build better quality software than what we set as a minimum? Absolutely — but it takes more time, and it may be more expensive.

And here’s where understanding the business objectives of a project becomes so important. As a dev agency, we can build a quick-and-dirty MVP that needs to hit the market ASAP. We can build a mission-critical software platform. We can support a multi-billion corporation that can’t slow down operations. For any of these projects, we need to meet our minimum quality standards — but beyond that, the quality we build depends on the needs of the project. Because with fixed resources, higher quality means more time. Period. There are no shortcuts.

Balance between business goals, speed, and quality

Here’s a very simple graphic that reflects this reality. As a company, we have a minimum standard. However, the project quality standard should be defined based on business goals. This means that:

It’s OK not to build the best possible quality software.

It’s OK not to deliver as fast as possible.

You have to build software that meets your minimum quality standards, produces results at a velocity that’s compatible with the business goals, and is as high-quality as possible within your constraints (team, money, time).

TEAM acronym: Time, Energy And Money
If you have the skillset, how you set your project quality standard is a choice. And that choice is determined by business goals. Do we want to go to market fast to test an idea? Do we need to take our time and build a stable foundation that will last a client decades? It all depends on the business goals of the project.

It’s worthless if you built something with uber-high quality but reached the market too late, lost all the investors, and lost any chance of becoming a sustainable business.

It’s worthless if you built something low quality that made it to the market fast, but after finding a product market fit it couldn’t grow because the architecture didn’t allow it.

Some companies create disposable prototypes, very fast, at low quality, in order to test some assumptions in the market. That’s OK if you know what you’re doing. The problem is that most entrepreneurs keep building on the top of it, and that’s a recipe to shoot yourself in the foot down the road.

We are not that company — we don’t just build cheap, disposable prototypes. We have high minimum quality standards because that’s the market we want to target. But it’s a choice, and we should recognize that.

At Rootstrap, we are not the fastest company building software (which produces poor quality results) or the one that builds the highest possible quality software (which takes forever). We aim to be strategic. We want to know where we stand with project goals and build software at the highest possible quality given the constraints and business goals.

At Rootstrap, we aim to be the company that creates the most value.

As an entrepreneur or company, how you deploy that value is up to you.

Feel free to drop me a line. I’d love to learn from your experience.

Anthony Figueroa, CTO, Rootstrap

Tagged in:, ,


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.