Intro
If you are looking for an apartment in Berlin (or possibly any other major city today), you quickly learn an uncomfortable truth. You can get something cheap, spacious, or well-located, but almost never all three together. If it’s cheap and close to the center, it’s probably small. If it’s spacious and cheap, than you need at least an hour to travel to the city center. And if it’s spacious and central, well, you’ll probably need a second job just to afford it.
Similarly, software engineering is the science of trade-offs. As engineers, we design, build, and ship software — and stakeholders almost always want it fast, cheap, and good. But just like in the rental market, you can only ever pick two. This idea, known as the “Software Engineering Triangle” is a classic model that defines the core constraints we face in engineering.
What is the Software Engineering Triangle?
The 3 angles of this triangle:
- Fast – deliver quickly
- Cheap – keep costs low
- Good – high quality, well-engineered
You can choose any two, but the third one will suffer. It’s not just theory — this trade-off shows up everywhere from startups to enterprise projects.
Fast + Cheap = Not Good
When you optimize for speed and cost, quality almost always suffers.
Real example:
While I was still a student (more on that here), our group of three landed a client through networking who wanted us to build a website. To earn their trust — and make sure we were heading in the right direction — we quickly built a working prototype in just one week and did a live demo.
We reused old templates, hardcoded the data directly into the source, and didn’t bother with unit tests. Technically, it wasn’t great — but it got the job done. More importantly, it showed the client we were serious, and it helped us win the project.
Fast + Good = Not Cheap
If you want something built well and built quickly, you’re going to need experienced people and solid tools — and that comes at a cost.
Real example:
At one of my previous jobs, we had to ship an MVP in just 8 weeks. To make it happen, we nearly doubled the team — bringing in senior contractors, designers, and testers.
It worked: we delivered on time and with good quality — but because we threw money at the problem.
Good + Cheap = Not Fast
When money is tight but quality matters, time becomes the only thing you can afford to spend. This is typical in side projects and open-source work.
Real example:
One of the first real projects I ever shipped was completely free. I was a solo developer, still early in my learning journey, and trying to figure things out as I built. I made it work, and the quality held up — but it took time. A classic case of good and cheap, but not fast.
Wrapping up. Why this matters?
Understanding the triangle doesn’t just help you build better software — it helps you communicate better. It sets clear expectations with stakeholders and helps avoid burnout. Whether you’re building an MVP, scaling a startup, or freelancing on the side, you’re constantly choosing between fast, cheap, and good.
Instead of chasing all three goals, acknowledge the trade-offs and choose the two that matter most for your case.