SoConnective

Product

Technical Blueprint — SoConnective · CRM

Changelog

  • 2026-06-13 — Pivot to multi-tier SaaS platform (Platform → Agencies → Sub-accounts) with an installable module marketplace and an AI onboarding concierge. Tenancy becomes hierarchical (tenant type+parent), config is per account, agencies deploy modules to sub-accounts (hybrid creds, per-module override). See ADR 0008. Supersedes the flat single-tenant assumption.
  • 2026-06-12 — created (INIT, was Spanish), then rewritten in English and reconciled with the ADRs. This document is the technical source of truth; architectural decisions live in docs/architecture/decisions/ (ADRs) and are referenced here rather than duplicated.

1. Product

SoConnective is the self-hosted, AI-native operating system for Feedback Studios (a marketing agency): a team CRM at the core, plus a client portal, native conversations, native automation, and AI agents. Philosophy: efficient manual process first → automation → AI.

  • Tenancy: multi-tenant agency → sub-accounts (clients). Isolation by tenant (Payload multi-tenant plugin + forced Postgres RLS). See ADR 0003, 0004.
  • Business model: internal use first; later a self-hosted SaaS / white-label product. No feature-gating.

2. Stack

LayerChoiceWhy
Frontend (CRM / portal / web)Next.js 16 + React 19 + Tailwind v4 + shadcn (Shadcn UI Kit)App Router, server actions, finished, branded admin template. ADR 0005
Backend / engine / API / auth / CMSPayload CMS 3 on Postgres, schemaName: 'payload'MIT, self-host, REST+GraphQL, auth, collections, hooks, multi-tenant. ADR 0004
DatabasePostgreSQL + Drizzle (packages/db) with forced RLS + app_user NOSUPERUSERSingle source of truth, tenant isolation at the DB. ADR 0003. Prod schema by migrations (ADR 0007)
AuthPayload JWT → httpOnly crm_token cookie (7d) → server-side Authorization: JWTRobust sessions; route guard in proxy.ts
AutomationNative engine (hooks → actions), no n8nFull control of the engine + identity graph. ADR 0006
ConversationsNative omnichannel (no Chatwoot)Control of the identity graph. ADR 0006
AIClaude (opus / sonnet)Agents, drafting, summarisation, "ask your CRM"
Email (transactional)TBD (Resend / Postmark / SES)Verification, reset, notifications
PaymentsStripe (Phase 6)Invoices, subscriptions, MRR
Hosting / CICoolify + Traefik + Forgejo on the Vidot VPSSelf-host, deploy on push

3. Architecture

Components, environments and the request path are described in docs/architecture/overview.md. Environments: local (support/backup only) and prod (the Vidot VPS, deployed by Coolify from Forgejo). Domains: backend. (engine) · crm. · portal.* · cms.* · docs. · website (apex). (* = later phases.)

4. Data model

erDiagram
    TENANT ||--o{ USER : memberships
    TENANT ||--o{ COMPANY : scopes
    TENANT ||--o{ CONTACT : scopes
    TENANT ||--o{ DEAL : scopes
    COMPANY ||--o{ CONTACT : has
    CONTACT ||--o{ IDENTITY : channels
    CONTACT ||--o{ DEAL : primary
    DEAL }o--|| COMPANY : derived
    DEAL }o--o{ SERVICE : serviceInterest
    CONTACT ||--o{ ACTIVITY : timeline
    DEAL ||--o{ ACTIVITY : timeline
    CONTACT ||--o{ TASK : todos
    DEAL ||--o{ TASK : todos
    CONTACT ||--o{ APPOINTMENT : meetings
    DEAL ||--o{ APPOINTMENT : meetings
    AUTOMATION ||--o{ AUTOMATIONRUN : logs

Live, tenant-scoped collections (Payload, schema payload): tenants, users, companies, contacts, identities, deals, services, activities, tasks, appointments, automations, automation-runs. Decisions: tenant on every scoped collection · deal company derived from the primary contact (read-only) · UTC in DB, local in UI · schema changes via committed migrations (ADR 0007).

5. Contracts

API (Payload REST, base PAYLOAD_URL)

MethodPathAuthNotes
POST/api/users/login→ JWT
GET/api/users/meJWTcurrent user + tenants
GET/POST/api/:collectionJWTlist / create (with tenant)
GET/PATCH/DELETE/api/:collection/:idJWTread / update / delete
GET/api/:collection?where[field][op]=…&depth=N&sort=…JWTfilters / relations

Events / hooks (Payload afterChange)

SourceEventHandlerNotes
Dealscreate / stage change / Owner changelogDealActivitywrites timeline Activity (same req transaction)
Contactslifecycle changelogContactActivitywrites timeline Activity
Dealscreated / stage_changed / wonautomateDealfires automation engine
ContactscreatedautomateContactfires engine
Tasksstatus → DoneautomateTaskfires task.completed
AppointmentscreatedautomateAppointmentfires appointment.scheduled

Background jobs (future)

Scheduled nurture/reminders, MRR checks, docs-sync (prebuild). The native automation engine currently runs synchronously inside the originating transaction; time-based triggers and queued execution are a later increment.

6. Integrations

ServicePurposeStatus
Email (Resend/Postmark)verification, reset, notificationsTBD
WhatsApp / Instagramomnichannel inboxPhase 2
Stripepayments, subscriptions, MRRPhase 6
Claude APInative AIactive
Previous
Task Map — SoConnective · CRM