Describe the business flow first.
What counts as a customer? Who can see or edit a record? What should happen after a follow-up is completed? These decisions define the CRM more clearly than a list of screens.
Begin with a small journey: find a customer, read the current status, add a note and schedule a follow-up. Use test records until access and data rules are understood.
Give sensitive changes the right review.
A security specialist focuses on permissions and server-side access checks. A data specialist examines imports, existing records and schema changes. A usability specialist considers whether users understand saving, validation and error recovery.
AI review is useful input, not a compliance certification. The actual rules for personal data and business access must come from the organization responsible for the tool.
Start with a narrow, verifiable CRM.
“Create a customer list and detail page with notes. Only signed-in team members can use it. A member can access only their assigned customers. Import five sample records and report invalid rows without losing the valid data.”
The brief gives coding and review a common set of outcomes. It also exposes where separate interface, data and authorization work needs to meet.
Grow through connected assignments.
Add pipeline stages, reminders or integrations as separate changes with updated acceptance criteria. Keep the current data and behavior in the context so a new feature does not quietly replace a working process.
For an existing CRM, begin with the repository, test setup and current decisions. A shared handoff is more useful than trying to reconstruct every old AI conversation.