How to build a learning CRM for your portfolio

A learning CRM is one of the best portfolio projects because it demonstrates work with real business processes. It includes users and roles, related entities, a sales pipeline, tasks, a change history, analytics, and access restrictions. Such a project demonstrates not only an interface, but also an understanding of complete system architecture.

Begin with a specific scenario. For example, the CRM may be built for a small company that receives enquiries from its website, distributes them among managers, and guides each client through to payment. A clear context helps define the necessary functions without turning the learning project into an endless copy of a large enterprise system.

Two roles are sufficient for the first version: administrator and manager. The administrator manages employees, the pipeline, and general settings. A manager sees assigned clients and deals, creates tasks, adds comments, and changes the sales stage. Role verification must take place on the server rather than merely hiding buttons in the interface.

The project’s main entities are user, client, contact, deal, pipeline stage, task, comment, and history event. One client may have several contacts and deals; a deal has a responsible manager, current stage, amount, expected closing date, and a set of activities. Relationships should be enforced with foreign keys and database constraints.

The core business process works as follows: a new enquiry creates a client and a deal; the administrator or system assigns a manager; the manager schedules the next contact, moves the deal through its stages, and records the result. A deal must not be closed without mandatory data, while an overdue task should appear as requiring attention.

The interface can be divided into a dashboard, client list, deal Kanban board, tasks, client profile, and administration section. The client profile should combine contacts, deals, comments, and a timeline of activity. The user should not have to move between many screens to understand the current state of work.

A modular monolith is suitable for the learning architecture. The client application handles the interface, the server handles business logic and access control, PostgreSQL stores persistent data, and file storage holds documents. Separate microservices would only complicate the project at this stage without adding value to the portfolio.

The API should be designed before screens are written in bulk. For every operation, define the address, method, input data, possible errors, and access permissions. OpenAPI documentation makes the contract clear, allows requests to be tested independently from the interface, and demonstrates a disciplined engineering approach to employers.

Special attention should be given to the activity history. The CRM should record deal creation, stage changes, manager assignment, amount changes, and task completion. This log helps investigate errors and shows that the developer understands the importance of auditing in business systems.

A few useful indicators are sufficient for the dashboard: the number of new deals, the value of the active pipeline, conversion between stages, overdue tasks, and manager results. The data should be calculated from real records, with filters by period and responsible employee.

Security includes protected authentication, storing passwords only as strong hashes, checking permissions for every server-side action, validating input, rate limiting, and handling files securely. Passwords, tokens, and other secret information must never be written to the log.

The project must be covered by tests. Unit tests verify calculations and transition rules, integration tests cover the API and database, and an end-to-end test follows the main path from enquiry creation to successful deal closure. Attempts by a manager to open another person’s data or perform an administrator action should be tested separately.

The final version should run through Docker and include automated code checks, database migrations, demonstration data, and a public test environment. The repository needs a clear problem description, an architecture diagram, launch instructions, API documentation, test accounts, and images of the key scenarios.

The portfolio should present the decisions made rather than the number of screens. A strong description explains the problem the CRM solves, why the data model was chosen, how roles are implemented, which scenarios were tested, and how the system could develop further. This makes it possible to assess the developer’s thinking without examining every line of code.