Generate a CRM that doesn't make your compliance officer cry

What you get in the generated ZIP

A CRM generation typically produces:

app/blueprints/
├── account_bp.py             # company / organisation records
├── contact_bp.py             # individual people, GDPR-classified
├── deal_bp.py                # pipeline stages with state machine
├── activity_bp.py            # call / email / meeting log
├── task_bp.py                # follow-ups
├── pipeline_bp.py            # stage configuration per workspace
└── data_export_bp.py         # GDPR Article 20 right-to-portability

app/models/
├── account.py                # name, domain, industry
├── contact.py                # email (PII direct), phone (PII direct), notes (PII risk)
├── deal.py                   # state machine: prospecting → qualified → proposal → negotiation → closed_won / closed_lost
├── activity.py               # immutable append-only log
└── consent_record.py         # GDPR Article 7 consent tracking

docs/compliance/
├── dpia.md                   # populated per entity, classified by GDPR direct/indirect/special
├── article-30-record.md      # processing register
├── data-retention-policy.md  # generated from your retention defaults
└── data-subject-rights.md    # access, rectification, erasure, portability flows

What's already wired

• PII classification: Contact.email, Contact.phone, Contact.address all marked direct PII. Contact.dob, Contact.gender, Contact.location marked indirect. Contact.notes marked "indirect PII risk — free text" with a recommendation to enable DLP scanning.
• Consent tracking: every customer-data record has a linked consent_record row with timestamp, source, scope, and revocation handler.
• Right-to-erasure: DELETE /api/contacts/{id} triggers a workflow that deletes or anonymises across Account, Deal, Activity records linked to the contact, with a 7-day grace window for accidental deletion recovery.
• Right-to-portability: GET /api/data-export/me returns a JSON bundle of every record linked to the requester, ready for the customer's GDPR DSAR response.
• Audit log: every read/write of contact PII is logged with actor, action, timestamp, and IP — required for SOC 2 §CC7.
• Pipeline state machine: deal stage transitions are guarded by from-state, logged, and reportable. The state machine is documented in a Mermaid diagram in docs/diagrams/deal-state-machine.md.

What ships in docs/compliance/dpia.md

The DPIA is populated from your entity model, not a template. Each entity gets a section listing its fields, their PII classification, the lawful basis for processing (you confirm this in the wizard), the retention period, and the technical/organisational measures applied. Auditors are reading actual data architecture, not generic policy language.

A typical DPIA is 8-12 pages depending on your entity count. It's reviewable in an hour by a compliance lead instead of being written from scratch over two days.

Internal links

• See for/legaltech and for/healthtech for compliance-heavy industries
• Stripe integration and SendGrid integration cover the wiring

CTA

Try it — free plan, no credit card. archiet.com.

Generate a CRM, open docs/compliance/dpia.md, decide if that's the shape your compliance officer would accept.