I’ve had good luck keeping multi-tenant n8n setups tidy by leaning on separate Postgres schemas per client and a shared pool of reusable sub-workflows. Makes it way easier to patch stuff later without stepping on anyone’s toes. If you ever feel things slowing down, queue mode with worker nodes has saved my bacon more than once.
Hi @JEnterprises,
I would start this with one paid validation slice, not a full-platform promise.
The slice I would propose:
- Postgres tables for tenants, states, candidates, sources, scoring decisions, approvals, and audit events
- self-hosted n8n structure with environment separation, credential boundaries, run logging, and backup notes
- one state/source monitoring workflow using synthetic or non-PHI data
- one human approval queue before anything is sent or promoted
- a handoff doc covering failure modes, rollback, and what should stay manual
For medical/compliance-adjacent work I would keep PHI out of the first build entirely. AI should draft, score, and summarize; it should not make final decisions without a human review gate.
I can do a $100 architecture/diagnostic pass on your current spec and return the concrete schema + first workflow checklist. If that is useful, the first implementation pilot can be scoped separately around $300-$500 so you are not committing to the whole system before the foundation is proven.
Hi JEnterprises,
This is the kind of build that should be treated as an operations platform, not a collection of agent demos. I like that you are separating PHI/patient data from operations/compliance data and requiring audit trails, canaries, isolation and documentation from day one.
I am Carlos Silveira, a Spain-based full-stack developer and automation consultant. Relevant overlap: self-hosted workflow automation, Node/Python, SQL/Postgres, APIs, Google Workspace/Drive workflows, dashboards/internal tools, logging, handoff documentation, and LLM steps with structured outputs and human approval before external actions.
On your questions:
-
I will not claim a public 6+ month n8n + Postgres reference I cannot share. What I can bring is production web/database experience plus a conservative design approach: Postgres as source of truth, explicit workflow state, audit/error tables, isolated automations, synthetic test data, and clear runbooks so another developer can take over.
-
To prevent context rot and agent drift, I would avoid relying on long free-form conversation memory. I would use versioned prompts, bounded context windows, source citations/URLs, structured JSON outputs, validation before writes, daily canary checks, confidence thresholds, and human approval queues for anything compliance-sensitive or outbound.
-
Rough first quote/timeline: Phase 0 foundation as a 1-2 week paid milestone, likely 2,500-4,500 EUR depending on dashboard/RLS depth. Phase 1 MVP as another 2-3 week milestone, likely 3,500-6,000 EUR depending on source count, auth complexity and scoring rules. I would start smaller if possible: a 1,500 EUR proof slice that creates the Postgres/audit/state pattern, one n8n workflow convention, one canary, and one dry-run lead-gen/compliance workflow before committing to the full Phase 0/1 scope.
-
For maintenance I prefer hybrid: fixed milestones for new builds, plus a small monthly retainer only after the first slice proves useful.
If that approach fits, I can review your developer brief and propose a clean first milestone.
Best,
Carlos Silveira
This is the kind of build where the first win is not “more agents”; it is a reliable operating spine.
For Phase 0/1 I would scope it as:
- self-hosted n8n on VPS with separate dev/prod workflows and explicit credential ownership
- Postgres schema for tenants, sources, candidates, compliance signals, approvals, runs, errors, and audit events
- row-level-security model tested before any automation touches real business records
- source adapters for the first 2-3 public lead/compliance sources, not every source at once
- human approval queue before any outreach/action
- canary runs with known fixtures so drift is caught daily
- replayable workflow runs, idempotency keys, and dead-letter/error paths
On context rot: I would avoid letting an agent carry vague memory across weeks. Store canonical facts in Postgres, retrieve only the bounded context needed for the current task, force structured outputs, validate outputs against schemas, and compare recurring canary outputs against expected fixtures. Anything risky becomes “suggest and queue for approval,” not autonomous action.
Rough Phase 0/1 shape: 2-4 weeks depending on how much of the dashboard and source scraping is included. I would start with a paid technical design/build slice: schema, deployment plan, one source adapter, one approval queue, and one digest/alert path. If that is clean, expand.
For maintenance, hybrid usually works best: fixed milestones for new phases plus a small monthly retainer for monitoring, fixes, dependency updates, and workflow drift review.
I can review the developer brief and turn it into a concrete Phase 0/1 milestone plan.