Buy, don’t build... then customize

How to spend more for less while also creating a maintenance nightmare.
Buy, don’t build... then customize

Our business is unique

Here at SynergetIQ, we believe in innovation, synergy, and the kind of efficiency that requires at least three middle managers to define. Our customers are visionary thought-leaders, and so are we. That’s why we refuse to use software that hasn’t been manically optimized and surgically grafted onto our unique, ever-shifting business needs.

So when the VP of Sales announced we needed a new CRM—one that could support:

  • Nested lead scoring,
  • Timezone-aware Slack notifications,
  • Steve’s spreadsheet (non-negotiable),
  • And work flawlessly on an iPad 2…

…we knew: this was a job for a custom solution.

We’re not like other companies,” said our CEO, with the quiet confidence of a man who once tried to run payroll through Mailchimp.

We briefly considered building in-house. But after someone did the math, then came one HR complaint about “developer tears not being a valid KPI,” and a team rage-quitting a vendor demo 14 minutes into a 30-day trial… we pivoted.

Thanks to some exceptional dealmaking by our CIO on the 16th green, we bought an off-the-shelf platform.

I clicked one button and now I’m locked out of Q3,” said Shelly from Accounting. “There’s an icon that looks like a flamingo, but apparently that deletes everything.

Steve, meanwhile, just quietly smiled to himself. His macros had survived the Windows 7 migration.

The light touch

We’ll just customize it a little,” they said.

Just enough to make it ours.

It began innocently enough: a renamed button here, a few new dropdown values there. Nothing too serious - just enough so that teams could “maintain continuity with our legacy workflows,” a phrase we later discovered meant “still use Steve’s spreadsheet.

But then Product wanted color-coded tagging that matched their mood board.

Marketing insisted on emoji reactions in the CRM notes field - strictly from the 2017 Unicode set, “for brand consistency.

Legal required every record to be exportable as a PDF, then immediately encrypted and password-protected, while Finance requested a secure audit trail with support for fiscal calendars based on the Mayan long count.

By the end of Q2, the system had:

  • A custom plugin that translated comments into pirate-speak every September

  • An internal chatbot named Workflow Wendy who, after sufficiently completing all necessary paperwork, went on maternity leave

  • A calendar integration that synced with Outlook, Google, and our CEO’s PalmPilot (which he insists is “more ergonomic”)

The vendor dropped support and then went mysteriously missing during a kayaking incident.

Soon out of the box meant a team of six developers living out of an actual cardboard box inside of the data center.

The Monolith awakens

By Q3, the system was no longer a tool - it was an ecosystem. Bugs were mature enough to have evolved legs, crawled primordial ooze and sent their kids to college. A sacred labyrinth of checkboxes, hidden dropdowns, and dependencies so old they were last backed up to Zip disk.

No one knew how our “turnkey solution” actually worked. Not even the team that built it.

All we know is there’s a 1998 Compaq laptop running Windows XP in the server room that the infra team are too scared to move onto the UPS.

Yes, the system is slow. Yes, onboarding takes two weeks, a whiteboard session, and a whispered legend passed down by Operations. But our customer satisfaction scores? All green.

Now running a simple email campaign was as simple as:

  • Ensuring the Global Elite ServiceNow subscription hadn’t expired
  • Wait 22 minutes for the dashboard to load
  • Remembering the dashboard’s only accurate on Thursdays
  • Adding each client to the template spreadsheet Q4_FINAL_FinalACTUAL_use_this_one_v3
  • Wait for Workflow Wendy’s out-of-office autoresponder to forward it to an internal inbox named crmtickets_butreal
  • Receive final approval from Steve - non-negotiable

And if something broke, we logged a ticket, held our breath, and hoped it wouldn’t reach Steve during a long weekend.

Rebirth

Eventually, something snapped. Possibly the infrastructure team.

The CTO left. A new CIO arrived, wielding fresh credentials, inspirational haikus and a deep distrust of anything old enough to support plugins.

She spoke of simplicity. Of clarity. Of streamlining.

“We need a system,” she said, “that reflects how we really work. That adapts to us. Not the other way around.”

This time, we’ll build it right,” she declared.

From scratch.

With AI.

A quiet shiver ran through the dev team.

Steve updated his résumé.

Intern-First - Disrupting Experience
They’ll ask why I didn’t swim harder

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.