Perfect is the enemy of done. But so is “good enough” when it’s not actually good enough.

The challenge isn’t choosing between perfection and mediocrity; it’s knowing where to draw the line. When does additional investment in a system yield diminishing returns? When does stopping short create problems that cost more than finishing would have? Where’s the threshold between pragmatic and penny-wise?

Most organizations don’t think about this systematically. They either over-engineer (building elaborate Salesforce implementations with custom objects, Apex triggers, and workflow automations for scenarios that will never happen) or under-invest, spinning up a HubSpot instance with no data hygiene strategy that becomes unusable within a year. Finding the right threshold requires understanding what “good enough” actually means for each situation.

The Over-Engineering Trap

Over-engineering is building more than the situation requires. It shows up constantly in platform implementations:

Building for hypothetical scale. A 50-person company implementing Salesforce Enterprise with custom CPQ, territory management, and Einstein Analytics: capabilities designed for organizations ten times their size. The infrastructure to handle problems you don’t have creates costs you do have: complexity, maintenance burden, longer development times, and higher licensing fees.

Premature optimization. Spending weeks building custom Monday.com automations and dashboards before understanding how the team actually works. Creating elaborate HubSpot workflows before validating that leads flow the way you assume. Optimization is valuable when it addresses real problems; it’s waste when it addresses theoretical ones.

Gold-plating features. Adding Salesforce custom objects, validation rules, and approval processes no one asked for because they might be useful someday. Each additional feature increases complexity, testing requirements, and the burden on users who have to navigate it all. Features that don’t deliver value are liabilities, not assets.

Excessive customization. Building so much custom functionality on top of a platform that you’ve essentially created a bespoke application, but one that’s constrained by the underlying platform’s architecture and priced at enterprise licensing rates. If you’re fighting the platform that hard, you may have chosen the wrong platform.

Over-engineering feels responsible. It feels like doing the job properly. But the company that spends six months perfecting their Salesforce implementation before sales reps can actually use it has lost six months of sales productivity.

The Under-Investment Trap

Under-investment is stopping before you’ve built something adequate. It’s equally common:

No data strategy. Implementing HubSpot or Salesforce without defining required fields, data validation, or cleanup processes. Within months, the database is full of duplicates, incomplete records, and inconsistent formatting. The system becomes a junk drawer that no one trusts.

Skipping user adoption. Rolling out Monday.com to a team with a 30-minute training session and assuming they’ll figure it out. Three months later, half the team is back to spreadsheets and email because the tool was never properly configured for how they work.

Building for today only. Setting up Salesforce with exactly the fields and workflows needed for current processes, with no thought to how the business might evolve. Six months later, a new product line or territory expansion requires starting over.

Ignoring integration. Implementing a CRM that doesn’t connect to the tools people actually use: email, calendar, support systems, billing. The CRM becomes a data entry burden rather than a productivity tool, and adoption craters.

Under-investment often stems from deadline pressure or budget constraints. But a CRM that sales won’t use isn’t a cost savings; it’s a waste of whatever you did spend.

The Real Cost of Each Extreme

Both under-investment and over-engineering have real downstream costs; they just manifest differently.

Under-investment leads to: rework costs when you rebuild what wasn’t done right, adoption failure when users abandon the system for spreadsheets, months of data cleanup to fix accumulated junk, lost productivity from workarounds and manual processes, and a trust deficit that makes teams skeptical of future tools.

Over-engineering leads to: delayed value as months pass before anyone can use the system, wasted budget on features no one touches, complexity burden in training and ongoing maintenance, upgrade friction when customizations break with platform updates, and opportunity cost from resources tied up that could have been deployed elsewhere.

Neither extreme is free. The goal is finding the middle ground where you’ve invested enough to succeed without investing more than the situation warrants.

A Practical Rubric

What does “good enough” actually look like for a typical CRM implementation? Here’s a rubric across key dimensions:

Data Model: Under-invested means no required fields and no validation. Good enough means core fields required, basic validation rules, and duplicate management. Over-engineered means custom objects for every entity with complex validation chains.

Integrations: Under-invested means none: manual data entry everywhere. Good enough means email, calendar, and one or two core systems connected. Over-engineered means every system connected with real-time sync everywhere.

Automation: Under-invested means none. Good enough means key workflows automated: lead assignment, follow-up reminders, stage progression. Over-engineered means elaborate multi-step workflows for every edge case.

Reporting: Under-invested means default reports only. Good enough means five to ten dashboards covering key metrics. Over-engineered means fifty-plus reports, most never viewed.

Training: Under-invested means a 30-minute overview. Good enough means role-based training, documentation, and ongoing support. Over-engineered means certification programs and extensive custom documentation.

Timeline: Under-invested is two weeks. Good enough is six to ten weeks. Over-engineered is six-plus months.

Finding Your Threshold

The right threshold depends on context. Several factors shape where “good enough” falls for your situation:

Criticality. A CRM for a sales-driven organization is mission-critical; it justifies more investment in getting it right. A project management tool for occasional use can be more pragmatic.

Longevity. If you’re committed to Salesforce for the long term, investment in proper architecture pays dividends. If you’re testing HubSpot for six months before deciding, keep it simple.

Rate of change. Organizations in flux (adding products, expanding markets, evolving processes) need platforms configured for flexibility. Stable organizations can fit implementations more tightly to current needs.

Uncertainty. When requirements are unclear, building minimal implementations and iterating is smarter than trying to anticipate everything. Start with core functionality; add complexity as you learn what’s actually needed.

Reversibility. Data models and object structures are hard to change later. Dashboards and reports are easy. Invest more in getting the hard-to-change elements right; be pragmatic about the rest.

Practical Heuristics

Some rules of thumb for finding the threshold:

Start with out-of-box, then customize. Use standard Salesforce objects before creating custom ones. Use native HubSpot workflows before building complex automation. Customize when the standard approach genuinely doesn’t work, not because custom feels more sophisticated.

Invest in data quality from day one. Required fields, validation rules, duplicate management: these aren’t gold-plating. They’re the foundation that determines whether your system becomes an asset or a liability.

Configure for how people actually work. Observe your team before building elaborate workflows. The elegant process you design may not match reality. Good enough means good enough for the people who have to use it.

Plan for the next stage, not the final state. You don’t need to build for five years from now. But building with no thought to next year creates systems that need to be rebuilt constantly.

Define done before you start. Agree on what “good enough” means for this implementation before building. When you don’t define the threshold upfront, you’ll either stop too early or never stop at all.

The Ongoing Calibration

“Good enough” isn’t a fixed point; it requires ongoing judgment. The threshold that makes sense at project start may shift as you learn more. Requirements change. Constraints change. What you learn during implementation changes your understanding of what’s needed.

The goal isn’t to calculate the perfect threshold once and execute against it. It’s to maintain awareness of where you are relative to the threshold, making deliberate decisions about when to invest more and when to ship.

Enterprise Engineering builds systems calibrated to actual requirements, investing appropriately in quality without over-engineering for scenarios that won’t materialize.

Strategic Advisory helps organizations make explicit trade-offs between investment and pragmatism, ensuring decisions are deliberate rather than accidental.