# Bell Case Study: AI Email Assistant Source: https://www.plutonapps.com/work/bell Published 2026-09-30, updated 2026-10-27. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). An AI email assistant for Gmail. Its assistant, Bella, sorts the inbox, works out what each email is asking of you and drafts the reply, in chat or by voice. The founder designed it in Lovable. We rebuilt everything underneath: a ledger that sends each email exactly once with a two-minute undo, a database that refuses any send no person approved, AI that treats every email as hostile, hard daily limits on AI spend, and a Gmail connection that can read and send, and do nothing else. ## At a glance Bell is an AI email assistant for Gmail users. Its assistant, Bella, sorts the inbox, works out what each email is asking, and drafts the reply, and nothing irreversible leaves without the person's approval. The founder designed it in Lovable; Plutonapps engineered the system underneath, with exactly-once sending, hard limits on AI spend and more than 13,000 automated tests. It is pre-launch and running on staging. - **Product:** An AI email assistant for Gmail, with an assistant, Bella, in chat and by voice - **Built in Lovable:** The whole product as a working proof of concept (51 pages), then its screens as a clickable demo - **Apps:** API, background worker, web app, and Electron desktop and Capacitor mobile shells, over 6 shared packages, shipped as 3 container images - **Stack:** React 19 · Vite · Tailwind CSS v4 · Hono · tRPC · Bun · PostgreSQL · Drizzle · pg-boss · Clerk - **Timeline:** First commit August 14, 2026 · first real mailbox imported August 20 · on staging from August 22 · current staging build September 21, 2026 - **Engineering record:** 771 test files in 11 groups · 8 CI jobs across 2 workflows · 1,307 commits and 285 merged pull requests - **Status:** Pre-launch: running on staging, with early-access requests open on getbell.ai Product site: [getbell.ai](https://www.getbell.ai) **0** Emails Bell can send without a person's approval.. Every send, reply and calendar invite records who authorized it, and the database itself refuses one that no person asked for or approved. The rule is an allow-list, so any autonomous mode added later starts out denied. > Building an in-house team with this much security, testing and launch experience would have taken us a year of recruiting. We got the whole discipline for roughly one senior salary. > > — Client review, Bell ## What did the founder design in Lovable? The founder built Bell first as a full proof of concept in Lovable: 51 pages over 151 backend functions and 143 database tables, with Bella in chat and by voice, a Solve conversation for working through an email, calendar booking pages and a weekly digest. When the first rebuild of the screens missed how the product worked, the founder took the backend out and published the screens as a clickable demo. That became the specification. Its code was never extended. ## Why could it not go live as it was? An email assistant holds the keys to someone's working life. In the prototype the browser queried the database directly, and the review of its row-level security rules covered about 12 of its 143 tables. Its outbox for sending mail was never wired up, its AI cost breakers had no callers, and its expensive second opinion quietly ran on the same cheap model as the first. One email sent twice, one mailbox shown to the wrong person, or one message that talks the AI into acting, would end the product. ## Product decisions ### Sending is the only thing Bell does to Gmail Archive, snooze, drafts and categories live in Bell and never change the mailbox. The founder made that call so Bell asks Google for exactly two permissions, read and send, and nothing else. ### Bella, in chat and by voice One assistant for the whole inbox. She can act only on something that traces back to what the person asked for, and a new recipient must be someone the mailbox already knows or the person named. ### The Feed, for everything that can wait Newsletters, promotions, receipts, notifications and cold outreach move out of the inbox into a Feed to read when there is time, with a real one-click unsubscribe. ### Nothing billed before it is built Billing and Microsoft mail come last, on purpose: a billing page before launch bills for a product the user cannot see yet, and a second mail provider adds a second sync before the first is proven. ## What did Plutonapps engineer? ### Every email sent exactly once Risk in the prototype: An email that goes out twice cannot be recalled, and a retry, a second tab or a crashed worker can each send it again. The prototype's outbox for sending was never wired up. Every outgoing action is first written to a ledger under one permanent key for what the person meant, so retries, second tabs and redelivered jobs all land on the same row. A worker must win a claim before it acts. Bell stamps each message with its own ID before sending, and if Gmail times out it searches Sent for that ID instead of sending again. When in doubt the email waits for a person: stuck beats duplicate. Every send also sits in a two-minute hold, which is the Undo button. ### Nothing irreversible without a person Risk in the prototype: An assistant that can reply for you can also reply wrongly. The prototype checked a 'trust it' rule before any safety signal, so a suspected phishing email could be handled on its own. Every action records who authorized it, with no default. Sends, replies and calendar invites are irreversible, and the database itself refuses them unless a person asked for them or approved them. The rule is an allow-list, so any future autonomous mode is denied by default. Security alerts and spam always go to a person, a new recipient must be someone the mailbox already knows or the person named, and one switch stops every autonomous action. ### Every email treated as hostile Risk in the prototype: Anyone can send you an email, and an email can be written to instruct an AI. In Bell's own evaluation set, an email that wrote out its own verdict chose its own category and switched off the second check. Email bodies are fenced off from the AI's instructions. A plain-code check reads the raw message before the model does, so an email cannot turn off its own review. A request the AI extracts is dropped unless it quotes text that is really in the email. Phishing is graded none, suspicious or clear, with rules for lookalike sender domains. The red-team tests run against a deliberately obedient fake model, so the safety has to come from the structure, not from the model behaving. ### AI spend with a hard ceiling Risk in the prototype: Every email Bell reads is an AI call, so a stuck import or a looping job becomes a bill. In the prototype the cost breakers had no callers, and the off switch was checked at 17 of 28 call sites. Every model call goes through one router, in one order: off switch, budget, circuit breaker, then the call. Each person has a daily limit in dollars and in calls: at 80% Bell drops to cheap triage, at 100% it stops, and a global limit sits above both, all tunable without a release. A build check forbids model names anywhere but the router, so the prototype's drift, where the expensive second pass ran on the cheap model, cannot come back unnoticed. ### Mailboxes that cannot see each other Risk in the prototype: The prototype let the browser query the database directly, and the review of its row-level security rules covered about 12 of its 143 tables. One missing filter is someone else's inbox. The browser never touches the database: every request passes one server boundary that checks the session. Every function that reads mail takes the user first, a rule a build check enforces, and tests running on a real PostgreSQL database act as one user against another's rows. The live update stream authenticates with a header, never a token in the address, and re-checks the session about every fifty seconds. ### A Gmail connection that can only read and send Risk in the prototype: Ask Google for a permission its consent screen does not offer and sign-in fails for everyone. For a while in the rebuild, one setting could widen what Bell asked for, with no code review. Bell asks for exactly two permissions, read and send, written as a constant in code. The setting that could widen them was deleted, along with the unused code that could change a mailbox. The connect step checks the grant can read and send before it goes on, and a build check stops any call that changes a mailbox from being made outside the one package that runs actions through the ledger. ### Unsubscribing without being used Risk in the prototype: An unsubscribe link is an address chosen by a stranger. Followed blindly by a server, it can reach internal systems, tell a tracker the mailbox is read, or be aimed at the person's own company. Bell unsubscribes on its own only when the sender declares the one-click standard over a secure connection; otherwise it shows the person the link. Every address the name resolves to is checked, private and cloud-internal ones are refused, the connection is pinned to the address that was checked, and redirects and the person's own domain are refused. There is a cap of 100 a day, and every request goes through the same exactly-once ledger. ## What were the results? - **13,000+** Automated tests, in 771 test files - **134** Test files that run against a real PostgreSQL database - **47** Database tables, where the prototype had 143 - **27** Working days from first commit to the staging build - **285** Pull requests merged into the staging build - **2** Gmail permissions Bell asks for: read, and send _Counted from Bell's own repository and CI at its staging build of September 21, 2026. No load test has been run, so none is quoted._ ## Outcomes - More than 13,000 automated tests in 771 test files, 134 of them against a real PostgreSQL database. - Every email sent exactly once through one ledger, with a two-minute undo. - No send, reply or calendar invite possible without a person's approval. - Pre-launch: running on staging, with early-access requests open. ## What do we hold ourselves to while it runs? - **Sending:** Exactly once, with a two-minute undo - **Approval:** No send leaves without a person - **AI spend:** A daily limit per person, checked before every call - **Deletion:** A deleted account's stored mail is purged within minutes ## What else do people ask about Bell? ### What did Plutonapps build for Bell? Everything underneath the founder's Lovable design: the ledger that sends each email exactly once, the database rule that refuses any send no person approved, the defenses that treat every email as hostile, the AI router with its daily spend limits, and the Gmail connection limited to read and send. ### Can Bell send an email without approval? No. The database refuses any send, reply or calendar invite that no person asked for or approved, and every send waits two minutes so it can be undone. ### What access does Bell have to a Gmail account? Two Google permissions: read, and send. Archive, snooze, drafts and categories stay inside Bell and never change the mailbox, and no setting can widen that access. ### How long did the build take? 27 working days from the first commit on August 14, 2026, to the staging build of September 21, 2026: 1,307 commits and 285 merged pull requests, with more than 13,000 automated tests. ### Is Bell live? Not yet. Bell is pre-launch: it runs on staging, production is not switched on, and its site, getbell.ai, takes early-access requests. ## Sources - [Bell's own site, getbell.ai](https://www.getbell.ai)