Custom CRM systems
We design and develop custom CRM systems around a company’s actual processes: sales, customer and partner management, documents, payments, employee tasks, approvals, analytics, and integrations.
We build web applications using Laravel, PHP, and JavaScript, design databases and REST APIs, and develop customer portals and administration interfaces. A CRM can operate as a standalone system or become part of the company’s existing IT infrastructure.
CRM Built Around Your Business Processes
Off-the-shelf CRM platforms cover common sales scenarios well. Projects become more complex when a single deal passes through several departments, customers need their own portal, suppliers upload documents, accounting sends payment data from 1C, and management needs to monitor the entire process from one interface. The number of configurations and workarounds grows quickly.
A custom CRM is designed with its own data model and business logic. The system contains the entities that actually exist in the company’s workflow: customers, companies, facilities, requests, projects, contracts, payments, suppliers, tenders, insurance cases, or other industry-specific entities. Each entity has its own relationships, statuses, transition rules, access permissions, and automated actions.
This approach is well suited to B2B companies with complex sales cycles, service businesses, financial organizations, manufacturing, logistics, real estate, and projects where CRM gradually becomes the company’s primary operating system.
Data and Business Logic Come First
Development starts with the structure of the future system. We define users, roles, entities, relationships between them, and the lifecycle of key processes. Documents, financial data, notifications, integrations, and operations that should run automatically are analyzed separately.
Even the concept of a “customer” requires proper design. In B2B, one company may have 15 contacts, several legal entities, dozens of contracts, and 6 active projects running simultaneously. A contract may be linked to payments and documents, individual documents may belong to specific deal stages, and only certain employees may have access to financial information. These relationships need to exist at the database and server-logic level rather than being assembled from an arbitrary collection of interface fields.
Before active development begins, we define the main scenarios. The development team already knows what should happen after a deal is created, its status changes, a contract is uploaded, a payment arrives, or the responsible employee changes.
CRM Architecture
For most corporate CRM systems, we use a client-server architecture. The server side handles business logic, permissions, database operations, documents, integrations, and APIs. The web interface receives only the data and operations available to the specific user.
A modular monolith is often a practical starting architecture. Customers, deals, documents, payments, notifications, and other functional areas remain separated within the application while sharing a common codebase. This architecture is easier to develop, test, and maintain. Microservices are introduced in projects with a clear technical reason for them: independent scaling of individual components, high load, several development teams, or the need to isolate particular services.
We design the architecture with future development in mind. Two years after launch, the CRM may need to support a new department, a mobile application, a partner portal, or another accounting system. Adding a new module should not require rebuilding half of the project.
Backend: PHP and Laravel
For the server side of corporate CRM systems, we use PHP and Laravel. The framework provides established infrastructure for routing, authentication, validation, queues, events, database operations, caching, scheduling, and testing. This allows developers to focus on project-specific business logic instead of recreating basic application mechanisms.
The code is separated by responsibility. An HTTP controller receives the request and passes it further into the application, business rules are handled in the service layer, and data access remains separated from the interface. A complex operation such as processing a deal may affect several entities at once: change a status, record an event in the history, create a document, add a job to a queue, and send data to an external system.
Laravel supports background queues through Redis, Amazon SQS, and other drivers. Queues are useful for operations that should not run inside a regular HTTP request: generating a large report, importing several thousand rows, sending notifications, or synchronizing with an external API. The user saves the record and continues working while a separate worker process performs the resource-intensive operation.
Frontend and CRM Interfaces
A CRM interface is designed for everyday use. A sales manager may spend 6–8 hours a day inside the system, making the speed of routine operations particularly important. We design tables, filters, cards, search, bulk operations, forms, Kanban boards, change histories, and fast navigation between related objects.
The client side can be developed in JavaScript using React or another suitable stack. The choice depends on interface complexity. Component-based architecture works well for applications with many interactive states: a table, filter, record card, modal window, and action panel can exist as separate components with predictable behavior.
Responsive behavior is planned from the beginning. A manager may need to open a report on a laptop, a sales representative may check a customer record from a smartphone, and an employee working on site may update a status or attach a photo from a phone. Specific workflows can also receive dedicated mobile interfaces with a reduced set of functions.
PostgreSQL and Database Structure
For complex CRM systems, we use PostgreSQL as the primary relational database. Most corporate data has clear relationships: companies are connected to contacts, deals to companies, contracts to deals, and payments to contracts. A relational model fits this structure well and allows data integrity to be enforced at the database level.
We design the schema before the database contains hundreds of thousands of records. Data types, foreign keys, unique constraints, and indexes are defined in advance. A field used every day to search through 500,000 deals requires a different approach from a comment that is simply displayed inside a record.
Some rarely changing or project-specific attributes can be stored in JSONB while the core structure remains relational. This works well for additional entity characteristics whose composition varies between object types. Core relationships and data used for reporting remain normalized.
Redis, Caching, and Queues
We use Redis for fast caching, temporary data, locks, and queues. CRM systems regularly perform operations that do not need to query the primary database repeatedly: storing short-lived results, rate limiting, or coordinating background jobs.
Queues are particularly useful for integrations. An external system may take 5 seconds to respond or may temporarily become unavailable. CRM users should not have to wait for that response every time they save a deal. The job enters a queue, a worker sends the data separately, errors are recorded, and retries follow the configured rules.
Locks are used for operations that must not run simultaneously. They prevent situations where two background processes attempt to synchronize the same deal or generate the same document at the same time.
User Roles and Access Permissions
Corporate CRM systems rarely work with only two roles such as “user” and “administrator.” A sales manager may see their own deals, a department head the deals of an entire team, and a CFO payment data for several legal entities. A customer may have access only to their contracts, a supplier only to related orders, while a system administrator can manage users without access to certain commercial information.
Permissions are checked on the server for every protected operation. Hiding a button in the browser is not an access-control mechanism because an HTTP request can still be sent directly. The server independently verifies whether the user can open a record, modify it, delete a document, export a report, or call a particular API method.
We follow the principle of least privilege. OWASP ASVS specifically addresses access control and protection against scenarios where a user substitutes an object identifier in a request and gains access to another user’s record. For CRM systems containing contracts, financial information, and customer documents, this is a fundamental part of the security architecture.
Customer and Partner Portals
A single CRM can serve several types of external users. Customers may receive a portal containing contracts, payments, documents, and requests. Suppliers work with their own orders and files. Partners see the deals assigned to them and their current status. All portals use the same business logic and database, while the information available to each user is determined by their role and relationship to the specific object.
In one of our projects for a leasing company, the system included four types of portals: customer, manager, insurance company, and supplier. The platform handled contracts, payments, documents, tender workflows, insurance, and deal-stage monitoring. Financial data was received from 1C. A project of this scale is already close to a corporate information system, with customer relationship management remaining one of its central functions.
REST API and Integrations
A CRM almost always exchanges data with other systems. We design REST APIs, webhooks, and dedicated integration services for this purpose. Depending on the project, we connect CRM systems to 1C, websites, telephony, payment services, delivery platforms, email, electronic document management systems, and the customer’s internal software.
An API contract defines available methods, JSON formats, required fields, data types, response codes, and authorization rules. API versioning allows the interface to evolve without requiring every connected application to be rebuilt at the same time.
Repeated data transmission requires special attention. A connection may be interrupted after the server has already processed a request, causing the sender to retry it. For financial operations, order creation, and other sensitive scenarios, we design idempotency into the API: repeating the same request does not create a second payment or duplicate deal.
CRM Integration with 1C
Integration with 1C starts by defining which system owns each type of data. Customers may be created in the CRM, accounting details updated in 1C, and confirmed payment information transferred from the accounting system back to the CRM. Allowing both systems to independently modify the same records quickly leads to inconsistencies.
For each direction of data exchange, we define object identifiers, creation and update rules, data formats, error handling, and retry behavior. The CRM stores the relationship between its internal ID and the corresponding 1C object identifier. An integration log records the exchange time, transmitted data, received response, and error details.
Large synchronization jobs run in the background. Exchanging 10,000 counterparties or several years of payment history should not take place inside the user’s browser. The operation is divided into batches and processed through a queue.
Documents and Files
A CRM may store contracts, appendices, invoices, certificates, commercial proposals, photographs, and other files. Each document is linked to a specific system entity and has its own access rules. Versioning, approval statuses, and operation histories can be added to projects that require them.
File storage is separated from the primary database structure. The database contains metadata and relationships, while the files themselves are stored in a dedicated storage system. Large projects can use S3-compatible object storage. This architecture simplifies backups, scaling, and handling large volumes of documents.
Every uploaded file is validated on the server. The system checks allowed file types, size, and the user’s permission to attach the document to the selected object. Links to protected documents must not turn those files into publicly accessible resources.
Process Automation
Automation is built around CRM events. A deal is created, its status changes, a contract is signed, a payment arrives, or a task deadline expires — each event can trigger further actions.
Some rules are implemented directly in the business logic, while others are placed in configurable workflows. The system can create tasks, change responsible employees, send notifications, generate documents, call an external API, or add a background job to a queue. Execution histories are stored for critical operations.
Complex workflows are designed around defined states and permitted transitions. A contract with the status “Draft” may move to approval, then signing and execution. An accidental transition directly from draft to a closed contract is blocked by server-side logic. These restrictions reduce invalid data and make system behavior predictable.
Change History and Logging
In a corporate system, it is important to know who changed data and when. For critical areas, we store an operation history containing the user, timestamp, object, action type, and required technical details. A manager or administrator can reconstruct the sequence of events without searching through employee messages.
Technical logs and business history serve different purposes. The business history shows that a sales manager changed a deal value. The technical log helps a developer understand why an external API returned an error or a background job failed.
Passwords, access tokens, and other secrets are never written to logs. OWASP ASVS recommends logging authentication events and authorization failures while keeping logs protected and excluding sensitive data.
CRM Security
A CRM stores customer databases, commercial terms, contracts, personal data, and sometimes financial information. We design protection across several layers: authentication, server-side authorization, session management, input validation, API protection, logging, and infrastructure.
Passwords are stored only as secure hashes. Two-factor authentication can be added to projects with stricter security requirements. Application secrets, API keys, and database passwords remain in environment configuration and are kept out of the source code.
Connections to the CRM use HTTPS. Laravel provides built-in data encryption mechanisms based on OpenSSL; encrypted values are also signed with a MAC to verify their integrity. Sensitive fields can be encrypted at the application level.
We use OWASP ASVS as a reference for authentication, session management, access control, input validation, cryptography, APIs, and logging. ASVS defines three verification levels. Level 2 is intended for applications handling sensitive data and provides a practical baseline for most corporate systems.
Backups and Recovery
A backup is useful only when the recovery procedure has also been tested. For production systems, we configure database and file backups at a frequency appropriate to the project. Copies are stored separately from the production server.
An additional recovery point is created before major updates. Projects with higher availability requirements also define RPO and RTO: the acceptable amount of data loss and the time within which the system must be restored after a failure.
Performance and Data Growth
A CRM may start with 20 employees and 30,000 customers and grow to millions of related records over several years. We account for this growth in database structure, indexes, queries, and the architecture of background operations.
Large lists use pagination, searches are processed on the server, and resource-intensive reports are not recalculated from scratch every time a page is opened. Frequently used data is cached. Bulk imports, exports, and synchronization jobs are moved to queues. For bottlenecks, we analyze SQL queries and execution plans rather than attempting to solve every performance issue by adding more server resources.
Scaling starts with measurements. We monitor application response times, database load, background job duration, memory usage, and errors from external services. This allows us to identify the specific cause of a slowdown.
CRM Testing
CRM systems are tested at several levels. Unit tests verify individual business rules. Feature and integration tests cover HTTP APIs, database operations, and connected services. Critical user scenarios are tested from beginning to end.
For a deal, the complete path matters. We create a customer, open a deal, change its stages, verify permissions for different employees, generate a document, send data to an external system, and close the process. An error at any stage can leave the system in an inconsistent state even though every individual screen appears to work correctly.
Before release, we test database migrations and deployment in an environment close to production. Changing the structure of a table containing one million rows requires a different level of preparation from publishing a CSS adjustment to the interface.
Development and Releases
Source code is stored in Git. Development is carried out in separate branches and goes through code review. Projects use separate development and production environments at a minimum. Larger systems also have a staging environment where releases are verified before publication.
An automated pipeline can run tests and static analysis before deployment. Database migrations are versioned together with the source code. Developers can deploy a specific application version together with the corresponding data structure.
Updates are released in smaller increments. This makes them easier to test and roll back. A large project lasting 6–12 months should not become one enormous release on the final day of development.
How We Develop a Custom CRM
We begin by studying the company’s processes and collecting requirements. We define users, roles, data, integrations, and key scenarios. The next stage covers architecture and interface prototypes. Prototypes allow the future workflow to be tested before development begins and help remove unnecessary steps early.
Once the structure has been approved, development of the server and client sides begins. The project is divided into functional modules and intermediate releases. The customer receives working parts of the system as they are completed and can test them using real scenarios.
Closer to launch, production integrations are connected, existing data is migrated, and user roles and permissions are verified. Backups, background jobs, and error handling for external systems are tested separately.
After launch, we collect feedback from employees. Some decisions become clear only after several weeks of actual use: where a bulk operation is needed, which filter is used every day, which stage turned out to be unnecessary. The CRM continues to evolve together with the company’s workflow.
Custom CRM Development Cost
There is no meaningful fixed price for “one CRM system.” A project with 5 user roles, 40 screens, and 3 external integrations differs several times in scope from a small internal CRM used by a single department.
The estimate depends on the number of user roles, entities and interfaces, the complexity of business rules, document volume, integrations, migration of existing data, and performance and security requirements. Customer portals and custom analytics are estimated separately.
An initial estimate can be prepared after discussing the company’s processes. For a large project, we begin with analysis and design, then define the architecture, module structure, and development budget. This produces a much more accurate estimate than calculating the project from the number of pages in a technical specification.
Bitrix24 or a Custom CRM
Bitrix24 works well for conventional sales processes, pipelines, tasks, standard automation, and a large range of ready-made integrations. BFD also provides Bitrix24 implementation and development as a separate service.
We use custom CRM development for projects with a specific data model, several types of user portals, complex access logic, industry-specific workflows, and deep integrations. The project team controls the code and architecture, interfaces are designed around specific user roles, and future development is not restricted by the entity structure of an off-the-shelf CRM platform.
Both areas are handled within the same team. During the initial project review, we can evaluate both Bitrix24 and custom development architectures and select the more practical option before development begins.
Tell us who will use the system, which processes need to be automated, and what software your company already uses. We will review the project structure, propose an architecture, and estimate the development scope.
