Stop Bending Your Business to Fit Your Software

It’s 4:45 PM on a Friday, and someone on Maria’s team is doing the thing they do every Friday: exporting a report from one system, reformatting it in Excel, and re-keying half of it into another system so the numbers line up for Monday’s meeting. It takes about ninety minutes. It has taken about ninety minutes, every week, for years.

Nobody remembers exactly why the two systems don’t talk to each other. It’s just how the process works. New hires get trained on it like it’s Newton’s law.

Maria runs a mid-size distribution company: call it $30 million in revenue, sixty employees, the kind of business that shows up on nobody’s “disruptive startup” list but a very “backbone of the economy.” And like most CEOs I talk to, she didn’t design this Friday ritual. She inherited a decision that was made years ago, quietly, without anyone calling it a decision: when the software didn’t fit the business, the business bent to fit the software.

For many years, that was just what running a company meant.

The Old Logic Was Rational

It’s worth noting that in the above scenario, nobody was being lazy or unimaginative. Building software that actually matched how your business worked used to be genuinely expensive – six figures, with 8 to 12 months for a first build cycle, and a real chance of delays, scope creep, or the project stalling halfway through. Buying a SaaS tool that handled 70% of what you needed and living with the other 30% was the smarter bet, nearly every time.

So companies like Maria’s did the rational thing. They bought the tools. They trained their people to work around the gaps. They hired a project coordinator whose real job, unofficially, was being the human API between multiple systems that were never designed to cooperate. It wasn’t a failure of leadership. It was a correct trade-off, given the economics of the time.

Those economics just quietly stopped being true.

What Actually Changed

AI hasn’t just made existing software smarter. It’s changed who can afford to build software in the first place. The kind of custom application that used to require a ten-month engagement and a six-figure budget can now be scoped, built, and put in front of real users in a matter of weeks, sometimes days for the first working version.

Cox Communications (the largest private broadband provider in the U.S., with 15,000 employees) hit a wall in its B2B growth engine and, working with Accenture, built its own suite of AI agents rather than bolting on another off-the-shelf platform. The result: a 7x return on its first year of AI investment, 55% faster speed to market, and the cost of validating and enriching sales leads cut by 86%, with accuracy up from 18% to 97%. If a company with 15,000 employees and every off-the-shelf option available to it is choosing to build custom, that’s not a trend confined to startups. That’s a signal for every business that’s been quietly living with software that almost fits.

It’s happening at a smaller scale too and faster than most CEOs expect. Curative, a health insurance company, recently canceled its Salesforce contract (worth $600,000 a year) after building its own CRM in two months and plans to cut roughly 80% of its SaaS spending this year. Salesforce’s own CEO has pushed back on the idea that this is a broad pattern, and it’s a fair pushback. Plenty of companies still find SaaS to be exactly the right fit. But the fact that this is now a live debate, rather than a settled assumption, tells you something. Two years ago, “we built our own CRM in two months” wasn’t a sentence a CEO could say out loud.

The Moment It Clicks

I’ve watched this land on CEO after CEO the same way. A project like Maria’s (the kind her team had assumed would take months and run well into six figures) can now realistically be scoped in a few weeks, for a fraction of that cost. Say that number out loud, and there’s almost always a pause. Then some version of the same sentence: “I didn’t know that was even an option anymore.” 

That’s the moment I keep watching play out. It’s not a technology conversation. It’s a realization that a constraint everyone built their operating assumptions around (we can’t afford custom, so we live with the workaround) has quietly stopped being real. The software didn’t get smarter overnight. The economics underneath it did. And most leaders haven’t caught up to that yet, because nobody sends a memo when a constraint disappears.

Two Ways to Get This Wrong

Here’s the part that makes this a genuine dilemma, not just an easy call.

The first way to get it wrong is obvious: keep doing what Maria’s company was doing. Keep training new hires on Friday rituals nobody questions. Most CEOs can tell their revenue and their margins to the decimal. 

Far fewer can tell what their workarounds are actually costing them: 

• the risk sitting quietly in a manual process nobody’s audited in years, 
• the growth that stalls because the system can’t handle a new product line without a six-month IT project,
• the cost to serve customers that creeps up every time a workaround needs another person to babysit it, 
• the good people who quietly stop raising their hand about a process they’ve complained about twice already. 

None of that shows up as a single line item. It shows up as a company that’s slower than it should be, in ways leadership has stopped noticing. Meanwhile, a competitor down the street who rebuilds around their actual workflow moves faster, serves customers better, and makes decisions with cleaner data, not because they’re smarter, but because they stopped accepting friction as the cost of doing business.

The second way to get it wrong is less obvious, and I see it just as often: treating “we can build custom now” as a license to rebuild everything immediately, because modernization suddenly feels urgent. A healthcare services company I encountered last year got excited about this shift and signed off on rebuilding a system that, frankly, worked fine. The real opportunity wasn’t there. 

Not every workaround deserves custom treatment. The skill isn’t building fast. It’s knowing which friction is actually worth removing.

Fitting the Software to the Business

What changes when a company gets this right isn’t just faster software; it’s where decisions get made. Instead of a vendor’s product roadmap dictating what your operations team can and can’t do this quarter, the workflow gets built around how the work actually happens. Teams stop normalizing friction; they’d quietly stopped noticing. The software becomes something the business owns and shapes, instead of something the business adapts around.

For Maria, that Friday ritual is going away, not because someone finally complained loudly enough, but because the cost of fixing it dropped below the cost of tolerating it. That’s a small example. The same logic is playing out, right now, in far bigger decisions across mid-size companies that don’t yet realize the math has changed.

Who’s Deciding How Your Business Runs?

Every company running on inherited software workarounds is, whether they think of it this way or not, letting a vendor’s decisions from years ago quietly continue to shape how their business operates today. That was a reasonable trade when the alternative was six figures and months of custom builds with uncertain outcomes.

That trade-off is gone. What replaces it isn’t a new tool to buy. It’s a question every mid-size CEO is going to have to sit with, sooner or later – are you still going to let your software decide how your business runs, or is it time your business decided that for itself?