Good, Fast, Cheap — Pick Three

There's a sign that used to hang in every print shop, every auto body repair place, every freelance designer's office:

Good, fast, cheap — pick two.

It was true for a long time. Quality took effort. Speed took money. Saving money meant cutting corners or waiting longer. You could optimize for two of the three, but the third one would suffer. That was just the nature of work.

I don't think it's true anymore.

What Changed

I'm a software engineer. I've been building software for decades — enterprise systems, internal tools, complex platforms, the works. For most of that time, the triangle held. You could ship fast if you threw bodies at the problem, but the code would be messy. You could ship clean if you took your time, but clients got impatient. You could ship cheap if you cut scope, but then nobody was happy with the result.

Over the past year, something shifted. I started building with AI as a core part of my workflow — not as a toy, not as an autocomplete, but as a genuine force multiplier for the entire development process. Architecture, implementation, testing, documentation, deployment. All of it.

The triangle collapsed.

What It Looks Like in Practice

I recently built a full-stack enterprise application as a part-time contractor. Multiple interconnected apps, authentication, workflows, the whole nine. The kind of system that would normally take a team of engineers several months.

I did it part-time. Ten hours a week.

And I don't mean I shipped a throwaway prototype. I mean working software with type safety, state machines for business logic, and a deployment pipeline. Software that stakeholders could actually use and provide feedback on.

Was it fast? Part-time, shipped in weeks instead of months.

Was it cheap? One person instead of a team. Do the math.

Was it good? Good enough that it accomplished exactly what it was built to do — validate requirements, surface edge cases, and inform the next iteration.

The Misunderstanding

Here's what people get wrong: they hear "AI-assisted development" and think "vibe coding." They imagine someone typing vague prompts and getting spaghetti code that works once and falls apart under scrutiny.

That happens. It happens a lot, actually. But it's not an AI problem. It's a discipline problem.

AI doesn't remove the need for engineering judgment. It amplifies whatever judgment you bring to the table. If you bring no structure, you get chaos faster. If you bring strong opinions about architecture, type safety, and testing — you get quality software faster.

The engineers who are struggling with AI are the ones trying to use it like a magic wand. The ones thriving are the ones who've figured out that AI is more like a power tool. Incredible force multiplier, but you still need to know which direction to point it.

Quality Is the Cornerstone

I want to be specific about what I mean by quality, because it's the most important part of this and it's the one people hand-wave away first.

Quality is not a luxury. It's not the thing you sacrifice to go fast. It's the thing that lets you go fast.

When your data models are defined as strict schemas, AI can't hallucinate invalid shapes. When your business logic lives in state machines, impossible transitions don't compile. When your linter catches mistakes before they reach a human reviewer, the feedback loop is measured in seconds, not days.

Quality is what makes speed sustainable. Tech debt isn't speed — it's deferred failure. Every shortcut you take today is a wall you'll hit next week. I've seen "fast" teams spend months untangling the mess they created in their first sprint.

The teams that actually move fast are the ones where the codebase is clean enough that changes are safe, reviews are quick, and deployments are boring.

Speed Comes from Iteration

Speed isn't about typing faster or generating more code. It's about learning faster.

Each iteration compounds understanding. You build something, put it in front of people, learn what's wrong, and rebuild with better knowledge. The cost of each cycle has plummeted. What used to take a sprint to prototype now takes an afternoon. What used to require a meeting to scope now requires a conversation with an AI that can read your entire codebase.

This means you can afford to be wrong more often. You can try three approaches and pick the best one instead of agonizing over which approach to commit to before writing a single line. The risk of experimentation has dropped to almost zero.

That's the real unlock. Not "AI writes code for you." It's "the cost of iteration is so low that you can afford to learn by doing instead of learning by planning."

When We Iterate, We Improve

This is the fundamental lesson. It sounds obvious, but most organizations don't actually believe it.

They believe in big upfront design. They believe in architecture review boards. They believe in six-month roadmaps and detailed specifications and meeting-heavy processes that exist to reduce the risk of building the wrong thing.

But the fastest way to reduce the risk of building the wrong thing is to build something and find out. When each build costs a fraction of what it used to, the calculus changes completely. Why spend two months specifying when you could spend two weeks building and learning?

Every cycle builds on the last. The first version teaches you the requirements. The second version teaches you the architecture. The third version teaches you the edge cases. By the fourth version, you're shipping something that would have taken the traditional approach months to even scope.

The New Triangle

It's not "good, fast, cheap — pick two" anymore. It's:

Quality. Speed. Efficiency. They compound.

Quality enables speed because clean code is safe to change. Speed enables learning because you see results sooner. Learning enables quality because each iteration is better than the last. Efficiency is the natural result of a tight loop between building and learning.

They're not trade-offs. They're a flywheel.

What This Means

For companies: the team that figures out how to work this way will outpace everyone else. Not by a little. By a lot. The gap between "we need six months and eight engineers" and "one person shipped this in ten weeks" is getting harder to explain away with architecture diagrams.

For engineers: the skill that matters most right now isn't knowing a particular framework or language. It's knowing how to build systems that are structured enough for AI to operate within them safely. Strict types, clear boundaries, automated validation. The engineers who are building that muscle memory today are compounding an advantage that gets wider every month.

For everyone: the old constraints are dissolving. Quality, speed, and cost are no longer at odds. The question isn't which two you want — it's whether you're willing to work in a way that gets you all three.

We help companies ship quality software at speeds they didn't think were possible. If that sounds interesting, [tell us about your project](/#chat).