20 KiB
DRE Functionality Gap Audit
Date: July 25, 2026
Purpose: Identify what's needed to go from static HTML portal to a functional end-to-end debt recovery system
Audience: Germaine Brown, Tony Brown, Anita Brown
Executive Summary
The DRE project has a mature specification (detailed fee structures, tiered recovery workflow, 8 letter templates, compliance framework, AI analysis design) and a polished static HTML portal (12 pages across public/internal, dark theme, consistent nav, Agent DRE chatbot widget). However, there is zero backend infrastructure connecting the portal to any real data or services. Every page uses static mock data. No claim submission works end-to-end. No payment can be collected. No letter can be sent.
The gap from "looks like a business" to "is a business" is roughly 3-6 months of focused backend engineering, depending on scope.
Part 1: Current State — What Actually Exists
✅ Working Infrastructure
| Component | Status | Details |
|---|---|---|
| TwentyCRM | Running | PostgreSQL + Redis + NestJS at crm.debtrecoveryexperts.com. Custom objects created: Debtors, Claims, CaseNotes, Payments. Claim→Debtor relation exists. Basic schema populated. |
| DocuSeal | Running | Deployed at sign.itpropartner.com. API token exists (info@itpropartner.com). |
| IMAP Email Poller | Running | Python script polls dre@ and collections@ every 60s via Hermes cron. Writes to /var/www/internal/data/dre-mails.json. |
| DRE MCP Server | Running | FastMCP server on localhost:8900. 3 tools: get inbox, get pending letters, update letter status. Reads/writes static JSON. |
| Inbox Page | Working | /var/www/internal/inbox.html fetches from dre-mails.json via JS. |
| Caddy Reverse Proxy | Working | portal.debtrecoveryexperts.com serves public pages, crm.debtrecoveryexperts.com proxies to TwentyCRM. |
| Scraping Stack | Configured | Firecrawl, ScrapingAnt, SearXNG all have API keys and are tested. |
| Compliance Docs | Drafted | 3 documents (ToS, Privacy Policy, Compliance Manual v1.1 — 23 sections). Mechanics lien research. Credit reporting analysis. All marked DRAFT — attorney review required. |
| Letter Templates | Documented | 8 templates: 3 auto (onboarding, under review, LPOA enclosed), 5 queued (soft touch, formal demand, lien threat, escalation, legal action). |
✅ Portal Pages Deployed
Public (/var/www/capabilities/):
debt-recovery.html— intake form with Agent DRE chatbot, real file upload, elevator-pitch responseslogin.html— SSO-only gateway pointing to Cloudflare Accessdre-fee-calculator.html— 4-tier fee projection widgetdre-pay.html— static debtor payment landing page
Internal (/var/www/internal/):
index.html— landing page with 4 navigation cardsdre-dashboard.html— claims dashboard (102 lines, mock data)dre-case-aging.html— stalled case monitor (158 lines, mock data)dre-client-dashboard.html— client view preview (mock data)letter-queue.html— demand letter composer with AI sidebar, approval workflow, Anita notification (1321 lines, full-featured mockup)dre-analytics.html— AI score distribution, recovery by tier, monthly trends (304 lines, mock data)inbox.html— unified inbox from JSON endpoint (357 lines, connected to real data)
Part 2: What's Missing — The Backend Gap
Critical: No Backend API Server
The single biggest gap. There is NO backend service that the portal pages can call. Every page uses hardcoded mock data. No claim submission pipeline exists — the intake form's submit button goes nowhere. No case management API. No payment processing endpoint.
What's needed:
- A Python (FastAPI) or Node.js API server
- REST endpoints for: claim submission, claim status, case notes, payments, debtor lookup
- Database: either build on top of TwentyCRM's GraphQL/REST APIs, or deploy a separate PostgreSQL database
- Authentication: JWT or session-based auth for clients and DRE staff
Missing Integrations (All of Them)
| Service | Spec Requirement | Current State | Gap |
|---|---|---|---|
| Stripe Connect | ACH payments, 0.8% cap $5 | No keys in .env | Must register for Stripe Connect, get API keys, build payment flow |
| DocuSeal API | Automated signing envelopes for LPOA, ToS | DocuSeal deployed but NOT integrated into portal | Build API calls from portal to DocuSeal for automated signing requests |
| LetterStream | Certified mail, ~$8.34/letter | API credentials exist (rzv56x1v / 5ezy56k2ny7a8vx14u). Account needs Automation mode activation. | Must activate account, then build API integration |
| Online Notary (OneNotary/Proof) | RON for LPOA, ~$25/session | No account, no API keys | Must create account, integrate API |
| Cloudflare Turnstile | Bot protection on intake form | Not implemented on debt-recovery.html | Add Turnstile widget |
| Partner Law Firm | Litigation referral, 25% fee split | No agreement in place | Business relationship needed |
Missing Automation Workflows
| Workflow | Spec Says | Current State |
|---|---|---|
| Claim submission pipeline | Client submits → AI scores → team reviews → accept/reject → LPOA → recovery | Submit button is decorative |
| AI Claim Analysis | Claude Opus scores 0-100, weakness analysis, debtor research | Not built. Scraping keys exist but no scoring pipeline |
| Automated letter sending | Templates 1-3 auto-send on trigger events | Templates exist as text docs. No sending code |
| Demand letter approval flow | Anita drafts → Tony/Germaine approve → send via collections@ | Letter-queue.html has the UI but no backend to persist or send |
| LPOA generation & notarization | DocuSeal envelope → sign → notarize via RON | Neither automated |
| Tier progression | Day 1-5: Tier 1, Day 7-14: Tier 2, etc. | No cron jobs or timers to advance tiers |
| Case binder generation | Two PDFs + ZIP on close | Not built |
| Payment disbursement | Receive funds → deduct fee → disburse to client | No payment processing at all |
| Notification system | Hourly approval reminders to Germaine + Tony | Script exists but reads from non-existent file |
| Audit trail | Every edit tracked: who, what (old→new), when, why | Not implemented |
Infrastructure Gaps
| Issue | Impact |
|---|---|
No internal.debtrecoveryexperts.com in Caddy |
Internal pages are not accessible — DNS resolves but no Caddy route exists. The entire internal dashboard (Claims, Aging, Letters, Inbox, Analytics) cannot be reached by the team. |
| TwentyCRM relations incomplete | Payment→Claim and CaseNote→Claim relations are missing. These are needed for associating payments and notes to claims. |
| DRE MCP server too minimal | Only reads static JSON files. No CRUD operations. No integration with TwentyCRM. |
No pay.debtrecoveryexperts.com resolution |
DNS resolves but no Caddy route. Debtor payment URL in all letter templates points to a non-existent service. |
Legal/Compliance Prerequisites for Operations
| Requirement | Status |
|---|---|
| Texas Debt Collector Bond/Registration | NOT DONE — Texas Finance Code Ch. 392 requires third-party collectors to be bonded/registered. This is a legal prerequisite before collecting any debt. |
| Attorney Review of All Drafts | NOT DONE — ToS, Privacy Policy, Compliance Manual all marked DRAFT. Must be reviewed by a Texas-licensed attorney. |
| FDCPA Compliance Implementation | NOT DONE — Validation notice, Mini-Miranda, cease communication protocols must be built into the system, not just documented. |
| LPOA Template Finalization | NOT DONE — Must be legally reviewed. Current docs mention it but no final template exists. |
Part 3: Minimum to Go Live with ONE Real Claim
If Germaine and Tony need to accept ONE claim, send ONE demand letter, and collect ONE payment (even manually), here's the absolute minimum:
Phase 0 — Legal (Do First — 2-4 weeks)
- Attorney review of ToS, Privacy Policy, Compliance Manual, LPOA template
- Register with Texas — bond/registration as debt collector under TX Finance Code Ch. 392
- Open business bank account for trust/escrow of collected funds (required by FDCPA)
Phase 1 — Manual MVP (2-4 weeks)
- Build basic API server with:
- POST
/api/claims— accepts intake form submission, writes to TwentyCRM or SQLite - GET
/api/claims/:id— returns claim status - Basic auth (API keys or simple JWT)
- POST
- Wire intake form submit —
debt-recovery.htmlform → POST to API - Build claim dashboard backend — replace mock data in
dre-dashboard.htmlwith real API calls - Stripe payment link — create a manual Stripe payment link for the debtor (no integration needed, just a hosted page)
- Send first demand letter manually — use LetterStream web UI or print/mail
Phase 2 — Semi-Automated (2-4 weeks)
- Stripe Connect integration — full API integration for automated payment collection
- LetterStream API integration — automated certified mail from portal
- DocuSeal API integration — automated LPOA signing requests
- Email automation — auto-send templates 1-3 on trigger events
Part 4: Prioritized Punch List
🔴 TIER 1 — BLOCKERS (Can't go live without these)
| # | Task | Rationale | Effort |
|---|---|---|---|
| 1 | Attorney review of all legal documents | ToS, Privacy, Compliance Manual, LPOA are all drafts. Operating without reviewed documents = regulatory risk. Texas bond/registration also falls here. | 2-4 weeks (external) |
| 2 | Build API backend server | Every portal page uses mock data. Zero data flows. Must build at minimum: claim CRUD, auth, client/debtor management. Recommend FastAPI (Python) reading/writing to TwentyCRM via GraphQL REST or a standalone SQLite/Postgres. | 2-3 weeks |
| 3 | Wire portal to API | Intake form, claims dashboard, client dashboard all need real data. Replace mock data with API calls. | 1-2 weeks |
| 4 | Fix internal.debtrecoveryexperts.com | Add Caddy route pointing to /var/www/internal/. Without this, the entire internal dashboard is inaccessible to the team. Also set up Cloudflare Access for email-based auth. |
2 hours |
| 5 | Stripe Connect account + integration | Can't collect a single dollar without this. Register for Stripe Connect, get API keys, build payment flow (payment link → webhook → mark claim as paid). | 1-2 weeks |
🟠 TIER 2 — OPERATIONAL (Must-have for daily operations)
| # | Task | Rationale | Effort |
|---|---|---|---|
| 6 | Automated email sending (templates 1-3) | Client onboarding emails (received, under review, LPOA enclosed) should fire automatically on claim state changes. Use germainebrown.com SMTP relay. | 3-5 days |
| 7 | DocuSeal API integration | Automate LPOA signature requests. Send signing envelope → track status → notify team. | 1 week |
| 8 | Demand letter approval pipeline | letter-queue.html has the full UI but needs: (a) letter persistence in DB, (b) approval workflow backend (Anita→Tony/Germaine), (c) actual email sending via collections@ | 1-2 weeks |
| 9 | LetterStream activation + integration | Email support@letterstream.com to activate Automation mode on the account. Then build API integration for certified mail with tracking. | 1-2 weeks (after activation) |
| 10 | Online notary account + integration | Sign up for OneNotary or Proof. Integrate RON sessions for LPOA notarization. | 1-2 weeks |
🟡 TIER 3 — AUTOMATION (Efficiency multipliers)
| # | Task | Rationale | Effort |
|---|---|---|---|
| 11 | AI Claim Analysis pipeline | Claude Opus scoring (0-100), weakness analysis, debtor research via ScrapingAnt/SearXNG. This is the DRE differentiator — "AI-powered recovery." | 2-3 weeks |
| 12 | Tier progression automation | Cron jobs that advance claims through tiers based on time elapsed. Tier 1→2 at day 7, 2→3 at day 21, etc. Triggers new letter generation. | 1 week |
| 13 | Payment disbursement logic | When Stripe webhook fires (payment received), calculate fee based on current tier, deduct costs, mark balance for client disbursement. | 3-5 days |
| 14 | Case binder generation | Auto-generate DRE Internal PDF, Client Package PDF, Evidence ZIP on case close. Use Python (reportlab/fpdf) to assemble from DB data. | 1-2 weeks |
| 15 | Audit trail implementation | Every edit to a claim tracked: field changed (old→new), who, when, why. Add claim_audit_log table, wrap all claim mutations. |
3-5 days |
| 16 | Approval reminder system | Fix dre-approval-reminder.sh to read from real DB. Send notifications to Germaine + Tony via Hermes every 60 minutes when approvals are pending. |
2-3 days |
| 17 | Fix TwentyCRM relations | Add Payment→Claim and CaseNote→Claim relations via GraphQL mutation. | 1 hour |
🟢 TIER 4 — POLISH (Post-launch)
| # | Task | Effort |
|---|---|---|
| 18 | Client portal with real auth (JWT or Cloudflare Access + tokens) | 1-2 weeks |
| 19 | Cloudflare Turnstile on intake form | 2 hours |
| 20 | Full-text search across claims (Elasticsearch or PG full-text) | 3-5 days |
| 21 | Client-facing case binder download | 2-3 days |
| 22 | Recurring debtor reporting (D&B Global Trade Exchange for B2B, consumer CRAs for personal guarantees) | 1-2 weeks |
| 23 | Analytics dashboard with real data (currently all mock) | 3-5 days |
| 24 | Mobile-responsive polish for all pages | 2-3 days |
Part 5: What's Missing from the Spec That Real Operations Would Need
1. Client onboarding contract (beyond LPOA)
The spec assumes clients sign ToS via DocuSeal and LPOA via RON, but doesn't address the full client engagement agreement: scope of services, fee schedule acceptance, dispute resolution, termination rights. This is separate from ToS — it's the per-client engagement letter.
2. Trust/escrow account management
FDCPA and state law require collected funds to be held in a trust account separate from operating funds. The spec mentions "disbursement" but nothing about trust account structure, reconciliation, or reporting requirements.
3. Debtor dispute handling workflow
FDCPA requires specific procedures when a debtor disputes a debt: cease collection, verify debt, respond within 30 days. The spec mentions this in the compliance manual but has no system workflow for it. Without this, a single disputed claim handled incorrectly = FDCPA violation.
4. Client communication preferences and consent
TCPA requires prior express consent for autodialed calls. The spec mentions manual dialing only, but there's no consent capture in the intake form, no opt-out mechanism, and no do-not-contact tracking.
5. Reporting and metrics for clients
The client dashboard spec shows tier progress but no actual reporting: recovery rate trends, average time-to-payment, fee transparency breakdown. Clients running a business need real numbers, not just "Tier 2 in progress."
6. Internal conflict checking
What happens when two clients submit claims against the same debtor? There's no conflict-of-interest detection or policy. This is a real operational risk.
7. Staff workload management
With only 3 people (Germaine, Tony, Anita), there's no capacity tracking, no claim assignment, no SLA monitoring. As volume grows beyond 5-10 claims, this becomes critical.
8. Payment plan negotiation tracking
Not every debtor pays in full. The spec assumes binary outcomes (paid/unpaid) but real collections involve payment plans, partial settlements, and structured agreements. No workflow for this.
9. Document versioning for uploaded evidence
Clients upload documents. Later they upload revised versions. The system needs to track versions, not just overwrite. Legal discovery requires original + all revisions.
10. Export/data portability for clients
When a client leaves DRE, they need their data: all uploaded documents, claim history, communications log. The case binder covers closed claims but not the full portfolio.
Part 6: Technical Architecture Recommendation
Given the existing infrastructure (TwentyCRM with GraphQL + REST, Python MCP server, IMAP poller), the recommended architecture:
┌─────────────────────────────────────────────────────────┐
│ Caddy Reverse Proxy │
│ portal.debtrecoveryexperts.com → /var/www/capabilities/ │
│ internal.debtrecoveryexperts.com → /var/www/internal/ │
│ crm.debtrecoveryexperts.com → localhost:3003 (Twenty) │
│ pay.debtrecoveryexperts.com → localhost:8001 (FastAPI) │
│ api.debtrecoveryexperts.com → localhost:8000 (FastAPI) │
└─────────────────────────────────────────────────────────┘
│
┌───────┴───────┐
│ DRE API │
│ (FastAPI) │
│ Port 8000 │
│ │
│ /api/claims │
│ /api/clients │
│ /api/letters │
│ /api/ai │
│ /api/pay │
└───────┬───────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌─────┴─────┐ ┌──────┴──────┐ ┌──────┴──────┐
│ TwentyCRM │ │ Stripe │ │ DocuSeal │
│ (GraphQL) │ │ Connect │ │ API │
│ Port 3003 │ │ │ │ Port 8090 │
└───────────┘ └─────────────┘ └─────────────┘
Key decisions:
- Build a FastAPI backend (not Node) — aligns with existing Python skills, IMAP poller, and MCP server
- Use TwentyCRM as the database via its GraphQL API — avoids managing a separate DB schema. TwentyCRM already has Debtors, Claims, CaseNotes, Payments objects. The FastAPI layer wraps TwentyCRM's GraphQL and adds business logic
- DRE MCP server expanded to intermediate between Hermes/Tony and the FastAPI — so Tony can manage claims via Hermes directly
- Stripe webhooks → FastAPI → updates TwentyCRM claim status
- Cron jobs for tier progression, email polling, approval reminders
Summary
The DRE project has an excellent specification and a polished frontend. The gap is entirely in the backend — there's no API, no database integration, no payment processing, no email automation, and no workflow automation. The portal is a beautiful brochure, not yet a functioning business system.
If you had to pick the single most impactful next step: Build the FastAPI backend with /api/claims CRUD, wire it to the intake form and dashboard, and integrate Stripe for payments. That alone bridges the "looks like a business" to "collects money" gap.