Modular CRM/ERP platform, designed and built solo with AI agents
A modular CRM/ERP designed to replace an off-the-shelf portal at a medical-equipment distributor. I did the analysis, architecture, implementation and hardening; AI coding agents wrote most of the code under my control. Deployed on the client’s server as a pilot.
45Django apps in a modular monolith
5.5 wk359 commits, one author
72test files; 1C and mobile APIs covered
An own CRM/ERP, designed to replace an overgrown boxed portal: in pilot
Before
Sales, warehouse, service and documents lived in a portal with an ever-growing set of add-ons; every change meant touching that set.
What I did
I analysed, designed and built a modular system myself — clients and deals, contracts, warehouse, procurement, delivery, mail, chat; AI agents wrote the code under my control.
After
In 5.5 weeks of development the core was built and a pilot deployed; it runs in a separate business line of the company — sales of metalworking machines (3 users).
Context and scale
Jun–Aug 2026. About 140k lines of Python, ~220 data models, ~110 API views, 26 background jobs; a Flutter mobile client, an Electron desktop client and a 1C extension. Pilot on the client’s server since August: 3 users, the client base imported (~150 companies), a handful of live deals.
Problem
Sales, warehouse, service and documents were spread across a customised Bitrix24, about 30 portal apps and separate side services; the exchange with 1C had stopped (see the Bitrix24 case). The company depended on code it did not control.
Analysis and options
Options: keep extending Bitrix24 (closed 1C connector, vendor modules, growing workflow load), buy another boxed CRM (same integration problem), or build a platform with its own source code and a migration path from Bitrix24. Chosen: build — while stabilising Bitrix24 in parallel so the business keeps running.
Architecture
People
Sales, warehouse, service staff
Field engineers (mobile)
System
Web applicationDjango · HTMX · REST · WebSocket
Background workersCelery · beat
DatabasePostgreSQL 16
Broker & channelsRedis 7
Document serverOnlyOffice
Mobile & desktop clientsFlutter · Electron
External systems
1C (accounting)
Bitrix24 (migration source)
EDI operators
LLM API
Mail, push
Main data flows
Domain events are written to an outbox in the same transaction; 1C pulls them over REST and acknowledges each one.
Bitrix24 data is imported once over REST or directly from its database, idempotently through an ID map.
Workflow rules and the “Secretary” orchestrator turn domain events into tasks for roles.
Mobile clients sign in through the platform’s own OIDC provider (PKCE) and sync offline changes.
Key decisions and trade-offs
Modular monolith, not microservices. One author, one transaction boundary, one deployment. 45 apps with explicit borders keep the option to split later.
Transactional outbox for 1C. 1C pulls and acknowledges events; the portal never pushes blindly. Cost: 1C needs its own extension.
Processes as data. A workflow engine with triggers and robots, so process changes do not need a release.
AI assistant behind a judge (in progress). Rubric, fact-check and dry run before any write; permissions are enforced by the core, not by the model.
What was done
CRM core: companies, contacts, leads, deals, kanban, roles and org structure, multi-organisation, change history.
Contracts, tasks, calendar; stock with serial numbers and batches, procurement, receiving, shipping, delivery routes, production.
Mail, WebSocket chat, notifications, BI dashboards, docx print templates, imports.
An .ai/ folder with rules, roadmap, handoff and specifications kept the AI agents consistent across 359 commits.
Result
A working pilot, deployed with all migrations applied and not yet in daily operation; the next step is moving the first live process over from Bitrix24.
What I would do differently
I would agree the pilot scope and the first live process with users before building breadth: 45 apps in 5.5 weeks are easy to build with agents, adoption is the slow part.