LeadFlow: Scaling Internal CRM Infrastructure

djangohtmxpostgresqlinternal-toolscrmsoftware-architecture

Context

Manual lead management via spreadsheets was causing a 15% 'leakage' in the sales funnel. To scale operations without the high per-seat costs of enterprise SaaS, the CEO commissioned a custom internal solution that could handle rapid spikes in traffic while maintaining strict data integrity.

Decision

Architect a centralized Django CRM using a Service Layer pattern for lead distribution and HTMX for a high-performance, reactive frontend, deployed on-premise to maximize data privacy and minimize latency.

Alternatives Considered

Enterprise SaaS (Salesforce/HubSpot)

Pros
  • Instant deployment and industry-standard features
  • Extensive third-party integration ecosystem
Cons
  • Prohibitively expensive recurring per-user licensing
  • Difficult to customize for proprietary 'Round-Robin' logic

Single Page Application (React/Django REST)

Pros
  • Rich, highly interactive user interface
  • Clean separation of frontend and backend
Cons
  • Significantly longer development cycle (exceeding 3-month window)
  • Higher maintenance complexity for a solo engineer

Reasoning

Django provided the robust ORM and security features needed for a 'single source of truth.' By using HTMX, I achieved the interactivity of a modern SPA without the overhead of a JavaScript framework, allowing for rapid iteration on the sales dashboard while meeting the CEO's aggressive delivery timeline.

Solving the “Spreadsheet Graveyard”

Moving from fragmented Excel files to a unified system required more than just a database; it required a rethink of how sales data flows through the organization.

1. The Service Layer & Lead Distribution

To prevent “fat models” and keep the codebase maintainable, I implemented a Service Layer. This handles the proprietary Weighted Round-Robin logic. When a lead hits the system via webhook:

  • Validation: The service checks for duplicates and sanitizes the input.
  • Assignment: It queries the current workload of active reps, using PostgreSQL’s select_for_update() to prevent race conditions during concurrent assignments.
  • Notification: It triggers immediate alerts via Redis/Celery to ensure the “Speed to Lead” remains under 5 minutes.

2. High-Density UI with HTMX

Sales reps spend their entire day in the CRM. The interface needed to be “invisible” and fast. HTMX allowed for:

  • Inline Editing: Updating lead temperatures or notes without a full page refresh.
  • Real-time Filtering: Searching through thousands of records with instant server-side results.
  • Reduced Latency: By sending HTML fragments over the wire instead of heavy JSON payloads for client-side rendering, the UI feels remarkably snappy on internal networks.

3. Data Integrity as a Feature

Unlike spreadsheets, the CRM enforces strict relational constraints. By leveraging PostgreSQL, we eliminated “data rot”:

  • Enforced Workflows: Leads cannot skip stages (e.g., from ‘New’ to ‘Closed’) without required documentation.
  • Automated Fail-safes: If a lead isn’t claimed within 15 minutes, a background task re-assigns it to the next available rep.

Impact on Sales Operations

  • Visibility: The CEO now has a real-time dashboard showing the exact dollar value currently sitting in each stage of the pipeline.
  • Efficiency: Automated distribution eliminated 100% of the manual labor previously spent “handing out” leads.
  • Performance: Average response time dropped from hours to less than 5 minutes, directly contributing to an 18% increase in first-month ROI.

The Road Ahead

The next phase of LeadFlow involves integrating a machine learning “Lead Scoring” module (ChurnGuard/LeadGuard ML) to prioritize high-value targets based on historical conversion data, further optimizing the sales team’s daily workflow.

Would you like me to help you draft the technical deep-dive on the “Weighted Round-Robin” algorithm used in the Lead Assignment engine?

All decisions