Building a Role-Based CRM From Scratch: What I'd Do Differently
The permission model is the one decision you cannot afford to get wrong late - lessons from building Cleano CRM.
When I started building Cleano CRM, a role-based system for an agency managing payroll, assets, and multiple clients, the temptation was to start with the features: dashboards, a payroll module, a client list. Features are visible progress, and visible progress feels good early in a project.
I didn't do that, and it's the single decision I'd repeat first if I started over.
Permissions First, Features Second
Instead, I built the access control layer before anything else — a system where every role (junior staff, manager, admin) has an explicit, enforced view of what they can see and do. It felt slow at first. There was no dashboard to show anyone for the first stretch of work.
But every feature built after that point inherited the permission system for free. The payroll module didn't need its own access logic — it asked the same permission layer everything else did. The social content calendar, the asset tracker, the multi-client project views — all of it plugged into one source of truth for "can this user do this."
What Retrofitting Would Have Cost
I've seen the alternative on other projects: build the features first, then try to bolt on role-based access once someone notices junior staff can see manager-only data. That's not a quick fix — it usually means touching every screen, every API route, and every query that assumed a single flat user type.
The lesson generalizes beyond permissions. Any cross-cutting concern - logging, auditing, multi-tenancy - is cheap to add at the foundation and expensive to retrofit. If a requirement is going to touch everything, build it before you build the things it touches.
What I'd Still Change
The access layer saved me later, but I was too conservative about activity logging early on - I added it as an afterthought once security review asked for an audit trail. It should have shipped in the same pass as permissions themselves, since they're really the same concern: not just "what can this user do" but "what did this user do."
Next time, that's the first two things I build, not the first and the fourth.