Skip to content
Pre-launch · In hardening

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.

Updated Bell's own site, getbell.ai (opens in a new tab)

Automated tests
13,000+
Stack
React · Bun · PostgreSQL
In development since
August 2026
Build time
27 working days
01

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.

02

The divide

What did Plutonapps engineer?

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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

04

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

05

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.

FAQ

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.

Get started$2,999 per month

Billed yearly. Month to month is $3,999 per month.