Should I vibe code
Model contacts and companies flexibly, create views, and manage a pipeline
A CRM is a database of people who never agreed to be in your database.
?
Their verdict, the Plus price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Flexible objects and views is a good build. Remember contact records are personal data with deletion rights attached, including for people you only ever emailed once.
What actually breaks
not "if". the specific failures.
- Duplicates, which arrive constantly — the same person with a work email, a personal email and a typo — and which no simple key prevents
- Entity resolution, because deciding that two records are the same person is a judgement call you have to encode
- Merging, which needs to reassign every related deal, note and activity and be undoable when it was wrong
- Many-to-many reality: a person at two companies, a company with two people, a deal with five contacts
- Flexible object modelling, which is the selling point and means user-defined schema with all that implies
Someone imports a conference list. Four hundred rows, of which sixty are people already in the system under a different address. Your import matches on email, so all sixty come in as new records. The notes from last year's calls stay attached to the old ones. Now a salesperson opens the duplicate, sees no history, and pitches a customer of three years as though they had never spoken — and the record showing otherwise is one row away, invisible, because nothing told anyone the two were the same.
Is that you?
the verdict is a default, not a law
- It is a read-only view over a CRM that already resolves entities
- The contact list is small enough that you personally know every entry
- Records are only ever created one at a time, by hand, by you
- Contacts arrive by import or from a form
- There is no duplicate detection beyond exact email match
- Merging is unimplemented or irreversible
- Several people rely on the history attached to a record
If you build it anyway
the checklist, then the prompt that enforces it
- Build duplicate detection before import. Match on normalised email, then on name plus company, and surface likely matches for a human rather than deciding silently.
- Never auto-merge. Present candidates, let a person confirm, and keep the merge reversible by retaining both source records.
- Model relationships as many-to-many from the start. Person-belongs-to-company is wrong within a month and the migration is painful.
- Normalise on write — lowercase emails, strip plus-addressing where appropriate, canonicalise phone numbers — so matching has something stable to work with.
- Make every import a dry run first, reporting how many rows are new, matched or ambiguous, and require confirmation.
- Keep an activity timeline per entity that survives merges, since history is the entire reason a CRM exists.
Before you build a CRM, apply these and push back if I ask you to break them. 1. Tell me at the start that duplicate handling is the actual product. Contact records arrive from imports, forms and manual entry, and the same human will appear under several addresses. A CRM without entity resolution slowly stops being trustworthy. 2. Implement duplicate detection before implementing import. Match on normalised email first, then on name plus company or name plus phone. Surface likely duplicates for human confirmation rather than merging or ignoring them silently. 3. Never auto-merge records. Merging must be an explicit human action, must reassign all related notes, deals and activities, and must be reversible — keep the source records rather than deleting them. 4. Model person-to-company and person-to-deal as many-to-many relationships from the first schema. A single company_id on a person is wrong within weeks and expensive to change later. 5. Normalise on write: lowercase emails, canonical phone format, trimmed names. Matching needs stable input. 6. Every import runs as a dry run first and reports new, matched and ambiguous counts with samples. Require explicit confirmation before writing. 7. Keep an append-only activity timeline per entity that survives merges. The history is why anyone opens a CRM. 8. If users can define custom objects or fields, tell me that turns this into a configuration platform and ask me to confirm before building it. 9. Out of scope unless I ask: email sync, sequences, reporting, permissions.
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
Once contacts arrive from anywhere but your own typing. $36 a month buys entity resolution, reversible merges and a relationship model that already survived contact with reality — which is most of what separates a CRM from a spreadsheet with nicer views.
$36/mo is cheaper than your weekend.
Export contacts, companies, relationships and the activity timeline as separate linked tables with stable ids — the timeline especially, since a CRM's value is the history rather than the contact details. Keep the merge log too, so a future system can understand why two records became one.
Active open-source modern CRM with extensible data models.
Questions
Isn't matching on email address enough?
It catches the easy half. People change jobs, use a personal address on a form and a work one in a signature, add plus-addressing, or have their name typed slightly differently by whoever imported the list. Email is the right first key; treating it as the only key is what produces a CRM full of strangers you already know.
Why must merges be reversible?
Because merging is a judgement and judgements are sometimes wrong — two people at the same company with similar names, a shared family email address. An irreversible merge that was wrong has destroyed two histories into one, and there is no way to work out afterwards which note belonged to whom.
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-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice