Custom CRM development.

A CRM that survives daily use needs eight building blocks, regardless of industry or size. Leave one out and you create exactly the side lists and spreadsheets you commissioned the system to eliminate.

• A data model that speaks your language. Not just contact and company, but your domain object: mandate, policy, property, case file, vehicle, batch — with its own states, relationships and required fields.
• Cases with states and an owner. Every case has a current state, a responsible person and a date by which something has to happen. Without those three, a CRM is an address book.
• Activities and an unbroken history. Who did what and when, linked to the case. That history is the real value of the system — it outlives staff changes.
• Roles and permissions. Who sees which records, who may edit, who may delete, who sees the amounts.
• Documents attached to the case. Upload, versioning, clear assignment. Documents living in inboxes are the most common reason a system goes unused.
• Search and lists. Full-text search and saved, filterable lists. Anyone who cannot see their work list in three clicks will keep working beside the system.
• Import, export and audit trail. Data has to come out in full at any time, and changes to sensitive fields have to be traceable.
• Reporting that supports a decision. A few clearly defined figures rather than a carpet of charts. Whether a KPI is worth anything in daily use comes down to whether somebody acts on it.

Only after those come the items that usually dominate the sales conversation: email integration, calendar, mobile use, templates, automations, mail merges. They are useful, but they cannot carry a system whose foundation is wrong.

Cut by process, not by feature — one complete workflow for one user group beats ten half-finished features for everyone. It is the single decision in the project that determines success or failure more than anything else.

In practice that means picking the process with the greatest daily pain, usually handling an incoming case from intake to closure. Build that one path completely, including permissions, documents and history, and put it into real operation with real data. Everything else — reporting, automations, the second user group, interfaces to further systems — goes onto a visible, prioritised list for later.

Two rules earn their keep here. First: whatever lives in a spreadsheet today belongs in the system; whatever nobody fills in today does not belong in the system just because it once appeared on a form. Second: every requirement gets one sentence explaining which decision it enables. Requirements with no decision behind them are almost always habits.

If the starting point is still open, we begin with a prototype for idea validation from CHF 10,000: a real data model, a usable interface and one process played through end to end. That costs a fraction of the full project and answers the most expensive question first — whether a bespoke solution is genuinely better in daily use. Technically such a system falls into the same category as our complex web solutions; for a first order of magnitude on the overall scope, use the project calculator.

Data migration runs in four steps — export, clean-up, test migration, production migration — and the effort sits almost entirely in the second. This is the expectation projects miss most often: reading the data in is not the hard part, the state of the data is.

• Export. A complete export from the old system including activities, attachments and history. Check early whether the old system can even produce that — with some products the export is the most expensive part of leaving.
• Clean-up. Merge duplicates, standardise company names, lift addresses out of note fields, assign orphaned contacts, fill in required fields. Nobody can take this work off you entirely, because only your team knows which of two records is the right one.
• Test migration. A complete run into a test environment, after which your team works there with real data for a week or two. Every error found gets corrected in the migration script, never by hand in the data — otherwise it is back on the next run.
• Production migration. A fixed cut-over date, a defined window, a documented way back. The old system stays available read-only for an agreed period afterwards.

Not everything should come along. Cases with no activity for several years belong in an archive, not in the new system. That is not cost-cutting but data protection diligence: personal data must be deleted or anonymised once its purpose has lapsed. The migration is the cheapest moment to enforce that rule for the first time.

Roles and permissions are modelled along responsibility, not along the org chart. The workable question for every record is: who needs to see this in order to do their job — and who does not?

A sound model has four layers. First the role (case handling, team lead, accounting, management, customer login), which bundles the basic rights. Second the scope: own records, team, everything. Third the field level: amounts, margins, HR data or notes can be hidden even when the record itself is visible. Fourth the action: view, create, edit, export, delete — with export and deletion deliberately drawn tighter than the rest.

Three recommendations from practice. Start tight and open up as needed; the reverse journey never happens. Log access to particularly sensitive data so that you can answer a subject access request. And treat customer logins as their own role with their own interface, not as a restricted employee view — otherwise the next extension is your internal security incident.

Technically this is routine work: authentication with a two-factor option, role checks on the server rather than only in the interface, and a check on every data access rather than only on page load. The effort does not sit in the implementation but in deciding the model beforehand. We settle that during the concept phase, together with the data model — both belong in the same session.

For a bespoke CRM, the revised Swiss Data Protection Act asks for three things above all: you must know which personal data you process and for what purpose, you must protect it appropriately, and you must be able to answer data subjects within the legal deadline. A server location on its own satisfies none of those obligations.

With a custom build the storage location is freely selectable — hosting in a Swiss data centre is a configuration decision rather than a vendor decision. That is the tangible advantage over an international standard product, particularly if your clients contractually require Swiss data storage, or if you work with health, HR or financial data.

What else belongs in the concept, so that the location is more than a sales argument: a permissions concept with documented roles; encrypted transport and encrypted backups; access logging for particularly sensitive data; defined retention and deletion periods with a mechanism that actually enforces them; a record of processing activities; and a rehearsed procedure for access and deletion requests. Where external services are involved — email delivery, document recognition, language models — each one belongs in the record with its purpose and storage location.

Take particular care with AI features. The moment customer data goes to an external language model, it leaves your infrastructure, even if the application itself runs in Switzerland. That is solvable, but it is a deliberate decision with a contractual basis — we work through it as its own item during AI consulting rather than settling it on the side mid-project. This page is not legal advice; for a binding assessment of your processing activities, involve a specialist.

In five steps, with a slice you can genuinely use as early as possible instead of one large handover at the end.

• 1. Scoping. Two or three working sessions: capture the processes, sketch the data model, settle the roles, clarify interfaces and data protection requirements. The result is a written scope with priorities — and honest feedback if a standard product would in fact be the better answer.
• 2. Prototype. A usable model of the core process with a real data model, from CHF 10,000. Your team tries it before the expensive parts get built. In our experience a third of the requirements change at this point — which is exactly what the step is for.
• 3. First production slice. One complete process including permissions, documents and history goes into real operation, running in parallel with the old system. From that moment the project delivers value instead of status reports.
• 4. Migration and expansion. Data migration as described above, then expansion in two-week steps along the prioritised list, with something visible after every step.
• 5. Operations. Hosting, backups, monitoring, security updates and an agreed allowance for further development. We hand over the repository, the documentation and the credentials in your name — even when you leave the running of it with us.

Technically we work with widely adopted tools rather than an in-house platform: Next.js on the front end, a relational database at the core, server-side permission checks, automated tests for the critical paths. The reason is not fashion but handover readiness — you should be able to change partner without starting again. What we have actually delivered is in our work.

A bespoke CRM costs money permanently, even in a year without new features — and anyone who does not budget for that does not have a cheaper system, they have an ageing one. This is where custom builds fail, almost never the development itself.

Recurring items: hosting and backups; monitoring and incident handling; updates to the framework and its dependencies, security advisories included, which arrive regardless of your wishes; adjustments when a connected system changes its interface; and further development for new requirements. On top of that, internally, the person who prioritises requirements and signs off results — without them even a good system drifts.

As a planning figure: budget a noticeable share of the original build cost every year for operations and maintenance alone, before a single new feature exists. That number belongs in the five-year comparison on CRM: buy or build, and it belongs there before you decide rather than after you have built.

The compensation is real: the cost does not rise with every additional account. If a hundred people occasionally set a status, or customers work in the system themselves, that is precisely the economic case for building — and the only one that holds reliably across five years.

We decline, or point you back to a standard product, when any of these applies — even when the enquiry is already concrete:

• No CRM is in use yet. Without at least a year of experience with a standard system, there is no basis for reliable requirements.
• The process is being rebuilt. Software freezes a workflow. If you are still searching, search inside a configurable standard product, not inside a codebase.
• Nobody internally owns it. Without a person authorised to decide on requirements and sign off results, you end up with a system that belongs to no one.
• There is no operating budget. We do not build a system whose upkeep from year two onwards is unfunded.
• You need demonstrable CRM references. We have built web applications with login, roles, documents and case processes — a complete CRM from scratch, not yet. If your procurement requires several comparable projects, that is a fair criterion against us, and we say so in the first conversation rather than afterwards.
• Time pressure is high. If sales has to be in order within six weeks, only a standard product will hold that date.

What does suit us: tightly cut domain applications sitting next to an existing CRM, client portals, case and approval workflows with several roles, and calculators and configurators that bring enquiries into the system in structured form. If you are still in the clarification phase, a strategy consultation is a better entry point than a quote.