"Good enough" is used as an insult. Say a system is good enough and it sounds like a shrug, a settling, an admission that you gave up before you got it right. In most enterprise technology conversations, the phrase is something you defend against, not something you aspire to. Nobody puts "we built a good enough system" on a slide. They put "best in class."

This is a costly confusion, because in the disciplines that have studied the question most carefully, "good enough" is not the lazy answer. It is the rigorous one. The pursuit of the perfect system, the endlessly customized, fully optimized, every-edge-case-handled ideal, is one of the most reliable ways to waste money, time, and organizational energy on technology, and what sinks most enterprise software projects isn't a lack of ambition: it's too much of it. Learning when good enough is genuinely the right call, and being able to tell it apart from mere corner-cutting, is a leadership skill worth more than most of the perfection it declines to chase.

Good enough has a Nobel Prize behind it

The idea that "good enough" is the intelligent choice is not a rationalization invented by tired project teams. It is a formal concept with a serious intellectual pedigree. The economist and cognitive scientist Herbert Simon won a Nobel Prize in part for the idea of satisficing, the observation that in a real world of imperfect information and limited time, decision-makers who choose an option that is good enough to meet their needs consistently outperform those who insist on searching for the optimal one. The search for perfect has a cost, and past a certain point that cost exceeds anything the perfect solution would have added. Choosing good enough is not giving up on optimal. It is recognizing that optimal is often not worth what it takes to reach.

Engineering formalized the same insight as the principle of good enough: development should stop once the core requirements are genuinely met, because continuing to chase a perfect solution yields diminishing returns and incurs opportunity costs that outweigh the marginal improvements. The computer scientist Donald Knuth put the sharpest version of it in the context of optimization, warning engineers to forget about small efficiencies the vast majority of the time because obsessing over them early causes more problems than it solves. The people who understand systems best are not the ones who chase perfection. They are the ones who know precisely when to stop.

What chasing perfect actually costs

The reason this matters for a leader is that the pursuit of the perfect system does not fail quietly. It fails expensively, and usually in ways that get blamed on something else.

It shows up as over-customization, the endless tailoring of a standard platform to handle every exception and match every preference, which produces a fragile system that costs far more to maintain than the standard platform ever would have. It shows up as over-building, teams constructing capabilities for scale they do not have and futures they cannot predict, solving problems they do not yet have at the expense of the ones they do. It shows up as the project that will not ship, refined and re-refined in pursuit of an ideal, while the good-enough version that could have been delivering value a year ago sits unfinished. The engineering literature has a name for the phenomenon of working past the point of diminishing returns, gold plating, and it is consistently identified as a driver of higher total cost of ownership, worse usability, and greater maintenance burden, not a mark of quality.

None of this looks like a mistake while it is happening, which is what makes it dangerous. Each additional refinement, each extra bit of customization, each anticipated edge case feels like diligence, like doing it properly. The perfectionism hides behind the mask of doing it right. But the accumulated weight of all that "doing it right" is a system that costs more, breaks more, and ships later than the good-enough version that would have served the business perfectly well, and the organization is usually years and millions in before anyone names the actual cause.

The honest line: good enough is not a license for negligence

The phrase can, of course, be abused, and a careful reader should be suspicious of anyone selling "good enough" without a standard attached, because the same words that describe disciplined pragmatism can also excuse genuine corner-cutting. There is a real difference between good enough and not good enough, and the discipline collapses into an alibi the moment it stops meaning "meets the actual requirements" and starts meaning "we stopped caring." A system that fails to meet real business needs, that is unreliable where reliability matters, that cannot support what the operation genuinely requires, is not good enough. It is inadequate, and calling it good enough is exactly the lower-quality justification that critics of the principle rightly warn against.

So good enough is not the absence of a standard. It is a precise standard, honestly applied: meet the real requirements fully, and stop. The skill is in defining "the real requirements" rigorously and refusing both errors on either side, the negligence that stops short of them and the perfectionism that keeps going long past them. Good enough done well is harder than perfectionism, not easier, because it demands the judgment to know exactly where the line is rather than the simple, expensive reflex of always doing more.

How to tell disciplined good enough from the lazy kind

The distinction a leader has to make comes down to a question asked honestly: does this system meet the genuine requirements of the business, the things it actually needs to do reliably to operate and grow? If it does, then further investment in making it better is optimization past the point of return, and the disciplined answer is to stop and put that money and attention where the business is actually constrained. If it does not, if there are real requirements going unmet, then it is not good enough and the work is not done, regardless of how much has already been spent.

What that question deliberately excludes is the flood of reasons systems get improved that have nothing to do with real requirements: it lacks the polish of a newer tool, a competitor has a nicer one, it could theoretically handle a scenario that has never occurred, or someone finds a workflow clunky. None of those establish that the system is failing the business. They establish that it is imperfect, which every system is, including whatever you would replace or rebuild it into. The leaders who get the most from technology are not the ones who chase the perfect system. They are the ones who define what the business genuinely needs, build or keep a system that meets it reliably, and then have the discipline to stop and spend their finite resources on the problems that are actually still open. This same discipline is why, before any major systems change, the honest first move is to test whether the current system's shortcomings are real costs or merely imperfections, the question at the center of the case against ripping out your systems.

FAQs

Q1. Isn't "good enough" just an excuse for cutting corners?
It can be misused that way, which is why it requires a real standard. Properly understood, good enough means fully meeting the genuine requirements of the business and then stopping, not falling short of them. The discipline is precise: it rejects both the negligence that stops before the requirements are met and the perfectionism that continues long after. A system that fails real needs is not good enough, it is inadequate.

Q2. Where does the idea that "good enough" is rational actually come from?
From serious decision science and engineering practice. Herbert Simon won a Nobel Prize partly for satisficing, the finding that choosing an option that meets your needs beats exhaustively searching for the optimal one once you account for the cost of searching. Engineering formalized the same logic as the principle of good enough, which holds that pursuing perfection past core requirements yields diminishing returns that outweigh the benefit.

Q3. What does chasing the perfect system actually cost?
More than it appears to, because the cost hides inside effort that looks like diligence. It shows up as over-customization that makes systems fragile and expensive to maintain, over-building for scale and futures that may never arrive, and projects that never ship because they are endlessly refined. The result is higher total cost of ownership and delayed value, all incurred in the name of doing it properly.

Q4. How do I tell whether our system is genuinely good enough or actually inadequate?
Ask whether it reliably meets the real requirements the business needs to operate and grow. If it does, further improvement is optimization past the point of return. If it genuinely fails to meet real needs, it is not good enough and the work is not finished. The key is defining the real requirements rigorously and not confusing them with preferences or aesthetics.

Q5. Isn't settling for good enough risky in a competitive market?
The greater risk is usually the opposite: pouring finite resources into perfecting systems that already meet the business's needs while real constraints go unaddressed. Competitiveness comes from directing effort where it actually moves the business, not from having the most polished version of every system. A good-enough system that frees resources for real problems often beats a perfect one that consumed them.

Q6. What is gold plating and why does it matter?
Gold plating is the project-management term for continuing to work on something past the point of diminishing returns, adding polish or features beyond what was actually required. It matters because it is consistently associated with higher costs, greater complexity, and worse maintainability, not with better outcomes. Recognizing it is part of knowing when to stop.

Q7. Does this mean we should never customize or improve our systems?
No. It means customization and improvement should be justified by a real, unmet business requirement rather than by the pursuit of an ideal. Some improvements are genuinely warranted because they close a real gap. The discipline is to require that justification each time, rather than treating "it could be better" as a sufficient reason, since almost anything could always be better.

Q8. What is the single most useful habit for applying this?
Before approving any effort to improve a system, force the question of whether it addresses a genuine business requirement or merely an imperfection. If it is a real requirement, proceed. If it is elegance, comparison, or a hypothetical scenario, recognize that you are about to spend past the point of return, and redirect that investment to a problem the business actually has open.