Is it possible to develop a good product cheap and fast? In short: no. But some sacrifices are bigger than others.


Peter Lukacs

Should you go for cheap, fast or good when developing products?

Surely we’ve all seen the sign, on the wall of a colleague’s booth or the corner car repair shop, that says: “We offer 3 kinds of service: good, cheap and fast. You can pick any two.” And probably smirked at it, too. What most people don’t know – or won’t accept – is that this snappy social commentary points to an age-old dilemma for product developers and clients alike.

When it comes to digital product development, there are three ways this can play out:

  1. You want it good and cheap: Hope you’re not in a hurry. More often than not, ‘good and cheap’ translates to longer lead time and low priority.
  2. You want it good and fast: You’re clearly a perfectionist. And a lottery winner. But mostly the second.
  3. You want it cheap and fast: Did you lose a bet and have to put this app out, no matter what? Then 100% recommend.

Here at Digital Natives, this gets even trickier because ’good’ is something we rarely, if ever, compromise on. We don’t do short-cuts and half-baked solutions, even if our client wants us to. Because guess what. That’s not what they want either. They just don’t know it yet.

So why should you take quality out of the equation?

Or rather, why leave it in? To answer this question, let’s have a closer look at all the variables in the dreaded time-material-budget triangle.


The general consensus about budgets is that it’s not how much you spend what matters but how you spend it. In software development, this is especially true. Take this example, that happened with us more than once so far: a client approaches us with a product idea and asks for a price quote. They collect a bunch of other bids, do the math and eventually sign off on a more wallet-friendly option. Then a year later they call and say something along the lines of ‘Well, this didn’t work out the way we’d thought it would”. Here are some hard lessons learned: the client has spent at least 30% of their budget and had to push back their go-to-market timing with 12 months easy.


Aka, in our case, ‘feature set’. Let’s take start-ups, for example. They usually have a very, very fixed budget, a great idea for a product and a whole list of features it simply must have. Now even if we’re just as excited about said great idea, we don’t rush back to our desks and start coding. We first do our homework: carry out UX research, pitch it to users and run business value scoring. And if we’re not sold on it, we’re not doing it, period. Here’s the thing, though: fewer features don’t equal low-quality. This is why the whole concept of the Minimum Viable Product, or MVP, came to be. Once we have the features users love, plus the client wants and can afford, we’re good to go.


Time pressure can be a real head-scratcher in digital product development. A start-up might be in a hurry because they want to beat competitors. At the same time, the main function of their MVP is often just to test the waters with users. Meaning that ‘perfect but slow’ is not exactly what they’re going for. Established businesses, on the other hand, are a whole other story. They often come to us with an application idea that has sprung from an actual business need they’ve identified. And they want to cater to that need fast.

So whatever you decide to compromise on, get ready to make some tough decisions. And if you’re on the development end, communicate. What we always do is cutting to the chase. We tell clients straight whether their product is viable or not, what it must be able to do for optimum performance, and how much it’s gonna cost to make it happen.

So what are you ready to sacrifice?

Related posts