In custom software, fast, cheap and good don't all come together, but the popular “pick two” rule isn't quite right either. Quality is the wrong thing to bargain with, because time saved on internal quality soon comes back as slower, more expensive development. The real room to move is scope: what goes into the first version. So we don't ask clients which of the three they're willing to give up. We ask what's fixed for them: the deadline, the budget or the feature list.
Asking for “fast and cheap” is completely reasonable. When you run a business, every week and every euro counts. The trouble starts when the request rests on the assumption that somewhere there's a developer who'll deliver the same thing for less and sooner. Usually you don't get the same thing. You just find out the difference later.
- The classic sides of the project triangle are time, cost and scope. Quality is the outcome of those three, not a fourth slider.
- According to Martin Fowler, skimping on internal quality (tests, readable code, sound structure) doesn't save money, because it slows down everything that comes after.
- DORA's research finds that speed and stability are not trade-offs.
- Adding people to a late project rarely helps (Brooks's law).
- Our process: agree what's fixed, rank scope with MoSCoW, ship in short timeboxes, and write down what we left out.
Where does the triangle come from, and what does it actually say?
The project management triangle (also called the iron triangle or triple constraint) is usually credited to Martin Barnes in 1969, although Wikipedia notes that its exact origins are unclear. Its three sides are time, cost and scope. The idea is that quality is shaped by those three, so if you change one, the others have to move too.
The meme version (“fast, cheap, good: pick two”) simplifies this and turns quality into one of the sliders. That's where we see the trap. If quality is a slider, “fast and cheap” sounds sensible: it'll be a bit worse, but done quickly and cheaply. In software, though, lower quality isn't a one-off concession. It's a debt that keeps accruing interest.
Why is quality the wrong bargaining chip?
In Is High Quality Software Worth the Cost?, Martin Fowler separates external and internal quality. External quality is what users see: does it work, is it pleasant to use. Internal quality is what only developers see: how readable the code is, whether there are tests, how easy it is to change. Fowler argues that internal quality doesn't make development more expensive. It makes it cheaper, because new features ship faster and with fewer bugs. In his experience, a messy codebase starts slowing a team down within weeks, not years.
Ward Cunningham made the same point in 1992 when he introduced the technical debt metaphor. A little debt can speed you up if you pay it back promptly, and the danger is debt that never gets repaid. Every minute spent on not-quite-right code counts as interest.
The DORA (DevOps Research and Assessment) program has measured software delivery performance for years, and its own summary says the research has repeatedly shown that speed and stability are not trade-offs. The teams that ship fast are not the ones cutting corners on quality.
In practice, “fast and cheap now, we'll clean it up later” rarely stays cheap. “Later” usually arrives once the system is live, full of real data, and every change carries more risk.
Why doesn't adding people make it faster?
The obvious way to speed things up is to add headcount. In his 1975 book The Mythical Man-Month, Fred Brooks put forward what we now call Brooks's law: adding manpower to a late software project makes it later. New people need time to get up to speed, and every new member adds coordination overhead. Brooks himself called it an outrageous oversimplification, but the direction holds.
The same goes for “cheap.” A lower hourly rate doesn't mean a lower total cost. If the work takes twice as long, or half of it has to be rewritten, you pay more in the end. That's why we work with a small, stable core team and only bring in partners for well-defined pieces of work.
How do we make the decision with a client?
We don't treat the triangle as theory. It's a question we raise in the first meeting, and we usually work through it in four steps.
1. Find out what's really fixed
Almost every project has one hard constraint. It might be a date (the start of a season, a trade fair, a regulatory deadline), an approved budget, or a set of features without which launching makes no sense. All three are rarely set in stone at once. If they are, it's better to say so up front.
| What's fixed? | What can flex? | Typical situation |
|---|---|---|
| The deadline | Scope | Seasonal webshop launch, campaign |
| The budget | Scope and schedule | A first version to test an idea |
| The feature set | Time | Regulatory compliance, replacing a legacy system |
You may notice that quality never appears in the “can flex” column. That's deliberate.
2. Rank scope instead of haggling over it
We sort the feature list with the MoSCoW method from DSDM: Must have (we don't launch without it), Should have (important, but there's a workaround), Could have (nice if it fits) and Won't have this time. The Agile Business Consortium, which maintains the method, recommends keeping Must Haves to roughly 60 percent of the effort at most, so there's contingency left for surprises.
3. Deliver in short, timeboxed stages
Instead of one long project handed over at the end, we split the work into short stages and show something working and testable at the end of each. That way scope decisions are made along the way, based on real experience rather than a spec written months earlier.
4. Write down what we left out, and why
Every deliberate shortcut gets recorded: what we deferred, what the risk is, and when it's worth coming back to. That's your technical debt register. It isn't bureaucracy. It's what makes it clear, six months later, why the system looks the way it does.
When is quick and simple the right call?
We're not perfectionists. Sometimes a quick, simple solution is exactly right:
- Validating an idea: if you don't yet know whether a feature is needed at all, a clickable prototype or an off-the-shelf SaaS tool is a smarter first step than custom development.
- Throwaway code: a one-off data migration or an internal script doesn't need the same care as a webshop that will run for years.
- A hard deadline with acknowledged debt: if the trade fair date won't move, a simpler solution can work, but only if we agree in advance when and with how much effort it gets cleaned up.
The difference is being deliberate about it. Bad “fast and cheap” is when nobody says what got left out. Good “fast and cheap” is when it's written down and the client makes the call. AI coding tools don't change this logic either. They speed up some steps, but they don't make the decision about what goes in and at what quality. We wrote a separate piece on where AI genuinely pays off.
Frequently asked questions
Is it really impossible for software to be fast, cheap and good?
Not for the same scope. But if you narrow scope to what you actually need, a smaller, well-built first version can be delivered faster and on a smaller budget. The triangle doesn't rule out speed. It rules out asking for everything at once.
What is technical debt, and why am I the one paying for it?
It's the extra effort that every future change costs because cleanup was postponed. The system is yours, so the interest is yours too: slower development, more bugs, more expensive extensions.
Is a fixed-price or a time-and-materials project better?
Fixed price works well when scope is genuinely known and stable. If you'll be learning as you go, staged time-and-materials billing is usually more honest, because you can decide on scope based on real experience. We pick the model together at the start of the project.
How can I tell if a quote is cheap because something's missing?
Ask about testing, documentation, handover, and who fixes bugs after launch and how. If there's no concrete answer, the price probably isn't low. The scope is just smaller than you think.
If you're considering custom development and want to agree early on what's fixed and what can flex, see how we approach custom software development. For a multi-part project (app, webshop and website together), take a look at our G8 Alakváltók case study.