A familiar sequence starts with a real problem. Someone in operations spends two days a month reconciling numbers that ought to agree on their own, the frustration reaches a manager, and by the following quarter there is a shortlist of platforms that promise to end it. The demo is impressive, because demos are built to be impressive. Eighteen months later the platform is half configured, three people have been trained on it, the reconciliation still happens in a spreadsheet, and the person who championed the purchase has moved to another company.
The problem was real the entire time. The response simply outgrew it.
Platforms are built for problems that repeat
Large enterprises buy platforms for a sound reason. A bank with twelve business lines discovers the same customer data problem in all twelve, each one solved locally, each local solution carrying its own integration, its own maintenance, and its own version of what a customer record means. Twelve point solutions become a permanent tax, and the tax grows every year.
A platform pays for itself against that pattern. The cost of abstracting a problem into something general is real, and it gets amortized across every unit that shares the problem. Two years of implementation is a rational trade when the alternative is a decade of divergence across twelve teams. The repetition is what makes the arithmetic work.
Repetition is the thing a smaller business lacks
A hundred-person company is structured differently. There is one operations team, one finance function, and one version of the reconciliation problem, held by the two people who understand it end to end. The abstraction has nothing to amortize across, so you pay the full generalization cost and receive exactly one solved problem in return.
You also inherit the configuration surface that made the platform attractive to a much larger buyer. Hundreds of settings exist because hundreds of scenarios exist somewhere in the customer base, and your team has to work through enough of them to reach the two that describe your business. That is where the implementation timeline starts to outlive the urgency that justified the purchase, and where a project stops being about the reconciliation at all.
The quick fix sends its bill later
The opposite instinct produces a different failure. Someone writes a script in an afternoon, or vibe-codes a small tool over a weekend, and the immediate problem disappears. The economics look excellent for about a year.
Then the assumptions surface. A rule that was true when the script was written became false after a pricing change that nobody connected to it. A hardcoded threshold has been silently rounding a number in the wrong direction. The one person who understood the logic has moved teams, and the tool has quietly become infrastructure that the business depends on and cannot explain. Short-term solutions age into permanent systems without anyone deciding that they should.
What Excel gets right
Excel is the most durable business tool ever built, and the reasons are instructive. Anyone can use it, it addresses an enormous range of problems, it moves between companies as easily as it moves between departments, and it requires no procurement cycle to start. When everybody needs a similar capability, a general tool is exactly the right answer, and Excel has been that answer for forty years.
The difficulty starts when Excel is asked to do work it was never designed for. As a multi-user database it corrupts, as a workflow engine it depends on somebody remembering to run it, and as a system of record for regulated data it fails an audit. The tool stayed the same throughout. The problem grew into a different shape, and the fit disappeared without any announcement.
The missing input is prioritization
Both roads lead to the same place, arriving from opposite directions. The platform generalizes past what the business needs, the quick fix under-builds what the business will need, and each is an answer to a question that was never properly ranked. Which problems actually cost you money this year? Which ones grow more expensive if you leave them for another eighteen months? Which ones would stay solved with a two-week fix?
Ranking those questions takes judgment about the business rather than expertise in any particular product. Someone has to look across operations, finance, and technology at once, size each problem in money and risk, and then choose the smallest response that holds for the next three years. That work is unglamorous, it produces no demo, and it determines whether the next two years get spent on an implementation or on the business.
Where this leaves you
Platforms make sense where a problem repeats across many parts of an organization, and the abstraction earns its cost through that repetition. Smaller businesses rarely hold the same problem in cloned form, so the platform arrives as overkill and the two-year implementation becomes the new problem. The quick fix inverts the error and defers the cost rather than removing it. Excel remains durable because a general tool fits a general need, and it breaks in predictable ways once the need becomes specialized.
What all of this points to is oversight of the problem itself. The businesses that spend well are the ones that decided what they were solving before they decided what to solve it with. Over the next few years the pressure will increase, since AI tools are being sold into the mid-market at a pace that makes the platform question arrive more often and with more urgency behind it.
So rather than investigating whether a tool is right for you, what processes do you have to prioritize business problems?
Do not over-optimize. Get the right guidance instead, and a fractional leader can help you find the answer that fits the problem you actually have.