Bell
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.
- Automated tests
- 13,000+
- Stack
- React · Bun · PostgreSQL
- In development since
- August 2026
- Build time
- 27 working days
The Lovable prototype
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.
The divide
What did Plutonapps engineer?
The prototype risk
Engineered by Plutonapps
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 email sent exactly once
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.
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.
Nothing irreversible without a person
Every action records who authorised 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.
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.
Every email treated as hostile
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.
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.
AI spend with a hard ceiling
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.
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.
Mailboxes that cannot see each other
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.
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.
A Gmail connection that can only read and send
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.
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.
Unsubscribing without being used
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.
0
Emails Bell can send without a person's approval.
Every send, reply and calendar invite records who authorised 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
Guarantees
What 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
Results
What were the results?
- Automated tests, in 771 test files
- 13,000+
- Test files that run against a real PostgreSQL database
- 134
- Database tables, where the prototype had 143
- 47
- Working days from first commit to the staging build
- 27
- Pull requests merged into the staging build
- 285
- Gmail permissions Bell asks for: read, and send
- 2
Counted from Bell's own repository and CI at its staging build of 21 September 2026. No load test has been run, so none is quoted.
Stack and timeline
- 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 14 August 2026 · first real mailbox imported 20 August · on staging from 22 August · current staging build 21 September 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
Engineered & run by Pod 02
Rohan Patel · engineerSam Gibson · key account manager
Monitored around the clock. When something goes wrong at three in the morning, Rohan is the one who answers.
Example team. Names are illustrative.
Questions
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 defences 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 14 August 2026 to the staging build of 21 September 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.
Everything you have just read runs on a custom-priced plan. Starter is the plan we start everyone on.
Bring us what you made. We will build it like this.
Billed yearly. Month to month is $3,999 per month.