HALO full-SaaS and modular-system sourcing

Status: complete · research snapshot 2026-08-29 Scope: complete products, modular operating systems, and exceptional commercial references. Boundary: sourcing/adoption report only. It does not modify repo/, live services, Convex data, or any other research file.

Executive decision

HALO should not be replaced wholesale by a generic CRM. Its differentiating core is the creator-agency operating loop: creator onboarding → Drive/content taxonomy → chatter/team execution → attribution/referral liability → invoicing/remittance, plus agency-specific gamification and customs workflows. The current app already contains roughly 56 tables and 80k LOC, but its identity, authorization, credential handling, audit, and money-truth boundaries are unsafe; those are release gates, not reasons to buy an unrelated second operating system.

Recommended architecture: a HALO-owned shell and domain core, with bounded sidecars:

1. ERPNext/Frappe as the finance/HR reference or isolated back-office sidecar, not the user-facing HALO shell. It is the only evaluated OSS system with credible accounting, CRM, projects, HR, payroll, and attendance breadth in one product.
2. Buzz as the selected collaboration, workflow, and agent layer, linked from HALO by creator, shift, campaign, and issue identifiers. Buzz is a fixed client choice; Zulip, Mattermost, and Rocket.Chat remain comparison benchmarks and fallback options only.
3. Twenty as the relationship/data-model donor. Study or pilot it for creator/contact/timeline patterns and workflow ergonomics. AGPL plus enterprise-marked files and a separate datastore make it a poor embedded drop-in for Convex.
4. AFFiNE as the knowledge/brief/SOP donor or optional sidecar, explicitly correcting the prior hunt’s category error. It is not a finance or creator-lifecycle system.

The remembered “AI-first Salesforce-like” product is most plausibly Salesforce with Agentforce if the memory was of an enterprise-grade platform with AI agents, unified CRM data, actions, workflows, and a trust layer. Attio is the strongest alternate if the memory was of a newer, lighter, AI-native CRM with a flexible data model and developer platform. Twenty is the strongest open-source visual resemblance, but its positioning is extensible open-source CRM rather than the likely remembered commercial AI product. Evidence is insufficient to identify the memory with certainty.

HALO operating map used for evaluation

The eight journeys from the brief remain the acceptance lens: owner command centre; creator lifecycle; content operations; team operations; money/trust; communication/relationship memory; governance/safety; and automation/intelligence.

Ranked system matrix

Scores are fit judgments: 5 is unusually strong for the stated HALO job, 1 is mostly conflict or absence. “Decision” is the recommended shape, not a claim that the product is turnkey for adult creator agencies.

Candidate evaluations

ERPNext/Frappe — strongest whole-product donor

ERPNext is the only candidate that plausibly supplies a meaningful slice of the “back office between Salesforce and Discord” in one coherent product. First-party documentation lists accounting, HR (leave, attendance, expenses, salary/payroll, recruitment and performance), CRM and projects. The product page describes full accounting, employee lifecycle, project tasks/timesheets, CRM and customisation. That maps to owner, manager and staff jobs more directly than a CRM-only product.

The boundary is the datastore and semantic model. ERPNext could become the authority for money, employees and attendance; HALO would remain the authority for creators, Drive taxonomy, content provenance, voice workflows and gamification. This is viable only with explicit IDs, event contracts and reconciliation. It is not a React/Convex package. GPLv3 and Frappe’s trademark policy require legal review for branding, modifications and any hosted-service plan.

Migration shape: begin with a read-only finance/HR pilot using synthetic or exported data; reconcile one invoice, payout, attendance period and dispute before deciding whether ERPNext owns any ledger. Do not migrate creator money while HALO’s contradictory commission semantics remain unresolved.

Buzz — fixed collaboration, workflow, and agent plane

Buzz is the client-selected collaboration system, not a candidate competing with the other chat products. Its first-party README describes a self-hostable workspace in which humans and agents share rooms, with channels, threads, DMs, canvases, media comments, search, audit events, YAML workflows, and agent keys. The documented source tree also includes a Rust relay, a Tauri/React desktop client, a JSON-in/JSON-out buzz-cli, and a production Compose path using Postgres, Redis, object storage, and optional TLS. That is the right product class for chatter shifts and manager handoffs, but it is still a separate event-log/keypair system rather than a HALO records or money system. README ↗ · architecture ↗ · workflow CLI ↗

Adoption shape: run Buzz independently and put a HALO-owned adapter between the two systems. HALO provisions users, memberships, and typed resource links only after server-side policy checks; Buzz owns communication history, workflow runs, and agent participation. Start with staff/chatters, synthetic data, read-only agents, and notification-only events. Keep contracts, consent, credentials, creator records, content provenance, attribution, payouts, and fine-grained authorization in HALO. The root source licence is Apache-2.0, but the permissive licence does not remove the operational obligations of key recovery, community isolation, upgrade, backup, and outage testing. licence ↗

The integration gates remain material: Redis-backed rate limiting is implemented but still needs configured load proof; workflow approvals cannot resume; send_dm and set_channel_topic are stubbed; NIP-FI is draft/optional; and Buzz's role model is too coarse for HALO's creator/chatter/manager/finance boundaries. These block unrestricted production autonomy, not a contained read-only or notification pilot. The full source-of-truth split, identity/channel provisioning, typed links, event sync, agent boundary, and sidecar-versus-merge decision are recorded in the fixed-anchor appendix below.

Zulip — collaboration benchmark and fallback

Zulip remains a strong benchmark for Buzz because its topics make a creator, shift, campaign or incident a durable thread; topic search and resolved topics turn chatter into retrievable work history. Official pages document self-hosted plans, topic threading, message-history search, bots, custom webhooks, REST API and integrations. It is not the selected HALO collaboration layer: Buzz owns that role per the fixed-anchor appendix.

The stream/topic model is useful comparative prior art for Buzz channel design. If Buzz cannot meet production gates, Zulip is the preferred fallback pilot; it should still not mutate money, creator permissions or Drive directly.

Twenty — CRM donor, not foundation

Twenty’s official capability description covers custom objects/fields, views/pipelines, workflows, AI, dashboards, permissions, notes/tasks, migration, API and webhooks. It is credible for creator profiles, referral relationships, manager tasks and communication timelines. It is also a plausible answer to the “Salesforce-like but modern” memory if the remembered product was open source.

It remains a separate CRM with its own auth, database, permissions and workflow runtime. Its licence says most code is AGPLv3 with an application exception, enterprise-marked files are commercial and named packages can be MIT. Do not assume “open source” means safe to transplant into HALO.

AFFiNE — explicit missed category

AFFiNE was missed because the prior hunt searched HALO screen labels rather than operator work. The owner command centre needs meeting notes, decisions, searchable memory, briefs, SOPs, handoffs and linked context. AFFiNE is valuable as a knowledge/notes reference or sidecar for managers and staff.

It should not own creator money, contracts, credentials or authorization. Its licence is mixed: most content outside specified backend/common-native areas is MIT, the backend has a separate license source, and third parties retain original licences. The safe default is product/pattern study or isolated deployment.

Salesforce Agentforce — strongest AI match

Salesforce’s first-party Agentforce material describes agents using CRM/external data, performing actions, combining deterministic workflows with LLM reasoning, and operating with guardrails. Agent API exposes goal-oriented agents through REST; the platform describes Agent Builder, Prompt Builder, Flow, Apex, MuleSoft connectors and a trust layer using existing permissions/sharing models. Those are exactly the features someone might remember as “Salesforce-like, but AI-first.”

The fit is reference architecture or paid integration, not adoption. If trialed, use one narrow workflow—owner briefing or creator-onboarding triage—with read-only HALO data and human approval before writes.

Attio — strongest lighter commercial alternate

Attio’s developer-platform announcement calls it an AI-native CRM with REST API, App SDK and no/low-code connectivity, designed for durable GTM systems. Its flexible records and webhook surface make it compelling for creator discovery, partner referrals and manager follow-up.

The missing pieces are payroll, creator statements, content provenance, Drive taxonomy, credential governance and chatter operations. It is cloud/proprietary and cannot be HALO’s self-hosted trust boundary. Require export and deletion tests before committing relationship data.

Modular and chat alternatives

NocoBase is attractive for rapidly composing tables, forms, permissions and workflows, but its license agreement and commercial-plugin boundary mean it is not unqualified OSS. Buzz is the selected collaboration layer. Rocket.Chat is a fallback benchmark where richer realtime chat, media, federation or air-gapped deployment wins; Mattermost is secure-chat prior art, but its source/compiled/admin licensing split prevents casual reuse. Plane is useful if campaign/content execution needs a mature project surface, but it is a separate AGPL application, not a CRM or operating system.

What the prior hunt missed and why

The prior hunt was feature-first: auth, RBAC, e-sign, invoicing, payroll, vault, admin, files, analytics and messaging. That found commodity replacements and critical security debt, but treated existing screen names as the search space. It therefore missed:

• AFFiNE: notes, briefs, SOPs, cross-linked records and decisions are operator jobs, not CRM features.
• Buzz (fixed anchor): collaboration is not merely messaging; channels, workflow runs, agents, entity links and approvals create the selected work-memory plane for shifts and handoffs. Zulip remains benchmark prior art.
• ERPNext/Frappe: finance + HR + projects + CRM is a whole back-office category, not a payroll library.
• Twenty/Attio: relationship operating systems are broader than contact CRUD when custom objects, timelines, workflows and APIs are evaluated together.
• Agentforce: an AI CRM can be an action/governance/data platform, not just a chatbot bolted onto a CRM.
• Compositions: a feature-repo list cannot show which systems coexist behind one identity/navigation layer or create an irreconcilable second OS.

The correction is to search by operator journey, then classify each candidate as foundation, sidecar, pattern donor or rejection based on datastore, auth, permissions, licence, UX and migration shape.

OnlyFans/creator-agency innovation hunt

This is the domain-specific pass the generic system search could not provide. The exact GitHub query OnlyFans CRM returned mostly 0–1-star prototypes, an archived Chatterly extension, and a comparison dataset—not a maintained open-source agency operating system. The useful signal is in adjacent products that model the real loop: fan conversation → chatter assignment → AI assist/human handoff → content or PPV action → attribution/ROI → creator and team performance.

Strongest GitHub donors

First-party OnlyFans benchmarks

The commercial fan-layer products reveal what a specialist agency actually values, even though they are not replacements for HALO and do not replace Buzz. Supercreator ↗ explicitly combines AI chatting, fan CRM/smart inbox, secure team access, chatter and creator analytics, automation, and agency-scale human/AI handoff. CreatorHero ↗ combines chat, PPV visibility, fan-spend insight, chatter performance, automation and centralized creator management. Infloww ↗ positions itself as an operating system across OnlyFans, Fansly, MYM and Fanvue with multi-creator inboxes, AI, scripts and fan insights. OnlyMonster ↗ highlights audience analytics, automated messaging workflows, role-based access and data portability.

These products suggest a sharper HALO opportunity than “add a CRM”: make every fan interaction an owned, permissioned work item that can be resumed by a chatter, summarized by AI, reviewed by a manager, linked to the creator/content context, and reconciled to an attribution ledger. Buzz should carry the team conversation and workflow/agent session; HALO should own the creator, fan-reference, content, consent, attribution and payout records. Any platform connector must be compliant, rate-limited, revocable and exportable; the innovation target is operational continuity and evidence, not bypassing platform controls.

High-leverage game-changing primitives

• Conversation-to-record promotion: a chatter or agent can promote a meaningful fan promise, objection, purchase intent, custom request or escalation into a HALO record with source message, creator, fan reference, timestamp, owner and next action.
• Human-resumable AI: AI drafts, summarizes and classifies; a named chatter owns the next step; managers can inspect the evidence and approve sensitive sends. Buzz’s agent session is not allowed to become an un-audited money or consent mutation.
• Per-creator playbooks: scripts, tone, pricing boundaries, restricted words, upsell rules and escalation policies are versioned by creator/account, with a visible effective version and manager approval.
• Revenue truth across the loop: connect message/PPV/custom-sale references to creator, chatter, campaign and referral identities, then post approved events into an append-only liability ledger rather than treating chat analytics as payout truth.
• Chatter operating intelligence: measure response latency, handoff quality, conversion, retention, policy exceptions and coaching outcomes—not just keystrokes or gross sales. Use the metrics to train and coach, not to silently automate sensitive decisions.
• Portable creator continuity: preserve creator-owned content, consent, contracts, account references, playbooks, decisions and payout history so a platform outage, agency departure or account transition does not erase the operating record.
• Safety control plane: credential isolation, least privilege, action audit, retention/deletion policy, export, backup/restore and platform-policy checks should be first-class product features. A fast inbox without these is a liability multiplier.

Chatter training, QA, and gamification

This needs to be a first-class HALO domain, not an afterthought. Second Nature ↗ is a useful commercial benchmark for the loop: managers design realistic scenarios, chatters practice against adaptive AI personas, the system scores the session, managers certify readiness, and analytics show skill gaps. MaestroQA ↗ is the benchmark for the second loop: analyze real conversations against configurable rubrics, calibrate reviewers, create coaching actions, and measure whether performance improves. These are not OnlyFans products, but their workflow is directly transferable to chatter onboarding, objection handling, upsell boundaries, restricted-word safety, tone, escalation and creator-specific playbooks.

The open-source hunt found no mature, OnlyFans-specific chatter-training suite. Questify ↗ is a small generic quest/progression system with XP, levels, achievements, streaks and admin/progression services; it is useful as mechanics prior art but not a replacement for HALO’s existing gamification domain. The practical design is: Buzz hosts or links the training conversation; HALO owns scenario versions, rubric definitions, completion/certification, coaching records, XP/reward ledger and manager overrides; training results can influence queue eligibility or coaching—not silently change pay. Keep XP and rewards append-only and separate from payout truth so gamification cannot become a shadow compensation system.

The compelling product loop is practice → score → coaching task → re-practice → live QA → measured outcome. A chatter should be able to rehearse a real creator’s approved tone and boundaries without touching a live fan, then receive a next drill. Managers should see evidence and calibration, while the creator’s playbook owner controls what is current. This is a stronger differentiator than another inbox because it compounds agency quality as the roster and chatter team grow.

Exact-match search reject signal

The exact-onlyfans repositories are useful as vocabulary, not as foundations: AirChatter ↗ is archived and only a Chrome assistant; of-crm ↗ describes admin/supervisor/chatter roles, clocking, sales, shifts and reports but has no declared licence and a placeholder middleware note; velvet-desktop ↗ is an unlicensed, empty/low-signal repository; and onlyfans-crm-comparison ↗ is a CC-BY comparison dataset, not an operating system. This is a confirmed market gap, not a reason to lower the quality bar.

Plausible coherent compositions

A — HALO core + Buzz + ERPNext (recommended target)

HALO remains shell, identity authority, creator/content/gamification domain and integration coordinator. Buzz handles collaboration, shifts, handoffs, workflows and agent sessions. ERPNext handles a bounded finance/HR pilot, eventually owning accounting/attendance only if reconciliation proves safe. HALO IDs are stable external IDs; Buzz receives links/events; ERPNext receives approved ledger/employee events. One-way writes are preferred initially.

B — HALO core + Buzz + AFFiNE

Use when the immediate bottleneck is manager execution, SOP drift, meeting follow-up and memory rather than finance replacement. AFFiNE stores notes/briefs with HALO links; Buzz stores live discussion, workflows and agent sessions; HALO remains authoritative for creators, permissions, content status and money. This is lowest migration risk but does not solve payroll or accounting.

C — HALO core + Buzz + Twenty

Use Twenty as a relationship pilot for discovery, creator/referral timelines and manager follow-up while Buzz remains the collaboration/workflow plane and HALO keeps bespoke creator workflows. Require tests for exportability, permission parity, API behavior and deletion propagation. Twenty must not become authority for creator identity, contracts or payouts by accident.

D — HALO core + Buzz + Salesforce/Agentforce or Attio (buy/reference)

Connect one read-only HALO dataset to a Buzz-routed Agentforce or Attio workflow. Agentforce is enterprise-grade for agent actions, policy and governed CRM context; Attio is the lighter relationship-OS option. Neither receives credentials or unrestricted money/Drive mutation authority.

AI Salesforce-like identification ledger

Conclusion: report the memory unresolved. Enterprise named agent builder/trusted CRM context → test Agentforce first. Clean modern flexible startup CRM → test Attio. Self-hosted/open source → test Twenty.

Reject ledger

GitHub verification record

Every repository cited here was freshly checked with gh api repos/OWNER/NAME on 2026-08-29, including the fixed Buzz anchor and the creator/OnlyFans-specific additions below.

NOASSERTION source inspection

• Twenty: root LICENSE says most code is AGPLv3 with an application exception; enterprise-marked files are commercial; named SDK/UI/app packages can be MIT.
• AFFiNE: root LICENSE says most content is MIT, but packages/backend and packages/common/native use packages/backend/server/LICENSE; third-party components retain original licences.
• NocoBase: root LICENSE.txt is a NocoBase License Agreement dated 2026-02-24, with community/commercial/plugin terms; it is not treated as a permissive SPDX licence.
• Mattermost: root LICENSE.txt distinguishes MIT compiled versions, AGPLv3 or commercial source licensing, and Apache-2.0 admin/config areas; it is not treated as a simple MIT source repository.
• Rocket.Chat: root LICENSE says content outside apps/meteor/ee and ee is MIT, while those enterprise paths have a separate licence and third parties retain their licences.
• ofmtools/onlyfans-crm-comparison: root LICENSE is CC BY 4.0 for the comparison dataset, not software reuse.
• keydbeats1/of-crm: no licence file is present; the README describes the prototype but grants no reuse terms.
• EddyRoig-1/velvet-desktop: no README or licence file was available at the checked repository root; it is not recommended for reuse.
• AirChatter: root LICENSE is MIT, but the repository is archived and the project is only a Chatterly Chrome assistant.
• Questify: root LICENSE is AGPLv3; it is considered mechanics prior art only, not a direct HALO code-reuse recommendation.
• Buzz: root LICENSE is the Apache License 2.0; the README documents the self-hosted relay/workspace and production Compose path. Apache-2.0 permits independent deployment or reuse subject to its notice/ licence terms, but does not make Buzz's event-log, key, role, or workflow boundaries equivalent to HALO's.

These inspections are why the report recommends study, buy or isolated sidecar decisions rather than copying code into HALO. No repository is recommended for direct reuse solely because GitHub returned NOASSERTION.

Adoption gates

Before any sidecar receives production data, require shared identity with server-side authorization; stable HALO external IDs; export/delete/retention tests; per-persona visibility tests; audit events for money, contracts, credentials and permission changes; backup/restore drill; rate-limit and failure behavior; and a kill switch that leaves HALO usable if the sidecar is unavailable. No candidate removes the immediate need to contain HALO’s public Convex endpoints and plaintext credential risk identified in the domain map and thesis.

Fixed-anchor appendix — HALO beside Buzz

Buzz is a fixed client choice, not another candidate in this ranking. The recommended shape is Buzz as the communication/workflow/agent sidecar beside the HALO domain core, with no code merge at this stage. HALO remains the system of record for creator identity and lifecycle, contracts and consent, Drive/content provenance, creator/referral money, payroll/attendance truth, credentials, compliance evidence, and fine-grained authorization. Buzz is the system of record for tenants/workspaces, channels, memberships, messages, channel history, workflow runs, agent conversations, and Buzz-native resource/entity links. A Zulip deployment is therefore no longer the default requirement in the Buzz composition; Buzz owns the selected chatter surface.

Boundary and provisioning

• Identity: keep one upstream identity authority and issue a stable haloUserId/external subject to Buzz. Provision or deactivate the Buzz user and tenant membership through an idempotent adapter. Do not treat Buzz’s coarse role model as HALO authorization; every domain action re-checks the HALO actor, tenant, resource ownership and policy server-side.
• Channels: HALO provisions channels from workflow events, using deterministic keys such as tenant/{tenantId}/creator/{creatorId}, shift/{shiftId}, campaign/{campaignId}, and finance-exceptions. Buzz owns channel membership and message delivery; HALO decides which personas may be invited and supplies the authoritative entity IDs.
• Links: messages, workflow inputs and agent context should carry typed links such as halo://creator/{id}, halo://campaign/{id}, halo://invoice/{id}, plus a human-facing HALO URL. Buzz may index/display the link, but must not copy mutable money, credential or consent records as authoritative data.

Event and webhook sync

Use an outbox/inbox adapter, not bidirectional ad-hoc writes. HALO emits versioned, idempotent events such as creator.onboarded, shift.started, content.brief.created, invoice.exceptioned, and contract.expiring; the adapter creates/updates the corresponding Buzz channel or notification. Buzz emits message.created, workflow.completed, agent.escalated, and channel-membership events; HALO stores only the relevant reference, audit event, or approved domain command. Every event needs tenant ID, stable event ID, schema version, actor/service identity, occurred-at time, and retry/dead-letter handling. A Buzz outage must queue notifications without blocking money, contract, Drive, or onboarding truth.

Agents and approvals

Buzz should host the conversational agent/session and route work; HALO should expose narrow, authenticated tools for lookup or proposed actions. Agents may summarize a creator thread, draft a follow-up, classify an exception, or propose a task. They may not directly mutate payouts, credentials, contracts, permissions, or Drive. Human approval and an auditable HALO command are required for consequential writes. Do not make NIP-FI a production dependency: it is draft/optional, so the first integration should use the stable Buzz SDK/API and explicit adapter contracts.

Blockers and decision

The integration is blocked for unrestricted production autonomy until the verified caveats are closed: Redis-backed rate limiting needs configured load proof; workflow approvals cannot resume; send_dm and set_channel_topic are stubbed; NIP-FI is draft/optional; and the role model is coarse for creator-versus-chatter-versus-manager boundaries. These do not block a read-only or notification-only pilot, provided HALO authorization remains authoritative and the adapter has rate limits, retries, audit logging, and a kill switch.

Recommendation: sidecar, not code merge. Keep Buzz independently deployable and integrate through a small HALO-owned adapter with versioned events and scoped tools. A code merge would couple Buzz’s draft/optional surfaces and coarse roles to HALO’s already fragile trust boundary, while removing the ability to disable Buzz without taking down the domain system. Revisit a merge only after production approvals/resume, configured rate-limit load proof, action stubs, and persona-level authorization have been proven in a bounded pilot.