Should I vibe code
Run a basic sales pipeline closely tied to Google Workspace data
The pipeline is a spreadsheet with a stage column. The Gmail scope behind it is a copy of your company's mailbox.
?
Their verdict, the Basic price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A pipeline is a table with a stage column and an agent will hand you a good one before lunch. Copper's actual product is the Gmail sidebar — the thing that reads every message in a mailbox, matches it to a contact and files it without being asked. Build that and what you have is no longer a CRM: it is a server holding a refresh token with restricted Gmail scope for every person on the team, and the interesting question stops being 'can I model deals' and becomes 'what happens to my company's mail when this box is compromised'.
What actually breaks
not "if". the specific failures.
- Google's verification wall: restricted Gmail scopes require an independent CASA security assessment, redone every twelve months, before your app gets past the unverified-app screen and its user cap
- Refresh tokens expiring, being revoked by a Workspace admin, or quietly losing a scope — and the sync simply stops, with nothing in the UI to say so
- Deduplication. Two records for the same person, each holding half the history, and the merge you wrote picks the wrong survivor
- Deletion. 'Remove this contact' means the contact, the deals, the logged messages, the calendar links and the attachments, and your foreign keys were an afterthought
- Threading. Message-ID, In-Reply-To and References are the only things that make a thread a thread, and subject-line matching files a customer's reply under a stranger
The Gmail sync has been fine for four months, so nobody looks at it. A new rep grants access with the wrong Google account, and your matching logic — which keys logged mail to the contact's domain — starts filing their personal correspondence against whichever accounts they happen to mention. It surfaces during a quarterly review, on a shared screen, when a customer is shown their own 'history' and three of the messages in it were never meant for them. The code fix takes an hour. The conversation with your own team about what else the box has been reading does not.
Is that you?
the verdict is a default, not a law
- It is a read-only view over a CRM you already pay for
- No mailbox is connected and contacts are typed in by hand
- It is your pipeline alone, and nobody loses a deal because you broke something on a Friday
- It requests Gmail or Drive scopes for anyone other than you
- You have no answer to 'delete everything about this person' that runs in under a day
- The sales team would lose the deal history if the database did
- You are storing refresh tokens with no plan for the morning one is revoked
If you build it anyway
the checklist, then the prompt that enforces it
- Build the CRM without Google first. If the pipeline is not useful with contacts typed in by hand, the Gmail sidebar will not rescue it.
- Reach for the narrowest scope that works — gmail.metadata threads conversations without ever storing a body — and only widen it when you can say why.
- Read Google's restricted-scope verification requirements before designing anything around Gmail. The annual security assessment is a budget line and a calendar item, not a checkbox.
- Store refresh tokens encrypted with a key held outside the database, and treat revocation as an expected event with a visible re-auth prompt rather than a silent stall.
- Model deletion first: one tested cascade that removes a person, their deals, their logged messages and their attachments, before you write the first create form.
- Thread on Message-ID and References, never on subject and participants. Subject threading merges unrelated conversations and looks correct right up until it isn't.
I am building a small CRM that will eventually read Gmail. Treat the mailbox integration as the dangerous part and hold these lines even if I push.
1. Build contacts, organisations, deals and activities with manual entry only.
Get that useful first. Do not scaffold any Google integration until I ask
for it by name.
2. Before writing a line of Gmail code, tell me what Google requires for
restricted scopes: app verification, an independent security assessment if
my server touches the data, annual re-assessment, and a user cap until
verified. I need that cost in front of me, not discovered later.
3. Default to the narrowest scope that satisfies the feature. Propose
gmail.metadata before gmail.readonly and explain what I lose.
4. Implement the full deletion cascade — person, deals, activities, logged
messages, attachments — with a test, before any create or import path.
5. Implement relational export (CSVs sharing stable ids) before import. I must
be able to leave before I am allowed to arrive.
6. Refresh tokens are encrypted at rest with a key from the environment, never
logged, never rendered, and stored apart from CRM records.
7. Token revocation and scope loss are normal states, not errors. Surface them
as a visible re-auth prompt on the affected user. A sync that silently
stopped is the failure mode I care about.
8. Thread strictly on Message-ID, In-Reply-To and References. Never match on
subject line or participant set, and tell me when a message cannot be
attributed rather than guessing at a contact.
9. Never auto-merge duplicate contacts. Show me candidates, let me choose the
survivor, and keep the merge reversible for thirty days.
10. Write an access log for reads of logged email bodies. If I ever have to
answer 'who saw this customer's mail', it must be a query.
11. Out of scope, and say so rather than half-building: calendar write-back,
sequences, bulk sending, and enrichment from third-party data brokers.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as a second person depends on the pipeline, or as soon as Gmail is in scope. Twenty-nine dollars a seat buys a Google integration that has already survived Google's verification process, a deletion path somebody else tested, and a merge tool that has been wrong often enough to have become careful. Twenty is the open-source route if what you wanted was control rather than savings.
$29/mo is cheaper than your weekend.
Everything valuable here is relational, so the export has to be relational too: contacts, organisations, deals, activities and the links between them, as CSVs sharing stable ids. Run that export into a real CRM's importer once, early — the shape it wants is the shape you should have been storing. The logged email bodies are the part that will not import cleanly, which is one more argument for never having stored them.
Active open-source CRM with extensible data models; self-hostable and already past the schema decisions you would be making at midnight.
Questions
Can I use the Gmail API and skip verification?
For your own account, yes — unverified apps work fine for the developer and a small allowlist. The wall arrives when a teammate needs access. Gmail read scopes are 'restricted', which means Google verification, and if your server touches the data, an independent CASA security assessment renewed every twelve months. That is a real recurring cost that lands after you have already built the thing.
What's the difference between this and a spreadsheet?
For one person, honestly not much, and the spreadsheet has better undo. A CRM earns its keep when several people need the same pipeline at once and nobody wants to think about who has the file open. That is also precisely the moment it becomes something other people depend on.
Is the contacts-and-deals half safe to build?
Yes, and it is a genuinely good project — right up to the point where the deal history only exists in your database. Deletion and export are the two features to build first, because they are the ones you will need on a bad day and the ones an agent will happily leave for later.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice