Should I vibe code
Run a small-business pipeline with contacts, activities, and simple workflows
Your CRM's worst day isn't a breach. It's the Friday a salesperson resigns and you can't tell what they took.
?
Their verdict, the Express 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
Contacts, companies, deals, stages, activities — this is the schema an agent is best in the world at, and you will have a working pipeline board before the coffee goes cold. Bigin is also nine dollars a seat, which makes the money argument almost silly, so the real question is what you are signing up to own. A CRM is multi-user by definition, and the day a multi-user CRM is genuinely dangerous is the day somebody leaves. Their session is still valid because you never wrote invalidation. Their Gmail sync token is still refreshing in the background because revoking it was never a screen. They could see every pipeline because per-record ownership was a UI filter. And you cannot tell whether they exported the contact list on the way out, because there is no audit log — audit logging is the sort of feature that never makes it into version one and never gets added afterwards. It works fine for a year. Then somebody resigns and joins a competitor.
What actually breaks
not "if". the specific failures.
- Offboarding, which is four separate things nobody builds: killing live sessions, revoking the mail and calendar OAuth grants, reassigning owned records, and being able to say afterwards what was accessed
- Record-level permissions, because "everyone sees everything" is fine at two people and becomes a resignation problem at six, and retrofitting ownership onto an existing schema means auditing every query you have written
- Mail sync tokens, which are long-lived refresh grants to a whole mailbox sitting in your database — the single most valuable thing in the system, and the thing least likely to be encrypted at rest
- The absence of an audit log, which is invisible until the one week you would have given anything for it
- Duplicate contacts, arriving from a web form, an import and a business-card scan, and merging them is where notes and consent flags quietly get dropped
- Export, since there is never a reason to write it until the day you need it, and by then every customer relationship you have lives in a schema only your app understands
- Deletion requests, which have to reach the contact, the activities, the email log, the attachments and last night's CSV backup
- The features you did not rebuild — the mobile app someone uses in a car park, the phone that records, the payment link — which is how a team drifts back to the spreadsheet within a quarter
The resignation is amicable and the handover is tidy, right up until a customer mentions three weeks later that they have had a very similar-sounding call from somewhere else. You go looking. The account was disabled on the last day, but disabled means a boolean on the user row, and the session token issued in March is still being accepted because you never implemented invalidation and set the expiry to a year so people would stop complaining about logging in. The Gmail integration is worse: the refresh token is still live, still pulling mail into the activity feed, and revoking it turns out to require a call to Google's API that nothing in your app has ever made. Then the actual question arrives, from your co-founder, and it is a reasonable one — did they export the contacts before they left? You have web server logs with paths in them, no record of which records were read, and no export event to look for, because export was a button that ran a query. The honest answer is that you do not know, and you are going to have to say that out loud.
Is that you?
the verdict is a default, not a law
- One person uses it, on their own machine, and the notes are about their own leads
- It reads from a system of record you already trust rather than becoming one
- Every contact is exportable to CSV today, without you writing anything first
- Losing the whole thing would cost you a morning of re-entry
- More than one person logs in and you have not decided who can see whose records
- You cannot revoke a departed colleague's session and mailbox access in under five minutes
- There is no record of who read or exported what
- It holds mail or calendar OAuth tokens that are not encrypted at rest
- It is the only place a customer relationship is written down
If you build it anyway
the checklist, then the prompt that enforces it
- Design offboarding before onboarding. Disabling an account must invalidate every live session, revoke every OAuth grant that account authorised, and reassign the records it owned — as one operation, with a test.
- Give every record an owner and a visibility rule from the first migration. Adding ownership to a live CRM means re-auditing every query in the codebase, and you will miss one.
- Log reads and exports, not just writes. The question you will eventually be asked is what somebody saw, and a write-only audit trail cannot answer it.
- Encrypt mail and calendar refresh tokens at rest with a key that is not in the same database, and treat that table as the crown jewels — it is access to a whole mailbox, not to your app.
- Write CSV export in week one and run it on a schedule to somewhere off the box. It is the backup, the migration path and the answer to a data request, all for an hour's work.
- Model consent and do-not-contact as fields that survive a merge. Deduplication that drops the flag saying someone asked not to be emailed is how a tidy-up becomes a complaint.
- Implement deletion as an enumerated list of every place a person's data lands, kept in code next to the schema so it gets updated when you add a table.
- Do not add mass email. It is one checkbox in the CRM and an entirely different risk category, with your sending domain as the fuse.
- Do not add call recording. Bigin includes it because Zoho has consent notices, retention settings and a legal team; a homemade recorder has none of those and the rules differ by state and country.
I am building a small-team CRM: contacts, companies, pipelines, activities. Build it in
this order and refuse to skip ahead — the pipeline board is the easy part and the part
I will be tempted to start with.
1. First, the account lifecycle. Sessions are short-lived and revocable from a
server-side store. Disabling a user kills every live session, revokes every OAuth
grant they authorised and reassigns their owned records, in one transaction, with a
test proving the old session is rejected.
2. Then ownership. Every contact, company, deal, note and activity has an owner and an
explicit visibility rule enforced in the data layer on every read — never filtered
only in the UI. Write the test that fetches another user's deal by id and expects 404.
3. Then the audit log, covering reads and exports as well as writes: who, what record,
when, from where. Say plainly that a write-only log cannot answer the question I will
actually ask.
4. Then CSV export of everything plus a scheduled off-box backup. This is my migration
path, my disaster recovery and my answer to a data-subject request.
5. Only now the pipeline, stages, activities and views.
6. For Gmail or Outlook sync: request the narrowest scopes that work, encrypt refresh
tokens at rest with a key held outside the database, and build the revoke path in the
same commit as the connect path.
7. Model do-not-contact and consent source as first-class fields, and make deduplication
preserve the most restrictive value across merged records, never the newest.
8. Implement deletion as an enumerated list in code covering contacts, activities, notes,
attachments, email logs, search index and backups, updated whenever a table is added.
9. Do not build mass email. Say once that it is a different risk category with my sending
domain as the fuse, and leave it out.
10. Do not build call recording. Consent rules vary by jurisdiction and this is not the
project to learn them in.
11. In the README, write who can see what, and note that the product I am replacing costs
$9 per user per month.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
Almost immediately, because the arithmetic is absurd: a four-person team is $36 a month, which is less than one hour of the time you will spend on session invalidation alone. What that buys is not the pipeline board — you can genuinely build that — but the parts you were never going to write: an audit log, a mobile app that works in a car park, a phone with recording and retention settings, payment links, and an offboarding switch that actually revokes things. Build it for yourself if you like the exercise. The moment a second person logs in, pay the nine dollars.
$9/mo is cheaper than your weekend.
Write the CSV export before the pipeline board and schedule it off the box nightly — contacts, companies, deals with their stage and value, activities, and notes with their author and timestamp. That file set is what every other CRM's importer expects, and it is also what you hand a lawyer, a successor or the contact who asks what you hold. The things that will not survive the move are attachments and email threads, so keep those as files in a folder structure named after the record ids rather than as blobs in a table nobody else can read.
Active open-source modern CRM with extensible data models.
Long-running open-source CRM with record-level access control and an audit log already built.
Questions
Attio and Pipedrive are DEMO ONLY here. Why is Bigin YOUR FUNERAL?
Because of who uses it. Attio and Pipedrive get prototyped by one person evaluating a workflow; Bigin is sold at $9 a seat to teams for whom it becomes the system of record for every customer relationship. The homemade version of a solo tool wastes your weekend. The homemade version of a shared system of record wastes everyone's, and it does it on the day somebody leaves.
Is the departing-employee problem really the biggest one?
It is the one that is both certain to happen and certain to be unhandled. Data loss you can mitigate with backups, and a leak needs an attacker. Somebody resigning needs nothing — it is a normal Tuesday — and it exercises four features at once that no generated CRM has: session invalidation, OAuth revocation, record reassignment, and an access log. Three of those are hard to add later. The fourth is impossible to add retroactively, because the log you needed covers last month.
What about the phone and the payment links?
Leave them out, and notice that leaving them out is most of why the rebuild disappoints. Bigin bundles call recording and Stripe/PayPal payment links into the same nine dollars, and both drag in a whole regulatory apparatus — consent notices and retention for recordings, somebody else's money for the links. Your version will have the pipeline board and none of the things the team opens the app for.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
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