Answering your four directly, including the one where the answer is no.
1. Six-plus months unattended, with something verifiable. No on both halves, and I’d rather be precise than close.
My production instance is SQLite-backed, not Postgres, and it has been live since 2026-03-16 — just under five months, not six. It’s 161 workflows, 25 active, running roughly 440 executions a day. Over the retained execution window there are zero gap days, and that includes a host reboot and a version upgrade to 2.19.2, neither of which required intervention. The oldest continuously-executing workflow dates to early March and ran this morning.
The honest limits on that claim: it’s my own infrastructure, so there’s no client link, repo, or third-party reference to point you at. And I can only prove 14 days of continuous execution directly, because execution pruning defaults to a 14-day retention window and I never overrode it. Longer proof windows are a config change, not a rebuild — but I’m not going to describe evidence I don’t currently hold.
So if a verifiable multi-year Postgres reference is a hard gate, I’m not your candidate, and you should know that from this post rather than from week three. If what you actually want is someone who has kept a real automation platform alive unattended and can reason about why it stays alive, that part I can speak to directly.
Worth adding, since it’s relevant to your Phase 0 choice: at 541 MB with a 94 MB WAL, my instance is right at the size where the community starts recommending Postgres over SQLite. I’m at that threshold rather than past it, which is exactly why I’d argue Postgres is correct for you from day one — multi-tenant with RLS is not something you retrofit onto SQLite, and you’d be crossing that line inside the first year anyway.
2. Context rot and agent drift. You prevent it by not letting agents carry state at all. Every agent run should be stateless and reconstruct its context from Postgres at invocation — the row is the truth, the agent is a pure function over it. The moment an agent accumulates its own running history, drift stops being preventable and becomes something you notice late, usually via a bad output someone happened to read.
Three things that follow from that:
- pgvector is retrieval, not memory. Fuzzy recall is fine for “find me similar prior collaborations,” and wrong for anything where being approximately right is being wrong — state-specific rules, contract terms, whether a collaboration is active. Those are relational columns with constraints, never embeddings.
- Every prompt, model, and output gets logged to a table with the input row id. Drift you can’t measure is drift you can only argue about. This also means when a model version changes under you on OpenRouter, you can diff before and after rather than guess.
- Regression fixtures. A small set of known inputs with known-correct outputs, run on a schedule. When a scoring agent quietly starts rating everything a 7, the fixture catches it that week rather than after a quarter of bad candidates.
Your human-in-the-loop approval step is the right instinct, but treat it as a data source, not just a gate — every rejection is a labeled example telling you where the agent is wrong.
3. Rough quote and timeline.
Phase 0: $5,000 to $6,500 fixed, roughly 3 to 4 weeks. That covers the Hetzner VPS and self-hosted n8n deployment, Postgres schema and multi-tenancy with RLS, the Drive document index, OpenRouter and Browserbase wired in, the dashboard, and backups tested by actually restoring rather than by existing.
Phase 1: $3,000 to $4,000, 2 to 3 weeks, assuming the sources are genuinely public and scrapeable — if any of them need authenticated sessions or turn out to be hostile to automation, that changes and I’d tell you before it changed the price rather than after.
Both are ranges because I haven’t seen your developer brief. Hourly rate outside fixed scope is $75/hr USD. If you’d rather not hand a multi-week phase to someone you’ve just met, I’d suggest a paid architecture week first: $500 for the Phase 0 schema, tenancy model, and deployment plan delivered as a written document. You keep it either way, and it works as a hiring test that produces something useful instead of a take-home that doesn’t.
4. Retainer vs per-engagement. Hybrid, and I’ll say plainly that I don’t have a long-term client history to generalize from, so this is what I think is right rather than what has worked for me before. Fixed price for each phase, because a phase has a defined end and you should be able to see what you’re buying. Then a monthly retainer for operations once anything is live — the retainer covers monitoring, incident response, and dependency drift, because a system that runs for years does not run unattended for years, and pricing that as ad-hoc per-incident work creates a bad incentive where I only get paid when your platform breaks.
One flag on your Phase 0 spec. Row-level security is the right call, and it’s also the piece most likely to be quietly wrong. RLS enforces against the current database role, and n8n connects to Postgres as a single static user for every workflow. Turning RLS on in that arrangement gets you the appearance of tenant isolation with none of the substance — unless the tenant is set per transaction, with the connection running as a non-superuser, non-BYPASSRLS role, and the policy reading from that. It’s a small amount of work if it’s designed in at Phase 0 and a painful retrofit later, because by then every workflow assumes it can see everything.
Related: RLS is enforced at the database, and n8n’s own credential store and execution data are not under it. If a workflow can read a credential, tenancy doesn’t constrain what it can reach. Worth deciding early whether a second physician means new rows or a second n8n instance — that’s an architecture fork, not a config toggle.
The question that shapes most of the above: what is a tenant in your model — the physician, the collaboration, or the state? They produce three different schemas, and “scales to a second physician without doubling my operational load” means something different under each.
Software engineer, 100% remote, Pacific time (UTC-7), Kent, Washington. Happy to look at the developer brief and master plan.
— Lucas