Point-to-point vs middleware vs iPaaS for a small firm

Most small firms never choose an integration architecture. They connect the CRM to accounting one year, the form tool to the CRM the next, then add a Zap here and a native sync there. Five years later nobody can draw how data moves, and every new tool means another round of fixes.

The short answer: point-to-point connections are fine for a handful of tools, but the number of possible links grows much faster than the number of tools. Past roughly five or six connected systems, most 10 to 50 person firms are better served by routing integrations through one hub, which in practice means a lightweight iPaaS such as Zapier, Make, n8n or Power Automate, with native integrations kept where they work well. Traditional middleware is rarely the right fit at this size.

The three approaches in plain terms

Point-to-point. Each pair of tools is connected directly: a native integration, a dedicated plug-in, or a small script. The CRM talks to accounting, accounting talks to the payments tool, the form tool talks to the CRM.

Middleware. Software that sits in the middle and translates between systems, traditionally installed and run by an IT team on the firm's own servers. Enterprise service buses are the classic example. Each tool connects once to the middleware, which handles routing and transformation.

iPaaS (integration platform as a service). The same hub idea, delivered as a cloud service. You sign in, connect each app, and build workflows in a visual editor. Zapier, Make, n8n and Power Automate sit at the lightweight end of this category; enterprise platforms such as MuleSoft, Boomi and Workato sit at the heavy end and are aimed at organizations with dedicated integration staff.

The connection math

If every tool might need to talk to every other tool, the number of possible point-to-point links is n × (n minus 1) ÷ 2, where n is the number of tools. With a hub, each tool connects once, so the number is n.

No firm actually needs every possible link. A realistic 20 person firm might need 8 to 12 of them. But the table shows the underlying problem: each new tool adds a connection to almost every existing tool, not just one. With point-to-point, adding a twelfth system can mean revisiting eleven others.

The math also hides a second cost. Each point-to-point link is configured in a different place, with different logins, error messages and settings pages. Finding out why a client's invoice did not reach the CRM means knowing which of several connectors was responsible.

What point-to-point does well

Point-to-point is not wrong. It is often the best choice for the most important pair in your stack:

• Native integrations are maintained by the vendor. A CRM to accounting sync built by one of the two vendors usually handles matching, retries and IDs better than anything you would build.
• There is no extra platform to pay for or monitor.
• For four or five tools with clear links, the whole map fits on one page.

The problems start when point-to-point becomes the default for everything, including links nobody documented.

What a hub does well

Routing integrations through one platform gives you:

• One place to look. Every workflow, every connection and every error log sits in the same account.
• One set of logins to manage. When someone leaves, you check one platform's connections rather than ten settings pages.
• Reuse. A new tool connects once, and existing workflows can pick up its data.
• Visible logic. A workflow in a visual editor can be read by someone other than the person who built it.

The trade-offs are real. The hub becomes a single point of failure, so it needs an owner and error alerts. It adds a subscription priced by usage: Zapier counts tasks, Make counts credits and n8n prices hosted plans by workflow executions, so a busy workflow can cost more than you expect. And it holds copies of the data passing through it, which matters for client confidentiality and data protection.

Why traditional middleware rarely fits a small firm

Classic middleware was designed for organizations with on-premises systems and IT staff to run it. For a 10 to 50 person firm on cloud software, it usually means:

• A server to host, patch and back up.
• Specialist skills to configure, which are hard to replace if the person leaves.
• Capability far beyond what a firm with a dozen SaaS tools needs.

Self-hosting a tool like n8n is the closest small-firm equivalent: you get the hub, and you also take on the server. That suits firms with reliable IT support and a reason to keep data on their own infrastructure, not firms looking for a cheaper Zapier.

A practical hybrid for a 10 to 50 person firm

What works for most firms of this size is not a pure architecture but a clear rule set:

1. Keep native integrations for core pairs where the vendor's connector covers your need, typically CRM to accounting, practice management to accounting, and calendar to email.
2. Put everything else on one automation platform. Intake forms, notifications, document requests, onboarding tasks and reporting feeds all live in the same account.
3. Never let two routes write the same record. If the native sync creates clients in accounting, platform workflows only look them up.
4. Draw the map. One page listing every tool, every connection, which route it uses and who owns it. Update it when anything changes.
5. Use firm-owned logins for every connection, on both native and platform routes.
6. Revisit at growth points. Adding a new core system, opening an office or doubling headcount are good moments to check whether the map still makes sense.

For the decision about each individual link, our guide to native integration vs Zapier vs custom API sets out the order to try them in.

Signs your current setup has outgrown point-to-point

• Nobody can say, without checking, how a new client gets from the enquiry form into accounting.
• The same client exists with slightly different names in three systems.
• Connections run under the logins of people who have left or changed roles.
• Adding one tool triggered changes in several others.
• Errors are discovered by clients or by finance at month end rather than by an alert.

Two or more of these usually mean it is time to consolidate, which often starts with removing tools rather than adding a platform.

How Flow Mesh helps

Our stack audit maps every tool and connection you have today, gives each tool a verdict (keep, configure, consolidate or replace) and sets out in writing which links should stay native and which belong on a single platform. If you want us to build it, the integration work is scoped and quoted in writing after the audit and done inside your own accounts.

Key takeaways

• Possible point-to-point links grow as n × (n minus 1) ÷ 2: 15 for six tools, 66 for twelve.
• Point-to-point suits a few core pairs, especially where a vendor-maintained native integration exists.
• A lightweight iPaaS gives a small firm one place to manage workflows, logins and errors, but needs an owner and costs scale with usage.
• Traditional middleware and self-hosting add servers and specialist skills most small firms do not have.
• The practical answer is a hybrid: native for core pairs, one platform for the rest, and a written map of every connection.