We proposed enterprise-grade middleware. The client's finance lead listened politely and wanted another option since they were on an aging ERP platform that would be replaced in the next 12 months which is long enough that they need to make the integration now but soon enough that it makes sense to cut some corners and take on some technical debt.
He was right, and I said so on the call.
Here's the situation. A manufacturer needed ERP data in HubSpot so the sales team could stop flying blind. Our instinct, and I mean our team's honest first draft, was the architecture we'd build for a company with a stable, long-term ERP: proper middleware, delta tracking, real-time sync, error handling, the works. It's the right design for that situation. It was the wrong design for this one, because the ERP was on its way out and the process it fed wasn't mission-critical.
The client's counterproposal was almost embarrassingly simple. The ERP already refreshed a SQL database nightly. Write a custom SQL view against that database, pull it into HubSpot on the same nightly cadence, done. No delta tracking, because nobody needed to know about a change within the hour. No middleware to maintain, because in eighteen months the source system wouldn't exist. A fraction of the cost, and a solution that would be thrown away with the old ERP at no loss.
The question that would have gotten us there first is one we now ask in every ERP conversation: is this process mission-critical, and how long will the source system exist? "Mission-critical" is a status people claim for everything. Actually asking "what breaks if this data is eighteen hours old?" gets a much more honest answer, and the honest answer is usually "nothing."
There's a version of this story where we defend the original scope, argue the merits of real-time architecture, and either win a bigger project the client doesn't need or lose the client. We didn't do that. I told him the estimate was wrong, that we'd designed for a situation he wasn't in, and that his approach was better. Then we re-scoped around it.
I'd argue that call did more for the relationship than a flawless proposal would have. Clients don't expect partners to be right every time. They expect partners to be honest when they're not, and a consultant who can't say "you're right, our design was over-built" is a consultant who will over-build everything.
In fairness to the original design, real-time middleware is the correct answer more often than the cheap version, particularly when quoting is the core sales motion or when reps make decisions on data that's minutes old. The mistake wasn't proposing it. The mistake was proposing it before asking how long the road would be there.
We preach simple-over-complex to clients constantly. This was a reminder that the instinct to over-engineer lives in us too, and it takes a finance person asking a plain question to catch it.
What's the most over-built integration you've inherited? I suspect most of them started with someone not asking how long the source system would exist.