# Build brief — a focused alternative to OutFriend

> **Verdict:** Partly, if you narrow it · **Buildability:** 56/100 · **Category:** Sales Outreach
> **Source:** https://www.canitbevibecoded.com/outfriend
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from OutFriend. Verify current pricing and capabilities before acting.

## Context

**OutFriend** — Learns your voice from emails you have actually sent, drafts the campaign, and sends it from your inbox on a schedule. It currently costs $29/mo.

This one is closer to buildable than most outreach tools, because OutFriend sends through your own Gmail rather than its own infrastructure. That removes the moat that usually saves this category: no warmup pools, no IP reputation, no deliverability engineering you cannot replicate. What is left is a Gmail OAuth integration, a voice sample you pass to a model, a scheduler with send windows and daily caps, and the one piece that is genuinely fiddly, watching threads so a sequence stops the instant someone replies. That is a focused implementation if you have written against the Gmail API before, and a long weekend if you have not.

This brief describes a focused, single-operator replacement for the part of OutFriend that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

- Track contacts, sequence outreach, and log replies for a pipeline you own.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- A leads CSV you sourced yourself.
- A scheduler that survives your laptop sleeping.
- Your own read of CAN-SPAM and GDPR before you send anything.

### Data and integrations

- A Google Cloud project with Gmail API access and OAuth consent configured.
- An OpenAI or Anthropic API key.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence.
- Verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues.
- A review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox.
- Lead generation, which the paid tiers include and your CSV does not.
- The Google OAuth verification process, which you will meet the moment you want this on more than your own account.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

## Existing alternatives

Before building, compare these checked options:

- [Mautic](https://www.mautic.org) — Runs the campaign, the throttling and the stop-on-reply. Writing in your voice is not in the box, and neither is a light afternoon of setup

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [Gmail API](https://developers.google.com/gmail/api) — Sending, threading and history endpoints; the whole send-and-detect-replies loop is here if you are willing to read it

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/outfriend