CRM: buy or build.

A standard CRM is the right choice as soon as your sales and customer processes follow the shape common to your industry: an enquiry arrives, gets qualified, receives a quote, gets followed up, and either converts or does not. That is exactly what these products are built for, and they do it without a line of your own code.

The hard advantages rarely sit where the sales conversation puts them. They sit in operations: security updates, backups, availability, mobile apps, email and calendar integration, import tools, an ecosystem of extensions and — routinely underestimated — staff who already know the system from a previous job. Every one of those you would have to fund yourself, permanently, in a custom build.

Concretely, the case for buying:

• Time to value. Productive in days or a few weeks rather than months.
• Predictable per-user cost. You pay for actual usage, not for project risk.
• Improvement you do not fund. New features arrive whether or not you are working on them.
• Independence from individuals. The skills are available on the market; nobody is the single person who understands the system.
• Reversibility. A wrong choice costs you a migration, not a written-off development project.

If you have fewer than fifty staff and currently run on spreadsheets, notes and an inbox, the right next move is almost always this: introduce a standard product, use it seriously for six to twelve months, and only then judge whether something is genuinely missing. The requirements you write down today are rarely the requirements you hold after a year of real use.

Building your own is worth it when your customer process is itself the competitive advantage — not when it merely looks unfamiliar. That single sentence decides the whole question.

The situations in which we consider a custom build justified:

• The process is the product. Fiduciary services, insurance broking, recruitment, laboratory services: the sequence of case files, deadlines, checks and approvals is the service, not the administration of it.
• Several roles with different views of the same record. Client, partner, internal handling and accounting each see different parts of one case. Standard products solve this with permission profiles, but the ceiling arrives quickly.
• A domain data model that is not called contact and company. Properties, vehicles, policies, mandates, batches, buildings — each with its own relationships, states and history.
• Customers work in the system themselves. The moment a client portal becomes part of the service, you leave the territory CRM licences were designed for. We built exactly that for Steuererklärung Zürich: package selection, login, document upload and appointment booking in a purpose-built web application.
• A large number of light users. Once a hundred people occasionally need to set a status, per-user licensing tips the maths quickly.

What is not a sufficient reason: a cluttered interface, missing training, disagreement in the team about the right sequence of steps, or the wish to own "something of our own". These survive a custom build. They reappear afterwards inside your own system, only more expensively.

Seven criteria carry the decision; everything else is taste. Work through them in writing, and note for each one what you actually know and what you are assuming.

• 1. Process maturity. Is your workflow stable enough that you could write it down today and still recognise it in two years? Anyone still searching for their process should not cast it in software. Standard products win here, because they hand you a proven structure.
• 2. Deviation from the standard. What percentage of your cases genuinely runs differently from the standard model? Under twenty per cent: buy, and solve the exceptions alongside. Over half: examine a custom build seriously.
• 3. Integration needs. Which systems absolutely have to talk to the CRM — ERP, accounting, time tracking, shop, calendar, telephony? Check whether ready-made connectors exist. If your core system only offers an unusual interface, the effort shifts onto both paths equally.
• 4. Data sensitivity. How sensitive is the data, and what do your clients require contractually? Health, HR and financial data carry different obligations from a list of prospects.
• 5. Cost over five years. Licences for a realistic user count against development plus operations — both sides counted in full. More on that below.
• 6. Internal IT capacity. Is there a person who can define requirements, sign off tests and decide when something breaks? Without that role, a custom build fails regardless of how well it is implemented.
• 7. Exit risk. What happens if the vendor doubles prices, discontinues the product, or the agency disappears? For a standard product what matters is export formats and migration paths. For a custom build it is code ownership, documentation, and how many other firms could realistically take over that technology stack.

A workable method: score each criterion from one to five, where five argues clearly for building. If the total does not land well above the middle, the answer is "buy" — and not narrowly, because buying carries the smaller risk.

Count over five years, in Swiss francs, and completely on both sides — otherwise the comparison is worthless. The common mistake is not a wrong price. It is an incomplete list: the buy side forgets onboarding and training, the build side forgets operations and further development.

Buying, counted in full: licences per user per month times twelve times five years, with planned headcount growth; the surcharge for a higher edition when one required feature only appears there; paid add-on modules; onboarding and configuration; migration of your existing data; training and the working hours it consumes; fees for connector services to other systems; annual price increases.

Building, counted in full: concept and data model; implementation; data migration; hosting and backups; monitoring and incident handling; security and dependency updates that arrive whether or not anything changed for you; further development for new requirements; and the internal time spent on requirements, testing and sign-off. As a rough orientation from projects of this kind: budget a noticeable share of the original build cost every year for operations and maintenance alone, before a single new feature exists.

We deliberately do not quote licence prices here. They depend on edition, term, user count and negotiation, and they change faster than a web page gets maintained. Take the vendors' current price lists and put your own user count into them. For the build side our project calculator gives you a first order of magnitude; a prototype for idea validation starts at CHF 10,000 with us, and a complete system sits well above that.

Two outcomes of this exercise are typical. For small teams, buying wins by a distance and the question is settled in twenty minutes. With many light users, or with customer logins, it tips — per-user licensing is structurally disadvantaged there, and a custom build becomes financially interesting. That is precisely the case worth calculating properly rather than guessing at.

The revised Swiss Data Protection Act does not forbid storing data abroad. It requires transparency, a documented legal basis and accountability. So the practical difference between buying and building is not "allowed or forbidden" — it is how much control you actually hold over storage location, sub-processors and deletion.

According to vendor statements, as of August 2026: bexio hosts in Switzerland. Salesforce offers a Swiss operating zone through Hyperforce. HubSpot runs an EU data centre in Germany. Zoho operates EU locations in the Netherlands and Ireland. None of those statements is what binds anyone — the data processing agreement you sign is. It names storage locations, sub-processors, deletion periods and the reporting path for security incidents. Ask to see that agreement before you decide, not afterwards.

With a custom build you choose the storage location freely; a Swiss data centre is a configuration decision. The price is that encryption, access logs, backup strategy, retention periods and subject access rights do not come included. You commission and pay for each of them. Data sovereignty is therefore not an argument that automatically favours building: you trade dependence on a vendor for responsibility for your own operations.

Two points cause more trouble in practice than the server location. First, export. Before you commit, verify that you can get all your data out — activities, attachments and history included — in a readable format. Second, subject access requests. When someone asks what data you hold about them, you have to answer within a legal deadline, and that becomes laborious with a handful of systems running side by side. Anyone who takes their first-party data seriously keeps it in as few places as possible.

The third path is this: keep the standard, build the deviation alongside it. In our experience it is more often right than either pure option. Contacts, companies, activities and pipeline stay in the standard CRM, and you develop only the one process that genuinely does not fit, connected to the CRM through an interface.

That might be a domain application for case handling, a client portal, a quoting or configuration calculator, an approval workflow, or a reporting dashboard across several sources. Technically it falls into the same category as a complex web solution, but it is cut far smaller than a full CRM.

The advantage is structural, not just financial. Maintenance, security, mobile use and updates stay with the vendor. Your own code is limited to the part that creates value, which keeps it small enough for one person to hold in their head. And if the deviation turns out to disappear, you throw away a manageable module rather than an entire system.

The price: you run two systems instead of one and you have to handle synchronisation. So decide from the outset which system is the leading source for which field. Without that decision you end up with two versions of the truth, and that costs more trust than either system is worth.

In these cases we actively advise against it — even when the enquiry has already landed with us and we could take it:

• You have no CRM at all today. Without a year of real use of a standard system, you have no basis for defining requirements. You would be paying for your assumptions, not your needs.
• The team is smaller than about ten people. Licence costs are then so low that no development budget can compete with them.
• Nobody internally owns it. When ownership sits "with management, on the side", there are no sign-offs, no prioritisation and no further development after launch.
• The trigger is frustration, not requirements. Irritation with the current system is a signal worth taking seriously — but it is not a specification. First establish whether configuration, training or a change of vendor would be enough.
• There is no budget for the years after launch. A CRM without an operating budget is an asset with an expiry date.
• Time pressure is high. If sales has to be in order within six weeks, a standard product is the only answer that can hold that date.

The reverse also holds. If you can clearly rule out several of these points, a custom build is not an extravagance but a sound investment decision. At that point it is no different in kind from deciding to buy a production machine rather than lease one.

Four weeks are enough if you work in this order and do not begin with product selection.

• Week 1 — write the processes down. Your three most important workflows, one page each, including the points where spreadsheets, email or a shout across the room currently fill the gap. Those points are your real requirements list.
• Week 2 — build a test, do not watch a demo. Set up two standard products in free trial instances with real data and run the same cases through both, with the people who will actually use them. A sales demo shows the ideal case; your test shows yours.
• Week 3 — do the maths and verify integrations. Build the five-year comparison for both paths and technically verify the interfaces that must work. Do not take the vendor's website at its word.
• Week 4 — decide and start small. If you buy, begin with one team and one process instead of moving the whole company at once. If you build, begin with a narrow first scope that goes live within a few weeks.

If you want an outside opinion at that stage, we will look at your situation as part of a strategy consultation — and we will tell you that a standard product is enough when it is. How to choose and compare an implementation partner in Switzerland generally is covered in our guide to choosing an agency. And if the answer really is to build, the next step is custom CRM development.