The $1M Mistake Hidden in Your Tech Stack
Every tool you add without a strategy is a liability you’ll pay to escape later.
You have a problem in your business. Someone recommends a tool. Maybe another owner swears by it. The vendor gives you a polished demo showing exactly how it solves the problem.
Your business consultant asks: Does this solve the problem? Yes.
Your IT consultant asks: Can we implement it securely and make it work? Yes.
The vendor asks: Can our product satisfy the requirements? Yes.
Everyone's boxes are checked. So, you buy the software. Yet it still might not be the best decision for your business.
Not because anyone did their job poorly. Each answered from their area of expertise. A technical specialist can build an excellent solution to the wrong problem. A business consultant may not understand the architectural consequences of the technology selected to solve it. A vendor can meet your stated requirements without knowing what you haven't thought to ask.
But who was looking at the whole system?
Most Tech Stacks Aren't Designed Intentionally. They Just Happen.
A problem arises, so we buy something. Reporting isn't good enough, so we add another platform. Two systems don't communicate, so we add an integration. That doesn't quite work, so someone builds something in Zapier. A department still needs something else, so it starts maintaining AirTable or Excel.
Individually, none of these decisions necessarily looks bad. Together, they can create an ecosystem that costs more, creates more friction, and works less effectively than the individual tools suggest.
This is where a systems thinker changes the conversation.
Tell a systems thinker, "We need a training platform," and the first question shouldn't be, "Which one?" It should be: Why?
What problem are we actually solving? What do we need the system to do? What do we already own? Where will the data live? How will access be governed? Who owns it after implementation? Where does it fit into how employees already work? What happens when we have three times as many employees?
A systems thinker doesn't need to know more about network architecture than your network engineer or more about a SaaS product than its implementation specialist. They need to understand enough about both the business and technology to bridge the two.
Only then should we compare buying something new against building internally, integrating what we have, replacing something, or discovering that we don't actually have a technology problem.
The point isn't to arrive at a particular answer. It's to make sure we solve the right problem before we start shopping for the solution.
The Hidden Costs of the Accidental Tech Stack
The subscription is usually the easiest cost to calculate, but not the whole cost.
Every new system creates another place to manage access, permissions, data, and troubleshooting. It also creates another place employees have to remember work happens.
Researchers studying employees across three Fortune 500 companies found workers toggled between applications roughly 1,200 times per day, with reorientation consuming nearly four hours per week. The numbers won't translate to every business, but the underlying problem does: fragmented technology fragments the work.
Integrations help, but every connection creates another dependency. A field, API, authentication method, or workflow changes. An automation fails silently. At high volume, a tiny failure upstream can create hundreds of incorrect records downstream.
Then employees reconcile records, verify automations, manually enter information that didn't sync, or maintain shadow spreadsheets because they don't trust the report.
That's human work created by the technology that was supposed to eliminate human work.
And eventually comes the question almost nobody asks during the demo: What will it cost to leave?
Years later, that inexpensive application may hold data, workflows, integrations, permissions, and institutional knowledge. Replacing it isn't a purchasing decision anymore. It's a migration project.
Some of the most expensive things in a growing company aren't bad decisions. They're old decisions nobody has revisited.
I Know Because I Inherited This
When I stepped into operations at a growing, high-volume law firm, our technology environment had developed much the same way.
I didn't start by asking what we should cancel. I started asking why we had it.
What requirement was each system meeting? Did it still exist? Were we paying for that capability somewhere else? Was a separate platform creating enough additional value to justify another system?
We moved document management from Dropbox into SharePoint, built our knowledge and training environment inside the Microsoft ecosystem where employees were already working, and matched software licenses to what roles actually needed.
Also, instead of assuming Lawmatics (our "CRM") belonged in one box and Clio (our "case management") in another, I looked at the requirements. In our environment, Lawmatics could meet them, so we consolidated case management there into one unified Practice Management System.
The value wasn't only eliminated licenses. It gave our team more time for substantive work and the client conversations we deliberately want to remain human-to-human.
In 2024, optimizing our technology, and the operating model around it, identified more than $1 million in annualized savings.
But the Answer Isn't BIY Everything
There is an obvious way to take Build-it-Yourself too far.
Paying for Microsoft doesn't mean every problem should become a SharePoint site or Power App. Internal development isn't free. Someone has to design, secure, govern, and maintain it. Without governance, you can recreate software sprawl and data silos inside the platform you were trying to consolidate around.
Specialized software can absolutely be worth paying for. Specialization just needs to earn its place in the stack.
The real comparison isn't Product A versus Product B. It's those products versus what we already own, something we could configure or build, changing the process itself—or keeping what we have.
The objective isn't consolidation. It's intentional architecture.
And architecture isn't just technical. A well-designed system can fail if the people expected to use it don't understand it, trust it, or own it. Systems thinking means developing internal SMEs and involving key stakeholders and end-users as Change & Culture Champions who help shape the solution and drive adoption.
So, if you're going to BIY, build it with the backbone of your business: your people.
Small Business Doesn't Have to Mean Small-Business Thinking
A 30-person company doesn't need enterprise-scale technology. But it can make enterprise-minded decisions.
Start with the architecture. Then choose the applications.
If you're buying something for 30 employees, ask what happens at 100. If pricing depends on users, transactions, records, or usage, model what happens when those numbers grow. If you're putting years of company data somewhere, think about how you would eventually get it back out.
You don't need to predict the future. You need to avoid building today's solution into tomorrow's limitation.
AI Is the Latest Test
"We need AI."
Okay. Why?
The question isn't whether AI can do impressive things. It can. The question is whether the way we're deploying it actually improves the system.
In 2025, while SaaStr founder Jason Lemkin was testing Replit's AI coding agent, the agent deleted a live production database despite an explicit code freeze. Replit subsequently introduced stronger separation between development and production environments and additional safeguards.
The lesson isn't that AI coding agents are bad. It's that a prompt telling an autonomous system what it shouldn't do is not the same thing as architecture preventing it from doing it.
And even when AI works, the economics deserve scrutiny. In 2026, CIO reported one case in which AI-agent usage reached roughly $300 per day, more than $100,000 annualized, while replacing only a fraction of one employee's work.
That's not an argument against AI. It's an argument against confusing automation with efficiency.
An implementation can work technically and still fail economically. It can reduce labor while adding compute, governance, security, monitoring, and human-review costs elsewhere.
So, we return to the same questions: What problem are we solving? What information does the system need? What permissions should it have? What should it be incapable of doing without human approval? Who reviews its work? How does usage scale? Who owns governance?
And what exactly should be measurably better after we deploy it?
The shiny object changed. The need to understand the whole system didn't.
Who Is Doing This for You?
You don't need to be this person because you own the company.
Founders build businesses because they understand an industry, customer, opportunity, profession, or service—not because they were secretly supposed to become experts in databases, APIs, cybersecurity, and systems integration along the way.
But someone needs to think about those things in the context of the business you're building.
Look around your leadership table. Who understands your business well enough to challenge what you say you need? Who understands technology well enough to translate what you actually need into requirements? Who can sit between your business advisors, technical specialists, and vendors and understand what each sees, and what each doesn't?
Who sees the whole system?
If the answer is nobody, that's the problem I'd solve before buying the next tool.
More about Ambar
