BccBuddy

Turning email into action

A service that runs sales workflows straight from your inbox.

An email with deal@ in the Bcc line, and the BccBuddy activity it triggers: the deal logged with its details, the CRM updated, a follow-up task and a confirmation — One Bcc does the work. Seconds after sending, the deal is logged, the CRM is updated and the follow-up is on the calendar.

The workflow behind deal@: extract the deal details, create or update the deal in the CRM, create a follow-up task and reply to the sender, with recent runs alongside — Behind each address is a workflow of steps. This is deal@, with its latest test and recent runs.

The problem

Salespeople live in their inbox, but their pipeline lives in a CRM. Every conversation that should become a deal, a task or a reminder has to be copied over by hand, and the ones that don't get copied are the ones that slip.

What I built

BccBuddy turns the Bcc line into a command line. Bcc an address like deal@ on an email and it logs the deal; task@ creates the follow-up; reminder@ sets the reminder. No new app to open: the email you were already sending does the work.

Behind each address is a workflow of steps, and steps can write to the tools a team already uses, such as a CRM. A browser extension brings the same actions into the inbox itself.

How it works

A Next.js app handles sign-in, settings and the workflows. Inbound email and the heavy lifting run on AWS Lambda, and everything reads and writes one Postgres database. The product works in three flows:

Set up, in the web app. A salesperson builds a playbook from a library of steps, creates a trigger address such as deal@ and attaches it, and connects HubSpot, Salesforce or Google Calendar by signing in to each.
An email arrives. Intake hands it to the API, which finds the sender, or quietly onboards them on first contact. It matches the sender and address to a trigger, loads that trigger's playbook, and runs it as a workflow. Each step calls the connected tools, and every step's state is recorded, which is what powers the history and analytics.
The extension. It signs in through the web app, syncs the salesperson's triggers, and uploads attachments that workflows can use.

The highlighted path follows a Bcc'd email from the salesperson to the CRM.

The most interesting engineering decision so far isn't a feature but a planned move: taking the product off a hosted backend-as-a-service and onto infrastructure I run myself. The plan:

Postgres onto my own Kubernetes cluster. The app already talks to Postgres through a plain driver, so the database move is mostly a connection string, plus a managed operator for replication and backups.
Identity onto a self-hosted Keycloak. Sign-in is the most security-sensitive part of the product, and it's the part most worth owning: schema, themes, emails and audit logs.
OAuth only. Google and Microsoft sign-in with no passwords stored at all, which removes the whole sign-up, reset and change-password surface.
Stable user IDs. Every user keeps the same ID through the move, so nothing downstream has to know it happened.

What was hard

Working across technical and non-technical people once LLMs made everyone fast. Velocity went through the roof. The models were good enough at building interfaces, but the interface isn't the system, and that was misleading. Screens were designed without regard for the shape of the backend. Data was stored in the browser on the assumption that it was saved. Output rose faster than understanding of the system underneath it, and that gap was the hard part to manage.

What I learned

When anyone can produce a working screen, the hard part of software moves to the system behind it: how data is shaped, where it lives and what the product can actually trust. That lesson led me to Nano, and to thinking much more deeply about software engineering and how teams will work in these environments.