Should I vibe code
Provide contacts, pipelines, tasks, notes, and a straightforward daily agenda
The risky column is not the email address. It's the free-text note explaining why someone's deal fell through.
?
Their verdict, the Standard 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, notes, a pipeline and a daily agenda is about as friendly as a schema gets, and an agent will hand you a working one before lunch. Then it fills up. Within a year it holds a few thousand people who have never heard of you, and the most sensitive column is not the email address — it is the free-text note where somebody wrote why the deal stalled, what the buyer's boss is like, and that they are off sick until March. You are now the controller for all of it, running your own login page, on a box you patch when you remember, with no export, no audit trail and no answer to the first person who writes in asking what you hold about them. Nothing dramatic happens. It just quietly becomes the system your business cannot lose and cannot get out of.
What actually breaks
not "if". the specific failures.
- The free-text notes, which are the whole point of a CRM and also the part that turns a contact list into opinions about named people that they are entitled to ask for
- Your own login page — password reset, session invalidation, what happens when a colleague leaves — which is the most confidently generated and most subtly wrong code an agent produces
- Export, because there is never a reason to build it until the day you need it, and by then "all my customer relationships" lives in a schema only your app understands
- Deletion, which has to reach the contact row, the notes, the pipeline history, the attachments and last night's CSV in a bucket, and which almost always misses at least two of those
- Backups of the one table nobody thinks of as a database — a bad migration on the notes column is not recoverable from anywhere
- Access control the moment there is a second user, when "who can see whose pipeline" stops being a UI question and becomes a query you have to get right everywhere
- The integrations that make it useful — calendar sync, email logging, a mail merge — each of which drags a credential and somebody else's rate limit into your evenings
Nine months in, an email arrives from a contact who wants to know what you hold about her and would like it deleted. You are not worried — there is a contacts table and a delete button. Then you start looking. Her name is in four notes attached to other people's records, in a pipeline history that references a deal she was on, in the attachments folder as a PDF filename, in the nightly CSV that has been landing in an S3 bucket since March, and in the Slack channel your webhook posts new-contact alerts to. The delete button removes exactly one row of those. You spend the evening grepping your own database trying to work out what you actually promised, and the honest answer to her second email — "can you confirm it's all gone" — is that you do not know.
Is that you?
the verdict is a default, not a law
- It is your contacts, on your machine, and nobody else logs in
- Everything it holds is a copy of something authoritative that lives somewhere else
- There is a one-click export to CSV before there is a second feature
- You are tracking your own job hunt or your own freelance leads, and losing the lot would be annoying rather than existential
- A second person logs in, at which point you have written an auth system and a permissions model whether you meant to or not
- It becomes the only record of a customer relationship, with nothing upstream to rebuild from
- You cannot produce, or delete, everything you hold about one named person in an afternoon
- The notes field is where people write frank things about clients, colleagues and their circumstances
If you build it anyway
the checklist, then the prompt that enforces it
- Export first. A complete CSV or JSON dump of contacts, notes, deals and history, on a schedule, before the pipeline board exists. It is your backup, your migration path and your subject-access answer in one.
- Do not write authentication. Use an identity provider and inherit password reset, session revocation and account removal, because "a colleague left last month" is a security event you will otherwise handle by hand.
- Build deletion as a named operation across every store from the start — rows, notes, attachments, exports, search index, webhook history — and test it by deleting a real contact and grepping for their surname.
- Treat free-text notes as the sensitive field. Restrict who sees them, keep them out of logs and out of alert payloads, and never put one in an email subject.
- Log who read and changed what. Without an audit trail you cannot answer the only two questions that matter after an incident.
- Back up nightly, restore into a scratch database monthly, and confirm the notes came back. An untested backup of the one irreplaceable table is a rumour.
I am building a small CRM: contacts, notes, deals, tasks. Most of the data belongs to people who have never heard of my software, and the free-text notes are more sensitive than the email addresses. Order the work around getting data out and getting it deleted, and push back when I skip ahead. 1. Build export before anything else: one command that dumps contacts, notes, deals, tasks and history to CSV or JSON, complete enough to rebuild the database. Schedule it, and store it somewhere I control. 2. Then deletion. One named operation that removes everything about a single person — rows, notes on other people's records, attachments, search index, webhook history, exports. Test it by deleting a real contact and grepping the whole system for their surname. 3. Do not write authentication, sessions or password reset. Use an established identity provider. If I ask you to roll our own login "just for now", refuse and explain what happens when someone leaves the company. 4. Every query that reads contacts or notes is scoped by the current user's permissions at the data layer, not in the UI. Write that in before the second user exists. 5. Free-text notes are the sensitive field. Never log them, never include them in webhook or alert payloads, never put one in an email subject, and keep them out of any analytics event. 6. Add an audit log of who read and changed which record, with timestamps, before adding features. After an incident it is the only evidence I have. 7. Nightly backups with a documented restore, verified monthly into a scratch database by looking for the notes. Migrations run on a copy first and keep the previous file — the notes table has nothing upstream to rebuild from. 8. Ask me before adding any integration that stores a credential — calendar, mailbox, mail merge — and tell me what a leak of that credential reaches. 9. Out of scope and say so: bulk email, sequences, and anything that sends to the contact list. If I want that, tell me it is a separate and worse problem, and that Less Annoying CRM is $15 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
As soon as a second person needs to log in, or as soon as the CRM is the only place a customer relationship is recorded. $15 per user per month buys authentication somebody else maintains, backups somebody else tests, and an export that already exists on the day you need to hand your data to a lawyer, a successor or the contact who asked for it. For one person tracking their own leads locally, building it is fine — the verdict is about the version with logins.
$15/mo is cheaper than your weekend.
The exit is the export, which is why it is guardrail number one. A scheduled dump of contacts, notes, deals and history in CSV means the project can be abandoned in an afternoon — every CRM on the market imports that shape, including the one you were avoiding paying for. Without it, leaving means retyping a year of relationships from a schema only your app understands, which in practice means never leaving and never upgrading either.
Very active open-source CRM with extensible data models and a real permissions layer.
Long-running self-hostable CRM aimed at exactly the small businesses Less Annoying CRM sells to.
Questions
It's a CRUD app. Why is this harsher than canivibecodeit's KINDA?
Because we are not scoring the build, we are scoring the year afterwards. The CRUD really is a lunchtime, and that is the trap: the schema is easy, so it gets built, and then it accumulates other people's data faster than it accumulates any of the boring machinery — export, deletion, audit, backups, sane permissions — that makes holding that data survivable.
What if it is genuinely just me?
Then most of this page does not apply and it is close to a SHIP IT. One user, local, with a CSV export and a backup is a fine thing to build. The verdict is written for the moment a second person logs in, because that is when you have quietly written an authentication system, a permissions model and a shared system of record without deciding to.
Which single guardrail matters most?
Export, and it is not close. It is your backup, your migration path and your answer to a subject access request, and it costs an hour on day one. Every other item on this page is recoverable if you can get the data out; none of them are if you cannot.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
For a small business a homemade CRM is fine. Just know what you are storing about whom.
Your CRM's worst day isn't a breach. It's the Friday a salesperson resigns and you can't tell what they took.
Rebuild the pipeline board, fine. The part that ends in "send to 400 people" is not a side project.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice