Key Takeaways
- Most of a CRM is generic plumbing: users, roles, record history, search, import, API. AtroCore covers that part, so a custom CRM only has to add what is specific to your business.
- A basic data model and the first workflows around it take a couple of hours to configure. The real time goes into the structures nobody else has.
- Built-in master data management produces golden records for customers, suppliers, and partners, which a classic CRM does not do.
- AtroCore ships no calendar sync, no mass mailing engine, and no ready-made CRM data model. You design the CRM yourself.
Companies build a custom CRM for one reason. Their customer relationships do not look like the ones Salesforce, HubSpot, and Dynamics were designed around.
A machine builder tracks installed equipment at customer sites, each unit with a serial number, a service contract, and a spare parts history. A chemical distributor sells the same material to one customer under three specifications and two pricing agreements. A building materials supplier deals with a buying group above the customer and a construction site below it. None of these are exotic. They are just not sales pipelines with five stages.
You can force this into custom objects on an off-the-shelf CRM. Teams do it every day. The bill arrives later, in per-seat licenses that grow with headcount and in the processes nobody automated because the platform made them awkward.
Only A Small Part Of A CRM Is Actually Yours
List what a working CRM does. User accounts, roles, permissions per record and per field, change history, search, import and export, file attachments, notifications, an API for the neighboring systems. None of it is specific to your company. It is identical in every CRM ever shipped, and it eats most of a from-scratch budget.
What is specific to you is smaller: the data model, the process rules, the integrations, and the two or three screens your team lives in.
The parts of a CRM that take the longest to build correctly are the parts no user ever asks for.
AtroCore inverts that ratio. It is a data platform under GPLv3, used as the base for PIM, DAM, MDM, and project management products, and it arrives with the generic layer already built and tested (source: AtroCore on GitHub). What you add on top carries your business logic.
The Data Model Is Configuration, Not Code
This is the strongest argument for the platform in a custom CRM project.
Entities, fields, relations, hierarchies, and attributes are defined in the administration panel. You create an entity called Installed Unit, relate it to Account and Product, give it a serial number and a link to a Service Contract. You add a hierarchy above Account so a buying group sits over its members. You attach attribute sets per customer type, so an OEM record carries fields a distributor never shows. Validation rules, change history, and access control apply to every entity you create.
A conventional starting model: accounts, contacts, opportunities, tasks, plus the first workflows connecting them, takes a couple of hours of configuration in projects we implemented. Nobody should quote a project for that part. The budget belongs to the structures nobody else has.
The REST API covers 100% of the model, custom entities included. No controller to write, no endpoint to document. The API exists because the entity exists.
Access rights follow the same logic. Every record carries an owner, an assigned user, and the teams allowed to see it, and roles restrict access down to single fields. That is how sales territories, key account protection, and a service department that reads contracts but never edits prices get built, without writing a permission check.
In projects we implemented for industrial equipment and building materials companies, this step decides everything that follows. Teams that spend two weeks modeling accounts, sites, contracts, and quote positions against their real ERP keys get a system their salespeople trust. Teams that skip it rebuild the model in month four, once the first sync exposes that the ERP customer number is not the key the CRM uses for an account.
Workflows That Do The Boring Work
The second half of a custom CRM is process. AtroCore handles it with workflows and actions, both configured rather than coded.
A workflow listens to one entity and fires before or after create, update, or delete. Conditions are basic, built with AND, OR, and NOT over fields, or written as a Twig script when the logic needs more room (source: AtroCore workflow documentation).
The action types matter more than the trigger mechanics. Create and Update write records. Upsert handles bulk create and update, matching on identifiers or unique fields. Send Notification pushes an in-app message or email to the owner, assigned user, or followers of a record. Error Message blocks a save and explains why. Action Set runs several at once, and Import, Export, and Connector actions move data between systems in the same chain.
Email is the part people underestimate. The Send Email action uses templates with a Twig subject and body, one version per locale, an SMTP connection you choose, and an option to attach files held on the record. A workflow can watch service contracts, catch one crossing ninety days to expiry, create a renewal task for the account owner, send the customer a templated email carrying the contract number and the equipment list, and set the status to renewal due. Four steps of a sales process, all configuration.
Actions also run without a trigger, as a button on a record page, a mass action, or a scheduled job.
A workflow your successor can read in the admin panel is a workflow your successor can maintain.
That readability answers the usual objection to custom software. The model sits in the entity manager, the automation in the workflow and action records, the screens in the layout manager. A developer who joins two years after go-live opens the admin panel and sees how the system works.
Upgrades behave the same way. Custom modules live in their own packages instead of modifying the core, so platform updates do not overwrite them, and the REST API covers your configuration as well as your data, which means a change tested on staging can be replayed on production through a script rather than clicked twice from memory.
The same split between configuration and code decides what AI assistance is worth here. It speeds up custom CRM development, and what it writes is still code you own forever. Veracode's testing across more than 100 models found security pass rates stuck around 55% while syntax correctness climbed past 95%. On a platform, the exposed surface shrinks to Twig conditions and import mappings a person reads in a minute, and a prompt still carries only what its author knows about your approval rules.
Getting Data In And Out
A CRM that does not exchange data with the ERP becomes a second version of the truth within a quarter.
Import and export run as feeds: a mapping between file columns or API fields and your entities, saved as a record and executed manually, on a schedule, or from a workflow. The same mechanism handles the migration from the old CRM and the nightly delta from the ERP. Bidirectional synchronization with a system that exposes a REST API runs in days rather than weeks, because the mapping is configuration and the API already covers every field you added.
The technical side of GDPR comes with the platform. Records for a person can be found, exported, corrected, and deleted; every change is logged with its author; access is restricted down to the field level; and the system runs on your infrastructure with no third-party processor.
The interface is responsive, so the same CRM works on a phone in a customer's parking lot, on a tablet during a site visit, and on a desktop, under any operating system. Chrome and Edge install it as an app, so field sales get an icon instead of a bookmark.
Golden Records, Which A Classic CRM Does Not Maintain
The same customer usually exists several times: once in the ERP, once in the webshop, once in a trade fair spreadsheet, twice in the old CRM with different spellings. Validity's 2025 survey of 602 CRM users found that 76% consider less than half of their CRM data accurate and complete. In migrations, duplicates are what we find first.
Matching those records, merging them, and keeping one authoritative version per customer, supplier, or partner, with a trace of which source gave which value, is master data work. Off-the-shelf CRM products offer duplicate detection and stop there.
Here the matching happens at the door. Import feeds identify incoming records by unique fields and update instead of duplicating; records can be compared side by side and merged, and change history shows which system last touched which value. Master data management sits in the AtroCore core, so the golden record is the point of the system. Sales, service, and the ERP read the same customer.
Where AtroCore Stops Short Of A Classic CRM
- No calendar sync. Tasks with owners and due dates exist. Two-way synchronization with Outlook or Google Calendar is not a ready feature. Build it against the API, or keep scheduling where it lives today.
- No mass mailing engine. Transactional and notification email over SMTP works well. Campaigns, unsubscribe management, and bounce handling are a different discipline. Connect Brevo or Mailchimp over REST.
- No telephony. Click-to-call and call logging need an integration.
- Advanced reporting is a paid module. The free core gives you list views, filters, and dashboards. The database and the API stay open, so Metabase or Power BI can read the CRM directly.
- No prebuilt CRM. Nothing called Lead or Opportunity exists until you create it, which is configuration rather than a project, but yours to do.
None of these block a project. All are reasons to scope one properly.
Open Source CRM As The Wider Option
AtroCore sits inside a larger category worth knowing. Open source CRM systems such as EspoCRM, SuiteCRM, and Odoo ship a ready model for lead and contact management, opportunities, calendars, and campaigns, which covers the gaps listed above, and all of them can be self-hosted.
The property that matters is the source code. You can change any part of the system and keep that change through upgrades, which ends the vendor lock-in that a closed-source product never lets you out of. If the gaps in a ready sales model are small, one of those systems closes them faster. If the customer data itself has unusual structure, a data platform is the better base for a custom CRM.
When A Custom CRM Makes Sense
For a twenty-person sales team running a conventional sales pipeline with standard reporting, an off-the-shelf CRM is cheaper and faster. Buy it.
Custom CRM development earns its cost when your customer data has structure a five-stage sales pipeline cannot hold, when the CRM exchanges data with an ERP every hour, when user count makes per-seat pricing painful, or when the same platform also carries supplier and partner master data instead of adding another system beside it.
The core is open source under GPLv3, so adding the twentieth or the two hundredth user does not change the license.
The total cost of ownership sits in different places than a subscription. What you pay for is a server, the CRM implementation, whichever premium modules you need, and somebody who owns the system afterwards. Over five years, that suits companies with many occasional users and unusual processes, and a small team with a simple sales pipeline badly.
Start with one process. Model accounts and their hierarchy, load real data, build the three workflows that hurt most, and give it to five people for a month. Then decide whether to keep going.