I run a small software company in Tokyo. I am an engineer, not a salesperson. Cold outbound was the part of my job I kept avoiding. So I built an agent that does it for me. It runs as a Claude Code plugin, and the whole stack is open source. This post is about the architecture decisions that mattered.
The product is LeadAce (leadace.ai, source). It is in Public Beta. It finds companies that match your ICP, reads each company's site, writes one email per company, and sends from your own Gmail. Then it collects the replies. And it turns every rejection into a structured reason: budget, timing, wrong buyer, or missing feature. That data changes the next round's targeting.
Why a plugin, not another dashboard
The honest reason: I already spend all day in Claude Code. I did not want to build one more web app with a chat box in it.
Later I found a better reason. A Claude Code plugin runs on the user's own Anthropic plan, on their machine. I do not proxy the LLM calls. So I do not have to charge for them. The price only covers send volume and infrastructure. That is why the entry plan can be $29/mo. My users are developers who already pay for Claude Pro or Max. For them, "bring your own agent runtime" is a feature, not a limitation.
The plugin is only the UX layer. Everything stateful is a normal SaaS backend behind it.
The Claude Code plugin model in 30 seconds
If you have not built one: a plugin is a directory with skills (markdown instructions that become slash commands), an optional MCP server declaration, and scripts. Distribution is a git repo:
claude plugin marketplace add aitit-inc/leadace
claude plugin install leadace@leadace
LeadAce ships skills like /leadace (onboarding: point it at your homepage), daily-cycle, build-list, outbound, check-responses, and evaluate. Each skill is a prompt that works like a program. It contains instructions, guardrails, and references to MCP tools and local scripts. ${CLAUDE_PLUGIN_ROOT} resolves file paths inside the installed plugin. That sounds like a small thing. But you need it the first time a helper script inside your plugin has to run on someone else's machine.
The split that matters: LLM vs MCP tools vs local tools
The main design question for any agent product is this: what does the model decide, and what is code?
Our split:
-
MCP tools (server-side, deterministic): database writes, dedup, quota enforcement, compliance checks, do-not-contact lists. The model calls
record_outreach. It does not see the twelve validation rules behind it. The validation runs on the server. So a prompt injection hidden in some company's website cannot turn it off. - Local tools (user's machine): things that need the user's environment. Sending through their Gmail. Fetching pages. Browser automation. This is what keeps "sends from your own inbox" true.
- The LLM (judgment): reading a company's site and choosing the angle, writing the email, classifying a reply, updating the strategy.
The rule I ended up with: if a mistake causes a compliance or data problem, it must be code. If a mistake causes a quality problem, the model can do it, with review gates around it.
There is one more point I understood too late. This split is also the trust boundary. The agent reads random websites all day. A prospect's site is untrusted input by definition. So anything that touches the database or sends email has to be a fixed contract in code. It must not be something the model can be talked into.
Multi-tenancy: RLS as the safety net
Every table has a tenant_id. Every request runs in a Postgres transaction that starts with:
SET LOCAL ROLE app_rls
SET LOCAL app.tenant_id = '<tenant>'
app_rls is a role with row-level security enforced. The policies filter on app.tenant_id. Route handlers still write normal filtered queries. RLS is not the query mechanism here. It is the thing that saves you on the day a handler forgets a where. Only the auth middleware bypasses RLS, because it has to resolve user → tenant before the tenant is known.
The whole setup is about a hundred lines. This product stores other people's prospect lists and email threads. For that risk, a hundred lines is very cheap insurance.
One env var to turn off billing
The backend has one switch, LEADACE_EDITION. It has two values: cloud and self-hosted.
In self-hosted mode, the Stripe endpoints (/me/checkout, /me/portal, /stripe/webhook) return 404, and every tenant resolves to an unlimited plan. The default is self-hosted. So a fresh deploy fails closed into the free mode. It cannot accidentally run billing without keys.
This is what makes the open-source story real. The hosted service and the self-hosted deploy are the same code. Hosted is just the edition where Stripe is on. The deploy target is Cloudflare Workers + Supabase. The free tiers of both cover solo and small-team volume. So self-hosting costs nothing.
Why give away an unlimited edition? Because my buyer is a developer. A developer asks "what happens if this company disappears?" before wiring their outbound pipeline to a SaaS. My answer: you deploy the same repo and keep going. That answer closes the objection better than any uptime page. (The license is a modified Apache 2.0.)
What I would do differently
-
Ship the single entry point first. For weeks the plugin had many skills but no clear front door. Adoption got easier on the day
/leadace <your-homepage>became the one command that sets up everything else. - Build the receive side earlier. Each recipient gets a page where they can ask questions before replying. I believe this side is the long-term core of the product. The roadmap is agent-to-agent over A2A, and the rejection-reason schema will become a public spec. I built this part too late.
- Do not pre-load and merge for upsert PUTs. Two concurrent writers and one read-modify-write cycle means silent data loss. Use the database's upsert.
- Treat migrations as immutable once they touch any environment. I edited an applied Drizzle migration once because "it is only staging". That is how you get two divergent histories.
Honest numbers and limits
Cold outbound reply rates are in the single digits. The pitch is not "10x replies". The pitch is that the nos come back as structured reasons instead of silence. Sending is capped at a human pace per mailbox, on purpose. Recipients are limited to the US, Canada and Japan until per-country compliance rules ship. The plugin is verified on macOS with Claude Code today. Other runtimes are unverified.
We use LeadAce to sell LeadAce. So most of the rejection reasons in my dashboard are about my own product. Reading them is not fun. But it is the most useful screen in the product.
Code: github.com/aitit-inc/leadace · Product: leadace.ai (Free tier, no card)
If you have questions about the plugin model, the RLS setup, or the edition switch, I am happy to go deeper in the comments.
