Mangrove Web — Internal Reference · v2
A single source of truth clients control, with tools plugged in around it. Cloudflare is the default spine; every layer beyond the core is added only when a client needs it. The goal: architect and hand off cleanly, own the data, and swap tools without migrations — while never becoming the client's data-cleanup crew.
Ecosystem Overview
Instead of contact/CRM data living inside any one SaaS tool (Pipedrive, ClickUp, Salesforce), it lives in a database the client — or Mangrove — controls. Every tool becomes a consumer of that data, syncing in and out through defined workflows, rather than a place data originates and gets duplicated. Drop a tool, and you lose a UI — not your data.
Solves: no single source of truth
The same contact exists in three tools with three slightly different versions. The hub makes one canonical record everything else reads from.
Solves: vendor lock-in
Switching tools means redirecting a sync workflow, not a painful data migration. The flexibility story that lets tools bolt on and off.
Solves: SaaS cost / pricing risk
Per-seat pricing creep, feature paywalls, or a vendor shutting down no longer threaten the data itself. Resonates hard with mission-driven clients.
Solves: each system's ceiling
Every SaaS tool has limits you eventually hit. Owning the data layer opens a path to build new tools and connectors on the hub — extending it — instead of investing more heavily in another SaaS vendor to work around a limitation. A foundation you build forward from, not a dead end.
Three layers are core to every build. Everything else is an optional add-on, included per client need. The database itself is a choice covered in the next tab.
| Core layer | Default tool | What it does |
|---|---|---|
| Database | Cloudflare D1or Supabase |
Holds the canonical records — contacts, deals, activity. The one place data lives; everything else reads from it. Choice of D1 vs. Supabase is the key decision (see next tab). |
| Sync | n8n |
Moves data between the hub and every connected tool, on triggers or schedules. Fails loudly (Slack alert on error), never silently. |
| Interaction / Access | Claude (MCP)Slackdashboardexisting tools |
How people and AI reach the hub — usually several pathways at once, one per stakeholder or workflow. The same data can be queried by Claude over MCP (tech-forward staff), surfaced to a program lead through a Slack bot, viewed by a director in a read-only dashboard, or pulled into someone's existing tool — all against one source of truth. Surfaces are matched to who's using the data and for what; every build has at least one. Works with either database. |
| Optional layer | Tool | When to include it |
|---|---|---|
| Client interface | Chosen per engagement Web app, Sanity, Supabase, a third-party tool, or just Slack/email — not predetermined |
Whatever surface the client uses to act on their data — approve dedupe merges, fix fields, manage records. Include when the client needs to act directly; the specific tool is a per-engagement choice. (See Client Interface tab.) |
| Reporting / dashboards | Metabase optional |
A read-only dashboard for exploring data — charts, filters, exports. Add only if the client has a stated reporting need. Many clients work in their existing tools and never need this. Self-hosted = free (~$15/mo VPS). |
| Agents / automation | Vercel eveCloudflare Agents+ memory |
For judgment-call automations (dedupe detection, triage) with human approval gates. Added when workflows need reasoning, not just mechanical sync. n8n stays the execution plumbing underneath; a memory layer (Personize) is a further opt-in once several agents share client context. (See Agents & Memory tab.) |
Why this shape
The database owns the data and the definition of what a record is. Every tool is a replaceable client of it. Drop a tool and you lose an interface, not your data — which is what lets you bolt tools on and off without migrations. Core stays tiny (DB + sync + interaction/access); complexity is opt-in per client.
Database Options
The one real fork in the road. Both are valid; the choice comes down to a single question — does a human need to log in and directly manage this data, or is the database a backend hub feeding other tools?
| Cloudflare D1 — DIY / owned path | Supabase — managed / batteries-included | |
|---|---|---|
| Best for | Smaller clients, owned-infrastructure preference, data that mainly feeds other tools. Mangrove's default. | Clients who need authenticated direct access, or where speed-to-build matters more than owning every layer. |
| Auth | ~ Via Cloudflare Access (native, no build-from-scratch) or Clerk/Auth.js | ✓ Built in — logins, roles, SSO |
| Row-level security | Enforced in the app / Access layer | ✓ Native, enforced at the database |
| Admin UI | ✗ None built in — you build the interface | ✓ Table UI out of the box |
| APIs | You write Worker endpoints (more glue) | ✓ Auto-generated REST + realtime |
| Cost | Near-free — bundled in $5/mo Workers Paid | Free tier pauses inactive projects; Pro ~$25/mo per project, multiplies across clients |
| Vendor fit | ✓ Cloudflare-consistent, Chae's expertise, one vendor | Second platform, second bill, second DB philosophy |
| Layer coupling | Data stays decoupled from UI/auth — swap the interface without touching the source of truth | Data + auth + UI bundled — convenient, but changing one can mean touching the platform |
| Mangrove stance | Default Build the interface once as a reusable template, redeploy per client. Extra glue is real but amortizes. |
Fallback Reach for it when managed auth/APIs are needed fast and building the glue isn't worth it for that client. |
Decision rule
Does a human need to log in and directly manage this data? Yes → the client interface matters; build it on Cloudflare (D1 + Pages + Workers + Access) by default, or reach for Supabase if speed-to-build wins. No, it feeds other tools → D1, clean and cheap. Either way, n8n handles sync and MCP connects Claude.
Design & Security
The part that decides whether this stays a clean architecture or turns into a support burden. The design choices below exist to keep upkeep measured in hours per month — small, predictable, and visible — not staffed like an IT department.
engine9 bundles all of this into one platform — connector protection, dedupe, security, an AI query layer — as an open-source, nonprofit-focused product you can adopt whole (see Alternatives for the build-vs-adopt call). If you assemble the hub yourself instead, the same jobs are done by components Mangrove owns and version-controls, run on a light retainer. There's no single "management platform" to run because each job is bounded and assigned — that's precisely what keeps it off a full IT team. The mapping:
| The job they bundle | How the hub does it | Runs on | Ongoing burden |
|---|---|---|---|
| Protect connectors (patch when a tool's API changes) | n8n workflow templates, version-controlled in GitHub. An API change is a bounded ~30-min fix, not a maintenance contract. | n8nGitHub |
~30 min per affected connector, 1–2×/yr |
| Dedupe / identity resolution | Confidence-tiered matching — auto-merge high, flag medium to a human, surface low. Judgment calls run as an approval-gated agent. (See Client Interface.) | Agent harnessn8n |
Client approves flagged merges; Mangrove tunes the threshold in month 1 |
| Security | Scoped per-integration credentials, encryption at rest & in transit, point-in-time restore, field-level access. (See below.) | D1Cloudflare Access |
Built-in; periodic credential rotation |
| Don't-fail-silently monitoring | Every sync Slack-alerts on error; idempotent re-runs; sequential rollout so failures never compound. | n8n |
Watch the alert channel |
| Orchestration — what decides what runs | The agent harness runs judgment automations behind approval gates; n8n executes the mechanical steps. (See Agents & Memory.) | Cloudflare AgentsVercel eve |
Set up once, then hands-off |
Total staffing: a few hours a month from someone who understands the hub (Chae) + one client-side data owner (a hard requirement — see Resourcing). That's the whole model. Assembling it yourself — vs adopting engine9's pre-built bundle — trades a bit more setup for full control of the stack, schema, and connector library across every client, nonprofit or not.
The management path — why this doesn't become a fire-fighting job
Fail loudly, not silently. Every sync workflow Slack-alerts immediately on error. Silent failures are what turn into weeks of quietly-wrong data — this design refuses them.
Idempotent workflows. Running the same sync twice never duplicates or corrupts anything, so debugging is low-stress and re-runs are always safe.
Sequential rollout. Prove one integration fully before adding the next, so failures never compound across connections.
Honest trade-off: this minimizes fire-fighting but doesn't eliminate the need for someone who understands the hub. The goal isn't zero maintenance — it's maintenance that's small, predictable, and visible, instead of silent drift that becomes a crisis. Paired with the hard qualification rule (the client owns an internal data person — see Resourcing), this is what keeps Mangrove the architect, not the janitor.
The management path above keeps upkeep to a few hours a month — but it still assumes someone is on deck. If the goal is to never jump in to fix things — to pay for peace of mind instead of staffing or babysitting it — that's a legitimate, deliberate choice. You buy down the "jump in" risk by moving toward managed services that own the failure surface. It costs more monthly; that's the trade. The options, most-hands-off first:
| Pay a system to own it | What comes off your plate | The trade |
|---|---|---|
| Managed connector service on the owned hub (Fivetran / Airbyte Cloud) | The vendor owns connector upkeep and monitoring/alerting — when an API changes, it's their problem, not a 2am fix. Removes the single biggest recurring job while you still own the data in the hub. | A real monthly bill (Fivetran scales fast at volume); dedupe, security, and the interface still have a home, but the connector fire-drill is gone. |
| Managed hosting for the moving parts (n8n.cloud, managed DB) | No servers to babysit — the provider handles uptime, patching, backups. Nothing to keep alive yourself. | Modest added monthly cost vs. self-hosting; you trade a little control for not being on call for infrastructure. |
| Adopt engine9's pre-built platform | An open-source, nonprofit-focused build of this whole hub — connectors (plugins), dedupe/identity resolution, warehouse, and a Conductor AI layer in one place. The most hands-off path if the client's tools are in its plugin ecosystem (ActBlue, EveryAction, Action Network). | Platform + dedupe are free; you pay per connector (~$50–$1k/mo each) plus a support tier ($500–$5k/mo) — that support tier is the "someone owns it" you're buying. Built for the nonprofit/organizing stack specifically, so less fit for general SaaS/CRM. The honest case for engine9: when peace of mind and ecosystem fit outrank custom control. (See Alternatives.) |
| A paid managed retainer (Mangrove or a third party) | A human/team owns oversight — monitoring, fixes, credential rotation — so you genuinely never touch it. | The "pay people, just not your people" version. Priced honestly as a managed service — unpriced, it's the janitor trap for whoever absorbs it. |
The spectrum — pick your point on it deliberately
This is one dial, not a yes/no. The cheap, DIY end (D1 + self-hosted n8n) needs a hand on deck and rewards someone who likes owning the stack. The managed end (Fivetran-class connectors, managed hosting, or a bundled platform) costs more every month but buys the failure surface off your plate so you can genuinely stop thinking about it. Neither is "right" — choose the point that matches what you value. If freedom-from-fixing is the priority, spend toward managed and treat the higher bill as the price of never jumping in. (This is the same D1-vs-managed dial from the Database tab, and why Fivetran sits under "never think about pipelines" in Alternatives.)
Does Personize shore this up? No — different problem.
Personize is a memory/context layer for agents (see Agents & Memory) — it doesn't protect connectors, watch syncs, or provide security oversight, so it does nothing for the "I don't want to jump in and fix things" need. It earns its place only once multiple agents share client context. For peace-of-mind oversight, reach for the managed options above, not Personize.
| Principle | Why it's there |
|---|---|
| One writer per field | Decide, per field, which tool (or the hub itself) is allowed to originate an edit. Prevents conflicting simultaneous edits across systems. |
| Read-only mirrors over two-way sync | A tool that just displays hub data is simpler and has far less that can break. Make a sync bidirectional only when a tool genuinely needs to originate changes. |
| New contacts created in the hub first | Then pushed out to connected tools — never created independently in two places and reconciled after the fact. |
| Master ID pattern | Once a contact exists in the hub, its ID is written into a custom field in every connected tool. Future syncs match by ID, not fuzzy name/email guessing. |
| Upsert, not insert | Every sync checks "does this record already exist?" before writing, so re-running a sync is always safe (idempotent). |
| Version-controlled schema & workflows | Git — same pattern as Mangrove's existing GitHub MCP setup. Changes are reviewable and revertible, not live-edited with no history. |
| Build one integration before the next | Sequential, not parallel — each new connection doesn't multiply what can drift or fail before the pattern is validated. |
| Safeguard | Detail |
|---|---|
| Scoped credentials per integration | Each sync workflow gets its own API token, limited to what it needs — contains the blast radius if one integration is compromised. |
| Encryption at rest & in transit | Handled automatically by D1. |
| Point-in-time restore | D1 supports time-travel/restore within a window — confirm the retention window and treat it as a real backup, not an afterthought. |
| Field-level access thinking | Decide up front who/what can read sensitive fields (personal contact info, internal notes) vs. just names/status. |
Client Interface
When the system finds two records that might be the same person, or data that needs a human call, someone has to approve it. Three ways to surface that — matched to who's answering.
Most matches never reach a person. A nightly dedupe check tiers matches by confidence; only genuine ambiguity escalates to one of the surfaces below. Auto-merge threshold gets tuned after watching real flagged cases for the first month, not guessed up front.
| Confidence | Example | Action |
|---|---|---|
| High | Exact email match | ✓ Auto-merge — no human needed |
| Medium | Similar name, different email domain; same person formatted differently across two tools | ~ Flag for approval — the human-in-the-loop step |
| Low | Loose fuzzy match only | Surface for awareness, no merge suggested |
Both records stay live and usable while a merge is pending — approval never blocks anyone from using the data. Same approval-gated pattern already used in Mangrove's meeting-notes-cleanup and client-code-sync skills.
To the client, the approval app is just a simple web app: open a link, log in, see a short queue of "these two records might be the same person" — click approve, merge, or keep separate. That experience is the same no matter how it's built underneath — the client never touches infrastructure or a dashboard.
How it's built is a per-engagement choice, not decided here: a guarded web app (on Cloudflare, or on Supabase using its built-in auth + APIs), Mangrove's existing Sanity CMS, or a third-party approval tool. Pick whatever fits the client and the speed-to-build. One example — built entirely on Cloudflare, no second platform:
| Piece | Built with | Notes |
|---|---|---|
| Data | D1 | Already the source of truth — the app reads/writes here. |
| App + logic | Pages + Workers | Front-end queue + the approve/merge endpoints. This is the reusable template. |
| Auth | Cloudflare Access | Native logins / SSO — so a Cloudflare build needs no separate auth platform. (Supabase bundles this too; either works.) |
| API glue | You write it | The one place that's more hands-on than Supabase's auto-generated APIs. Built once, reused. |
Will client edits break everything? No — edits are guarded, not raw
Clients edit through a permissioned interface, never the raw database. They can only touch their own records and the fields you allow — they physically cannot change the schema, drop tables, or reach other data. Safeguards baked in: one writer per field (no edit conflicts with sync), validation before write (no malformed data), soft-deletes (nothing truly gone, always recoverable), and point-in-time restore on the database. What breaks systems is unguarded direct DB access or uncontrolled schema changes — clients get neither. Schema changes stay with Chae, version-controlled in GitHub.
Connector Library
Each connector = an n8n workflow (JSON, version-controlled in GitHub). Deploy per client by swapping credentials. This is how you replicate engine9's connector model without buying engine9.
| Tool | What it covers | Build time |
|---|---|---|
| Salesforce | Contacts, leads, opportunities, upserts | 1–2 hrs |
| HubSpot | Contacts, deals, pipeline sync | 1–2 hrs |
| Pipedrive | Contacts, deals (Mangrove uses this internally) | 1 hr |
| Mailchimp | Lists, members, tags, email events | 1–2 hrs |
| Stripe | Payments, customers, subscriptions | 1–2 hrs |
| Action Network | Petitions, signups, donations, people | 1–2 hrs |
| Airtable | Read/write to any base | 1 hr |
| D1 / Postgres | Direct read/write to the data layer — destination for all connectors | Included |
| Tool | Approach | Build time |
|---|---|---|
| ActBlue | Webhooks push real-time donation data. One-time setup, reusable template. | 3–5 hrs |
| EveryAction / VAN | Well-documented REST API. Constituent sync, canvassing, event RSVPs. | 3–5 hrs |
| Groove | REST API. Support tickets, contact history into unified record. | 2–3 hrs |
| Harvest | REST API, well-known to Mangrove. Time entries, invoices, clients. | 1–2 hrs |
| DonorBox | REST + webhooks for donations. Common nonprofit fundraising tool. | 2–3 hrs |
vs. engine9 connectors
engine9's plugins are maintained connectors into its warehouse — real value if you adopt engine9. Building the hub instead, this n8n library gives the same reuse with no per-connection fee: build a connector once, redeploy it across every client for free. An API change is a bounded ~30-min fix, not a maintenance contract. Version-control all workflow JSON in GitHub, include an API-change response clause in retainers, and deploy to a new client by swapping credentials — and it covers general CRM/payments/email tools, not only the nonprofit stack. (Full engine9 build-vs-adopt call — and the questions to ask them: Alternatives tab.)
Agents & Memory
Added only when workflows need reasoning — dedupe judgment, triage, anything a mechanical sync can't decide — always behind human approval gates. Two questions: which agent harness runs the logic, and (later) whether a shared memory layer sits underneath. n8n remains the execution plumbing regardless; the agent decides what to do, n8n does the mechanical steps.
| Vercel eve | Cloudflare Agents SDK | Stack AI | n8n | |
|---|---|---|---|---|
| What it is | File-based agent framework (skills/tools/subagents/channels) | Code-first agent runtime on Durable Objects | No-code visual agent builder, governed workflows | Workflow engine; agent layer via AI Agent node + MCP |
| Setup friendliness | Moderate — Next.js-like, still needs a dev | Lower — extend classes, wire bindings yourself | ✓ High — drag-and-drop, built for non-devs | Moderate — Canvas UI + AI-assisted, still node-based |
| Team edits w/o a dev | Partial — skills are markdown, tools are TypeScript | ✗ Weak — no plain-file convention | ✓ Strong — its core design | Moderate — Claude/MCP drafts workflows in English |
| Client self-service | ✗ Weak — not productized for hand-off | ✗ Weak — same issue | ~ Unclear — no white-label billing tier | ✗ Weak — not branded/multi-tenant alone |
| Approvals / HITL | ✓ Built-in, any action gateable | Available, newer/less mature | ✓ Built-in | ✓ Via Chat node (pause for input) |
| Durability | ✓ Strong (Workflows, checkpointed) | ✓ Strong (Durable Objects' native strength) | Workflow-run model, not the focus | Improved significantly in 2.0 |
| Slack / channel-native | ✓ Yes, first-class concept | Thinner — DIY via Events API | Not a core focus | Via nodes/webhooks, not a channel abstraction |
| Claude integration | Native, model-agnostic via AI Gateway | Native, model-agnostic | Model-agnostic, LLM-swappable | Native AI Agent node + full MCP |
| Hosting | Vercel only (prod lock-in) | Cloudflare only | Stack AI cloud, or VPC/on-prem (Ent.) | ✓ Self-host anywhere, or n8n.cloud |
| Pricing entry | Free framework; $20/mo Vercel Pro; usage beyond | $5/mo Workers Paid; usage-based | $199/mo min + run limits; custom Ent. | Free self-hosted (open source); n8n.cloud if managed |
| Cost ceiling risk | Function-duration billing can spike on long LLM streams | Predictable at small scale; DO storage billing active | Fixed monthly — but pricier floor | ✓ Lowest — just your server |
| Mangrove fit | Internal tooling Durable, audit-trailed; porting Cowork skills | Default when hub is on CF Same vendor, same infra | Team-friendly Closest to no-code, but no client resale | Plumbing layer Always present underneath |
Bottom line — which harness
Team-friendly management: Stack AI or n8n (with Claude/MCP) — non-devs can meaningfully participate without writing code. Agent layer for client hub work: Cloudflare Agents SDK is the natural fit whenever the hub is already on Cloudflare (one vendor, one bill), with Vercel eve as the alternative for durable, audit-trailed internal tooling. Client self-service: none of the four ships this out of the box — Stack AI is philosophically closest but explicitly lacks white-label billing; a dedicated resale platform or custom portal would be needed if that becomes a hard requirement. n8n is the execution plumbing under whichever reasoning layer you pick.
What it is: Governed AI memory infrastructure that sits underneath whichever harness you pick — it doesn't build or host agents. It gives every connected agent shared, policy-governed memory of clients and context, so a support agent, a CRM automation, and an internal bot all work from the same facts instead of each re-deriving or re-asking. Counters the "stateless expensive-autocomplete" failure mode where agents start cold every session.
How it integrates: MCP-compatible (same pattern as an n8n MCP setup — add a URL), installable skills for Claude Code / Cursor, native no-code hooks for HubSpot, Salesforce, Zapier.
Claimed benefits (self-reported — verify independently): up to 70% token savings via centralized policy enforcement; 74.8% accuracy on LoCoMo, described as ahead of other long-term memory systems.
Pricing: Free tier ($10 credits) · PRO $80/mo · usage $0.003 / 1K tokens memorized + $0.001 / recall · custom FastTrack for 10k+ records/yr.
When it matters for Mangrove: only once multiple agents share client context (e.g. a support-triage agent and a client-facing bot both needing the same project status/history). Not a day-one need with a single internal automation — revisit as the agent footprint grows. Opt-in memory sublayer — later phase
| Component | Assumption | Est. monthly |
|---|---|---|
| Memorization | One-time onboarding, ~300 tokens/contact, minimal ongoing updates | ~$9 (first month mostly) |
| Recall | Light usage, ~1,000–2,000 queries/month | ~$1–2 |
| PRO base | Flat fee | $80 |
| Total | Flat fee dominates — usage barely moves it at light volume | ~$85–95/mo |
The real question isn't cost
At light query volume the $80 flat PRO fee dominates — a small fraction of a typical mission-driven client's software ceiling, so affordability isn't the deciding factor. The open question is whether shared agent memory is actually needed given the client's scope and integration count. Decide once the data hub and agent footprint are defined, not upfront.
Resourcing
Less work than engine9 makes it sound — but more than a website project. The library build (connectors + the reusable approval app) is a one-time investment. Per-client work is bounded if scoped correctly.
| What | Detail | Effort |
|---|---|---|
| Connectors | Tier 1 + Tier 2 for 8–10 tools, unified schema design, error handling, GitHub docs | 40–60 hrs |
| Approval app | The reusable Cloudflare (Pages + Workers + Access over D1) dedupe/edit interface template | 25–40 hrs |
| Who | Dev-led + one contract dev for heavier API and app work | — |
| Output | Reusable assets — each redeploy costs only credential-swap + light config time | — |
| Phase | What it involves | Who | Est. hrs |
|---|---|---|---|
| Discovery | Map tools, data sources, data quality. Qualify internal data owner. | PM | 3–5 hrs |
| Schema mapping | Match client fields to unified schema (people, transactions, activities, messages) | Dev | 4–8 hrs |
| Connector deploy | Install templates, swap credentials, test each source. 2–4 hrs per connector. | Dev | 2–4 hrs ea |
| Database setup | Provision D1 (or Supabase), configure access/permissions, tables | Dev | 4–6 hrs |
| Interface deploy | Deploy approval app template, wire to client's DB, set up logins | Dev | 4–8 hrs |
| Reporting (optional) | Only if needed: connect Metabase, build initial dashboards | Dev | 4–8 hrs |
| Handoff + docs | Train client, document credential rotation, set expectations | PM | 2–4 hrs |
| Total (3–4 connectors) | Typical client with 3–4 source tools | — | ~30–55 hrs $5–10k+ at Mangrove rates |
Clean client
2–4 hrs/month
Monitor n8n error log, occasional API key rotation, connector fix 1–2×/year
Complex client (6+ sources)
8–10 hrs/month
More connectors = more failure surface. Screen for this in scoping.
No internal data owner
Don't take the client
No internal owner = Mangrove becomes the janitor.
Hard qualification rule
The client must have one internal person who owns credentials and data quality. No internal owner = don't take the engagement. This is the single biggest protection against becoming the client's unpaid data-cleanup crew. You're the architect — not the janitor.
Alternatives Considered
Everything vetted during the data-architecture research, kept on record so we don't redo it. The owned-hub model (D1/Supabase + n8n + MCP) is the synthesis of this landscape — these are the roads we didn't take, and the reasons. Verdicts reflect fit for typical Mangrove nonprofit/gov clients, not the tool's absolute quality.
What it actually is (per their own architecture spec): not a thin connector product — a 100% open-source, nonprofit/organizer-focused implementation of this exact hub pattern. A permanent data warehouse (they call it a LakeHouse) where tools plug in as plugins that don't own the data — add, swap, or drop one without touching the rest — normalized into the same unified schema this doc uses: people, transactions, activities, messaging events. Built-in identity resolution (deterministic + probabilistic), full SQL access, a plugin marketplace for the nonprofit stack (ActBlue, EveryAction, Action Network, email, events), and "Conductor" — a plain-English query/action layer that connects, like their website tool, over MCP. Data ownership is the whole pitch.
But architecture-aligned ≠ a good platform. That it markets to nonprofits and open-sources its code are go-to-market and trust facts — not proof it's mature, supported, or economical to run. Assess it on the things that actually bite: cost per connection, upkeep, security, support.
The real pricing (from their pricing page). The platform is genuinely free — the open-source data warehouse, identity resolution / dedupe, and the Conductor AI are all included at no cost. So the worry that they charge to dedupe is off: dedupe is free. What you pay for is each connector plugin, monthly, plus a support tier, plus volume-based third-party segments.
| Free — included | Paid — recurring |
|---|---|
| Data warehouse · identity resolution / dedupe · Conductor AI · segmenting · Members Only portal · e9 Events plugin · community support | Each connector plugin ~$50–$1,000/mo (some free tiers, e.g. Mailchimp) · CRM / People manager $150–$500/mo · support tiers Basic $500 → Enterprise $5,000/mo · third-party segments (volume-based) |
Their own sample totals: small org on one connector = $50/mo; a theater/venue = $775/mo; a 1M+-supporter org = $7,050/mo (including $5k Enterprise support).
So the economic question is connectors, not dedupe. Every tool you connect is a recurring monthly plugin fee, forever — whereas we build a connector once in n8n and reuse it across every client at no per-connection cost. For a single small nonprofit with one or two connectors, engine9's free platform + a ~$50 connector may be cheaper and faster than our build + retainer. For Mangrove running the pattern across many clients and many connectors, our reusable library amortizes and the recurring per-plugin + support fees don't. It's a per-client calculation, not a blanket answer — and the more-evolved specialists (Fivetran, RudderStack, dedicated harnesses) still lead on scale and flexibility if a client outgrows the bundle.
And outside engine9's stack, you're building custom anyway. The paid plugins only cover engine9's own ecosystem; connect a tool it doesn't have and it's a custom build — exactly the case where a build-your-own MCP/API approach (n8n, or a direct MCP connection) wins outright and engine9 adds nothing. Which sharpens the real question: what is the per-connector monthly fee actually buying? Not the connection itself — that's a one-time build — but ongoing reconnection when a tool's API changes. So the value hinges entirely on how often that happens and whose time it is: if an API breaks ~1–2×/year and the fix is ~30 min, paying ~$50/mo ($600/yr) per connector to outsource that is hard to justify. If connectors broke constantly, the story flips. That reconnection frequency is the number to get from them.
Open source cuts both ways. Forkable code is nice, but open source ≠ maintained, secure, or supported. Self-hosting means we patch, monitor, and secure it — i.e. we become the IT team this doc exists to avoid. A managed plan removes that, but then we're betting on engine9's own maturity, support SLA, and security posture, none of which is established.
So, realistically: build (our default) wins when we want one reusable connector library across all clients, full control of stack/schema/interface, no per-connection fees, and Cloudflare consistency. Adopt engine9 only if a specific client is deep in its plugin ecosystem and the plugin costs, support, and security actually check out — a narrow, verify-first case.
What to nail down when we talk to them next week:
Verdict: architecture aligned; platform & dedupe free, but connectors + support are recurring per-client fees — build wins as we scale across clients, adopt can win for a single small nonprofit. Confirm the open-source-vs-paid connector split.
| Option | What it is / best for | Est. cost/mo | Verdict | Why we landed here |
|---|---|---|---|---|
| Supabase + n8n + Metabase | Managed Postgres + workflow sync + dashboards. Nonprofits/gov with multiple data sources. | ~$75–200 | Basis | The direct ancestor of the owned-hub model. Fewest moving parts, built-in failure alerting. We kept the n8n + managed-DB spine and made the database a D1-vs-Supabase choice. |
| Supabase + Airbyte Cloud + Metabase | Multiple SaaS sources needing maintained connectors without DIY work. 400+ managed connectors. | ~$75–200 | Runner-up | Cleaner than n8n for pure data sync — Airbyte owns connector upkeep. Lost to n8n because n8n doubles as our general automation layer and the connector library gives us the same reuse without a second platform. |
| Supabase + RudderStack + Metabase | High-volume, multi-source constituent data needing real identity resolution. | ~$300–600 | Good — situational | Right when identity resolution is genuinely needed (messy multi-source data). Overkill and pricey otherwise; event-based pricing scales fast. Reach for it only when the dedupe problem is real. |
| Fivetran + Supabase + Metabase | Enterprise clients wanting zero-maintenance, guaranteed connector reliability. 700+ managed connectors. | ~$500–2000+ | Situational | Highest connector reliability in the category, but MAR-based pricing is unpredictable and scales fast, SaaS-only (not self-hostable), and no custom-connector flexibility — you're on their roadmap. Right only for well-funded clients who never want to think about pipelines. Overkill for most Mangrove clients. |
| Attio | Modern CRM-as-data-layer. Pipeline + contact consolidation, best-in-class UI. | ~$100–300 | Situational | Genuinely great UX for pipeline/contact work, native maintained connectors. But it's a CRM, not a warehouse, and SaaS-only with no MCP yet. Pair with the hub if broader consolidation is needed; not a source-of-truth on its own. |
| PostHog + Supabase | Behavioral analytics + CDP in one. Mission-driven SaaS where product data is the priority. | ~$0–150 | Situational | Best when behavioral/product data is the priority — generous free tier, SDK-based ingestion means fewer connections to break. Weak for donor/CRM consolidation, which is most of our clients. Wrong default, right for a specific client type. |
| Supabase + n8n + Retool | Clients who need custom internal tools, not just dashboards. | ~$400–700 | Situational | Powerful for bespoke internal apps, but Retool apps break when the schema changes — that pulls Mangrove back in to fix them. Creates ongoing dependency, not a clean handoff. Only if the client has internal dev to own the Retool layer. |
| Airtable (standalone) | Small nonprofits, very non-technical teams, simple data needs. | ~$200–400 | Pass | Looks simple, becomes a mess. Zapier/Make automations break silently with no native monitoring — failures invisible until the client calls you to debug. That's exactly the babysitting loop we avoid. (Still a fine Tier 1 connector into the hub — just not the hub itself.) |
| Meltano + Supabase + Metabase | Engineering-led clients treating pipelines as version-controlled software. 300+ Singer taps. | ~$30–100 | Pass | Great for DataOps-mature engineering teams — cheap, open-source, code-first. But CLI-first with no native monitoring UI and community-maintained taps of varying reliability = highest engineering overhead of any option. Wrong fit for typical nonprofit/gov clients. |
| engine9 | Nonprofit/organizer orgs in its plugin ecosystem (ActBlue, EveryAction, Action Network). (See featured breakdown above.) | Platform free; connectors ~$50–1k/mo ea; support $500–5k/mo | Build vs adopt | Open-source, nonprofit-focused pre-build of this exact pattern — warehouse + plugins-don't-own-data + people/transactions/activities/messages schema + identity resolution + MCP. Genuinely aligned; the call is adopt-theirs vs build-our-own, driven by ecosystem fit and control. |
The through-line
The clear "passes" each fail the same test in a different way: a silent-failure babysitting loop (Airtable/Zapier), engineering overhead the client won't own (Meltano, Retool), or renting a managed moat (Fivetran). engine9 is the exception — not a pass but a genuine build-vs-adopt fork, since it's an open-source build of this same pattern. The owned-hub model keeps the parts that survived — managed DB, n8n sync, MCP — and makes everything else opt-in. Identity resolution (RudderStack), a CRM front (Attio), behavioral analytics (PostHog), and managed connectors (Airbyte/Fivetran) all stay available as bolt-ons when a specific client genuinely needs them.
Client Specifics
Two active opportunities the owned-hub model maps directly onto. This is applied context — the reference tabs are the general pattern; this is how it lands for specific clients.
The "before": patched SaaS stack wired via Zapier/Make, no single source of truth — the exact picture this architecture solves.
Why it's a direct fit, not a new direction: Cloudflare is already the leading data-hub candidate (Chae's expertise, cost, security focus). Stated client need — "move data without duplication" — is precisely hub-and-sync. Replatforming off Squarespace is the prerequisite for meaningful dev work.
Client-confirmed scope priorities: (1) CRM / data management, (2) Map + Join Now UX, (3) social-posting simplification.
How the layers map: D1 hub · n8n replaces the Zapier/Make patchwork as the sync layer · Cloudflare Agents SDK the natural agent layer (same vendor/infra) · Personize only later, once the hub feeds multiple agents needing consistent member context.
Budget: ceiling ~$2,000–2,500/mo ongoing software, itemized costs expected. D1 + n8n are minor against that; Personize (~$85–95/mo at ~10k contacts) is affordable — so cost isn't the deciding factor on memory, need is.
engine9 for RH: RH is squarely engine9's target org, so it's the strongest external alternative to weigh — an open-source pre-build of this same pattern (see Alternatives). We lean build-our-own on vendor consistency (Cloudflare, Chae's expertise) and full control across RH's non-nonprofit tools too, but this is a genuine build-vs-adopt call, not a dismissal. First real client application
The ambiguity: the RFP references an undefined "digital asset management" system and an undefined "healthy pro two-way API" — both flagged unresolved in the proposal.
The real need (from discovery): recipes + lead-gen forms + landing pages talking to Salesforce — not two websites talking to each other. That's a hub-and-sync problem, not a website-consolidation one.
Why the hub decouples the hard question: whether the two sites (chefann.org + the lunchbox subdomain) stay separate or consolidate, a shared data hub means the CRM/DAM question is independent of the site-architecture question — sites can be redesigned separately while the data underneath stays unified.
Commercial structure: because the systems work is undefined, a not-to-exceed budget (~$200K) fits better than a flat fee — the architecture pattern gives a credible way to scope the discovery phase instead of guessing a fixed price for a black box.
Raised on the CAF call (Aug 13): owning the data layer opens a path to build future tools and connectors on the hub without investing more heavily into any one SaaS system — it addresses each system's limitations over time, not just today's integration. The hub is the foundation the rest can be built forward from.
Question raised with Danielle: "What does the DAM actually need to do, and could recipes / leads / forms all sync through one data layer regardless of how the sites are structured?" Discovery-phase conversation — not build-now
Sequencing across both
1. Prove it internally first — Mangrove's own ClickUp ↔ D1 sync, including the dedupe/approval flow, before pitching externally. 2. Use that build as the live demo for both conversations — "here's what swapping a tool actually looks like" beats a theoretical diagram. 3. RH is the first real application — Cloudflare direction set, budget supports it, need is explicit and current. 4. CAF is discovery-phase — the architecture gives a credible way to scope the undefined systems work before committing to specifics.