Fast, cheap, good: you can now pick all three

Fast, cheap, good. Pick two. Everyone who has ever paid to have software built has heard some version of that line, usually from the person about to invoice them.

It no longer holds. You can have all three on the same piece of work now, and I mean actually have them, not have two and a story about the third. What has not gone away is the trade-off itself. It moved, and where it moved decides whether you get all three or none of them.

What the triangle was really describing

The old rule was never a law of software. It described one particular way of making it. A group of people, typing, coordinated by process. Everything the triangle claimed followed from that. Going faster meant adding people. More people meant more coordination, and coordination is where mistakes come from, so quality slipped. Protecting quality meant slowing down. Cost tracked headcount multiplied by elapsed time, so pulling one corner straight always bent another.

Read it that way and it stops being a constraint on software and becomes a constraint on hand assembly by committee. Change the shape of the team and there is no reason to expect the rule to survive.

What changed

Two things collapsed at once, and they were the two things holding the triangle up.

The first is how much one person can produce. In 2026, two senior people working with AI agents ship what a team of six to ten used to ship, in production, at the same quality bar or better. We wrote about that when we launched, because it is what killed the billable hour for us.

The second is the coordination tax. A team of eight needs daily ceremony to know what each person is doing. A team of two does not. When the team is small enough, most of the process that existed to synchronise people has nothing left to do. The overhead that used to eat the schedule goes with it.

Take away both and there is not much of the triangle left standing.

All three on one job

A client in building safety had specialists spending five days matching hundreds of technical requirements to certified products and pricing each one. Regulated work, where a confident wrong answer is a legal problem and a safety one. One senior builder took it from a standing start to production in under two weeks. It cost roughly a quarter of what a traditional engineering build of the same thing would have cost. In testing it reached the same conclusion as the client’s own experts 95% of the time. Every answer carries the inputs and the reasoning behind it, which is a record they could not produce before.

Fast, cheap and high quality, on one job, in a setting with no tolerance for a corner cut. And the quality was not a happy accident of the speed. Speed came from doing the thinking properly up front, encoding the expert logic into rules rather than skipping straight to code. You can read the full case study.

The constraint moved, it did not vanish

The binding constraint on a software project is now the quality of the decision about what to build.

When building was slow and expensive, a poor brief was survivable, because the slowness gave you months to notice and correct. Now the build is quick enough that you can be finished and wrong before anyone has questioned the brief. Speed without judgement gets you the wrong product sooner and for less money, and that is not a saving.

So the question worth asking a supplier has changed. It used to be how many people and how long. It should now be who is deciding what goes in, and what happens when they turn out to be wrong. Cheap, fast and good is available to whoever can make that decision well. Whoever cannot will pay the old price and get the old result, with better tooling.

Where pick two still holds

The compressible part of a project got much cheaper. The incompressible part did not, and on a lot of work it is now most of the timeline.

• Getting a room of people who all want different things to want the same thing moves at human speed. No agent has ever shortened that.
• Regulated sign-off, security review, clinical or legal review, procurement. None of it speeds up because your build did.
• Putting something in front of real users and finding out what they actually do with it takes as long as it takes.
• If what you want keeps changing, you are paying for time again, whatever the pricing model on the contract says.

There is also work where the old rule holds outright. Deep legacy estates, or anything where the difficulty is archaeology rather than construction. We will tell you when that is what you have.

If you are buying bespoke software this year

Start from the outcome, not the software. What you are paying for is a result, like work that took five days now taking twenty minutes. Bespoke software is how you get there. How many people build it, and for how long, is not yours to specify.

So stop scoping by team size and duration, because both are now weak proxies for what you are getting. Ask for the outcome, and a fixed price for that outcome, and let the supplier’s team shape be their problem. If you want the longer list, we wrote down the questions worth putting in an RFP separately.

Then spend the effort you used to spend arguing about the estimate on the decision instead. Getting the brief right is where the money is now. If it turns out you were wrong about what to build, finding that out is far cheaper than it used to be. That is the part of all this I find genuinely useful.

This is how we work. If it sounds like what you need, start a conversation.