成長企業がソフトウェアスタックを追い越す理由

At twelve employees, the system works. Xero handles the accounts. Trello manages projects. Slack handles communication. HubSpot holds the customer data. Dropbox stores the documents. It cost almost nothing to set up, it runs itself, and it lets the team move fast.

At forty employees, something has changed. Nobody is quite sure when it happened.

The operations director has three spreadsheets that bridge Xero and HubSpot because the two systems don't talk to each other. The project manager maintains a separate tracker because Trello doesn't have the reporting the board wants. Finance spends two days per month consolidating data from five different sources before they can produce management accounts. A new client onboarding requires someone to manually create records in four separate systems.

Nobody decided to build this. It assembled itself, one sensible tool decision at a time.

The Common Belief

Software fragmentation is a symptom of growth. Once you have the revenue to justify a proper system, you replace the stack with an ERP and the problem resolves.

The implication is that the fragmented stack is a transitional state — uncomfortable, slightly inefficient, but not materially damaging. It is the cost of growing fast. You clean it up when you can afford to.

Why That Belief Is Wrong

The belief that fragmented software is a transitional inconvenience misunderstands how operational complexity compounds.

Each tool in a fragmented stack creates its own data model. HubSpot's customer record is not the same as the customer record in Xero. Trello's project has no relationship to the invoice in Xero. When these systems need to talk to each other — and at forty employees they must — the gap is bridged by a human. Usually the same human, every time.

That human is not performing administrative work. They are performing system integration work. They are the middleware between your tools. And unlike actual middleware, they can leave.

More critically, the fragmented stack does not just create integration work. It creates data inconsistency. When the same customer appears in three systems with three slightly different names, three different contact records, and three different payment histories, the question "what is the state of this customer relationship?" cannot be answered from any single source. It requires reconciliation. Every time.

Reconciliation at forty employees is annoying. At 150 employees, it is an operational ceiling. The business cannot scale past a point where manual reconciliation of fragmented data becomes the binding constraint.

What Actually Happens

The fragmentation pattern is consistent across sectors and business models.

Stage 1: Tool adoption. Early-stage businesses adopt the best tool for each specific problem. This is rational. A dedicated CRM is better than a spreadsheet. A dedicated accounting system is better than a shared spreadsheet. Each adoption solves a local problem.

Stage 2: Integration debt accumulates. As the business grows, the boundaries between tools begin to matter. Sales needs to see the invoice status. Operations needs to see the pipeline. Finance needs to see the project profitability. None of the tools were designed to share this data automatically. Bridges appear: exports, imports, spreadsheets that consolidate, and people who run the process manually.

Stage 3: The stack becomes load-bearing. The bridges that were meant to be temporary become permanent. The monthly export from HubSpot to Xero becomes a process that the finance analyst owns. If she is on holiday, the process does not run. The Trello board becomes the only place the production schedule lives. If Trello goes down, the factory stops.

Stage 4: Growth reveals the constraint. The business tries to grow faster. It needs to onboard more clients. It needs to report more granularly. It needs to give investors a consolidated view of performance. All of these requirements run into the same problem: the data exists, but it is distributed across systems that were never designed to work together, bridged by processes that scale with headcount rather than with revenue.

At this point, the fragmented stack is not a transitional inconvenience. It is the reason growth is slowing.

Real-World Example

Company: Stackfield Digital
Industry: Digital marketing agency
Size: 67 staff, £9.4M revenue
Problem: Operational capacity capped at current headcount

What happened:

Stackfield had grown from 8 to 67 people in four years on a stack built for the early days: HubSpot for CRM, Xero for finance, Harvest for time tracking, Asana for project management, and Google Workspace for everything else. Each system had been chosen when it was the right decision.

When the operations director modelled what scaling to 120 people would require, the analysis produced an uncomfortable finding: adding 53 people would require adding approximately 12 administrative and finance staff to manage the integration work between systems. The business would not scale to 120 people on £9.4M revenue. It would scale to 120 people on £11.2M revenue, with £1.8M of that absorbed by operational overhead.

The fragmented stack had imposed a headcount tax on growth.

Outcome:

Stackfield modelled two paths: integrate the existing stack using middleware (estimated £180,000 and six months), or move to a unified platform. The integration option was ruled out when the technical team determined that the data models across the five systems were too inconsistent to integrate cleanly without significant data remediation work.

The migration took eleven months and cost £340,000. The business disruption during migration cost an estimated £120,000 in delayed projects and management distraction.

Total cost of deferring the problem: approximately £460,000 and eleven months of reduced organisational capacity. The cost of addressing it at twenty employees would have been a fraction of that.

The Cost of Ignoring It

Revenue impact: Sales cycles lengthen when the CRM does not reflect current customer status. Project delivery slips when the scheduling system does not reflect actual resource availability. Finance cannot produce accurate profitability reports, so pricing decisions are made on incomplete information.

Operational impact: The number of manual integration tasks grows faster than headcount. At some point, a significant proportion of the operations function is running processes that should not exist. Those processes are invisible in the org chart but very visible in the cost base.

Team impact: The people running manual integration processes are typically capable people doing work that offers no development, no recognition, and no satisfaction. They leave. The processes they run leave with them.

Hiring impact: Fragmented operations create onboarding problems. A new employee who needs access to five systems with five different data models takes longer to become productive. At forty employees this is manageable. At one hundred it is a material drag on growth velocity.

Investor impact: Businesses preparing for investment face due diligence that requires clean, consolidated operational data. Fragmented stacks cannot produce it. The data exists — it is just distributed, inconsistent, and requires weeks of manual consolidation to present coherently. This creates risk in the due diligence process and, sometimes, valuation haircuts.

What Good Looks Like

The businesses that avoid the fragmentation trap tend to make one decision differently: they think about operational data as infrastructure before they think about tools.

The question is not "what is the best tool for project management?" It is "what operational data model does the business need, and which systems best support that model?" The distinction matters because tool selection driven by features produces a stack that is excellent at individual functions. Tool selection driven by data model produces a stack that works together.

In practice, this means:

Choosing integration-first. Before adopting any new tool, the question is how it connects to the rest of the stack. An excellent standalone tool that cannot share data cleanly is often a worse choice than a good tool that integrates well.

Designing data ownership. Every operational data object — customer, project, invoice, employee, asset — should have one system of record. Other systems can read from it, but only one system owns it. When the ownership is ambiguous, data diverges. The hidden cost of per-user licensing makes this worse — when access is rationed, teams maintain their own copies of data outside the system, which accelerates the divergence.

Treating operational processes as system design. The monthly export from CRM to finance is not an operational process. It is a system design failure. Every manual integration task is an architectural decision that was not made — and making it explicitly, earlier, is almost always cheaper than inheriting it later. This is exactly what happens when the business evolves faster than the software — the manual integrations multiply until the stack becomes the constraint on growth rather than an enabler of it.

ENTMAZ Perspective

The fragmentation problem is solved architecturally, not operationally. Adding middleware between fragmented systems treats the symptom. The cause is that each system was selected for its individual function without reference to a unified business data model.

ENTMAZ's approach starts from the business model. When the business describes its operations — customers, projects, finances, people, approvals — the system that ENTMAZ generates is built around that model. There is no CRM, no separate accounting system, no project tool, no bridging spreadsheets. There is one system of record, compiled from the business description, with every domain sharing the same data model.

The fragmentation problem cannot exist in that architecture, because the architecture does not allow fragmentation to develop. There is no tool to add. There is no bridge to build. There is no integration to manage.

Conclusion

The software stack that works at fifteen employees is not the software stack that will work at sixty. The tools that helped you move fast in the early years create the operational ceiling that slows you in the growth years.

This is not a revelation. Most founders and operations leaders know it. The problem is that the transition feels expensive and disruptive precisely when the business is most stretched — when everyone is focused on growth rather than on the infrastructure that supports it.

The businesses that solve this cheaply solve it early. The ones that solve it expensively solve it in the middle of a growth cycle, or during a funding round due diligence, or after a key person leaves and the bridges they were running collapse.

The fragmented stack is not a transitional state. It is a compounding liability with a predictable payment schedule.

Key Takeaways

• Software fragmentation accumulates silently — each tool decision is rational in isolation, but the combined stack creates integration debt that compounds with headcount
• Manual integration tasks are not operational processes — they are system design failures that scale with headcount rather than revenue
• The fragmented stack imposes a headcount tax on growth: adding revenue requires adding operational staff to manage integration work
• The cost of fixing fragmentation grows exponentially with business scale; addressing it at twenty employees costs a fraction of addressing it at sixty
• The solution is architectural: a unified business data model, not middleware between fragmented tools