Develop Mode: Multi-Repo CRM with AI Agent Layer
April 26, 2026
This case study covers a real Develop Mode engagement on an existing production codebase. Unlike a greenfield build, Develop Mode here had to navigate an existing system — understand its structure, follow its conventions, and make targeted changes without breaking what was already working.
At a glance
| Project | Agentic CRM (B2B + B2C) |
| Mode | Develop Mode — existing codebase |
| Repos | 3 — CRM API, AI Agent, CRM Frontend |
| Stack | Python, FastAPI, Next.js, PostgreSQL, VTEX API |
| Tasks executed | 11 across ~3 weeks |
| Work types | Feature builds, bug fixes (soft-delete, sync issues), security patches, greenfield admin frontend |
| Human role | Task selection, code review, deployment |
The project
An agentic CRM system with three interconnected repositories:
- CRM API — the core business logic layer (Python/FastAPI).
- AI Agent — a dedicated agent service that sits above the CRM API.
- CRM Frontend — a Next.js admin interface for internal operations.
The platform serves both B2B (company accounts, multi-user) and B2C (individual customers) users, with a full integration into VTEX for e-commerce operations.
What Develop Mode handled
The tasks below are real, taken from the completed task log. They span several weeks of work across the three repositories.
User address flow — CRM ↔ VTEX integration
Brief: “The frontend sends the user address to be stored in the CRM. I want the flow to be: FE sends address → stored in CRM → synced to VTEX.”
What Ileen built: A complete address synchronisation flow. The CRM API receives address data from the frontend, persists it, and propagates it to VTEX via their address API. Ileen handled the data mapping between the CRM schema and VTEX’s expected format, including error handling for VTEX sync failures without rolling back the CRM write.
B2B admin approval flow
Brief: “If you want a B2B to be checked by [the team] we can eventually keep that account inactive (is_active=False) until someone activates it.”
What Ileen built: A gated activation flow for B2B accounts. New B2B
registrations are created with is_active=False. An admin endpoint allows
internal staff to review and activate accounts. The frontend surfaces inactive
B2B accounts in a pending approval queue. Email notification hooks were added for
activation events.
B2B/B2C user browse list
Brief: “The frontend doesn’t allow browsing B2B and B2C users without knowing their name or surname in advance. Why? I should be able to browse.”
What Ileen diagnosed and fixed: The existing list endpoints required exact-match filters on name/surname fields. Ileen added paginated browse endpoints with optional fuzzy search, returning full B2B/B2C user lists with appropriate role-based access control. No name knowledge required to start browsing.
Remove deprecated entity, surface new column
Brief: “We removed the ‘representatives’ table from the database. The APIs need to be corrected by removing the unused CRUDs.”
What Ileen did: Audited all routes, services and models referencing
representatives. Removed CRUD endpoints, cleaned up foreign key references,
surfaced the user_id column that was previously hidden behind the now-removed
relation. Validated no other endpoints had implicit dependencies on the removed
table.
Propagate profiles[] through register and login
Brief: “Auth/register API: AVON frontend will send user type to be saved. Populate the profiles array on registration and return it on login.”
What Ileen built: Extended the registration payload to accept a profiles
array (B2B/B2C/admin roles). On login, the response now includes the full
profiles array so the frontend can make routing decisions without a second API
call.
Fix soft-delete read semantics
Brief: “Can you check the delete address functionality? It returns success but the address still exists and is not deleted.”
What Ileen found: The DELETE endpoints used soft-delete (setting a
deleted_at timestamp) but the corresponding GET endpoints were not filtering
out soft-deleted records. The bug produced a success response on delete but the
records reappeared on subsequent reads.
Fix: Audited all read paths across the CRM router, added deleted_at IS NULL
filters consistently. Validated that soft-deleted records were excluded from list
endpoints, single-record fetches and VTEX sync operations.
Greenfield CRM frontend
Brief: “I want to build a frontend for the CRM. It must be able to interact with CRM tables using an ADMIN account.”
What Ileen built: A greenfield Next.js admin interface. Ileen bootstrapped the project, configured authentication against the CRM API using an admin account, and built data tables for each CRM entity with create/read/update/delete operations. The frontend respects the CRM’s role-based access control — admin credentials unlock all tables.
Security patch + build fix
Brief: “npm warn deprecated inflight@1.0.6 — this module is not supported and leaks memory.”
What Ileen did: Identified the deprecated transitive dependency, resolved the dependency tree conflict, patched the Next.js security advisory that had surfaced alongside it, and fixed the build break that the dependency update introduced. The fix was applied without changing any application behaviour.
A second engagement: Multi-Platform Mobile Suite
In parallel, Develop Mode worked on a different multi-repo product — a full-stack mobile suite with separate iOS, Android, backend and backoffice repositories. One task from this engagement is worth highlighting because it crosses three runtimes at once:
p5.js component for webview (iOS + Android)
Brief: “Create a simple p5.js component that integrates natively with our Kotlin/Swift frontends to add a new modal.”
What Ileen built: A self-contained p5.js sketch rendered in a webview, designed to be embedded inside both the iOS (Swift) and Android (Kotlin) native apps. The component communicates with the native layer via JavaScript bridge events. No native SDK dependency — the entire component lives in the webview.
What made this engagement different from Design Mode
In Design Mode, Ileen starts from a blank slate and produces architecture and plans. Here, Ileen had to:
- Read and understand an existing codebase across three repos before touching anything.
- Follow existing conventions — naming, patterns, folder structure — not introduce its own.
- Debug real bugs — the soft-delete issue required tracing a symptom (wrong behaviour on read) back to a root cause (missing filter across multiple endpoints).
- Work incrementally — each task was a discrete unit; Ileen picked it up, completed it and moved on. The user stayed in control of what to work on next.
Honest limitations
- Ileen does not have access to a running environment during development. It cannot run the app, execute tests or observe live behaviour. All validation is static (code analysis, test files if present).
- Complex bugs that require live debugging (e.g., race conditions, production-only failures) cannot be diagnosed purely from code. The user must reproduce and describe the symptom.
- Each task is independent. Ileen does not automatically detect side effects of a change on other tasks unless they are in the same task scope.
- The VTEX integration required the user to provide API documentation and credentials. Ileen cannot discover undocumented external APIs on its own.
The pattern that makes Develop Mode useful on existing codebases
The value is not writing code fast. Any developer can write code fast.
The value is entering an unfamiliar codebase, understanding it, and making targeted changes without introducing regressions — repeatedly, across tasks, across repositories.
For a team managing multiple repos in parallel, this compresses the ramp-up time on each task and removes the context-switching cost for human developers.