Claude Can Build You a CRM. That Does Not Mean You Should Use It.
By Michael MacfarlaneClaude can build something that looks like a CRM remarkably quickly.
Give it a weekend and the right prompts, and you could have:
- A login page
- A contact database
- A visual sales pipeline
- Notes and tasks
- User accounts
- A reporting dashboard
- Email templates
- Some basic automation
- A modern interface
You click around.
It looks impressive.
You start thinking about how much money you have saved by avoiding an established CRM platform or professional development company.
Then real people start using it.
Two users update the same customer.
Somebody accidentally deletes a record.
An email integration stops working.
A form creates duplicate contacts.
Permissions expose information to the wrong employee.
A software dependency develops a security vulnerability.
Your backup exists, but nobody has ever tested whether it can actually be restored.
A customer asks you to export or delete all their personal information.
The developer who helped finish the project is busy with something else.
At that point, you have not saved money on a CRM.
You have accidentally started a software company.
And when something goes wrong, nobody else owns the problem.
You do.
Claude is not the problem
Claude is an extremely capable tool.
It can help developers:
- Write code
- Explain unfamiliar code
- Create database structures
- Design interfaces
- Fix bugs
- Build integrations
- Produce tests
- Refactor applications
- Create prototypes
The same applies to other AI coding tools.
They have made software development faster and more accessible.
But faster software development is not the same as reliable software ownership.
Even Anthropic’s own security guidance says users are responsible for reviewing proposed code and commands for safety.
Claude can help build the CRM.
Claude does not become your permanent development, security, compliance, infrastructure and support team after launch.
That distinction matters.
A working demo is not a production CRM
The first version is the easy part.
A contact list and sales pipeline can be created relatively quickly.
The difficult part begins when the CRM becomes responsible for real business operations.
A production CRM may hold:
- Customer names
- Email addresses
- Phone numbers
- Sales conversations
- Contracts
- Payment information
- Call recordings
- Appointment details
- Internal notes
- Marketing preferences
- Customer service history
- Commercially sensitive information
It may also control:
- Automated emails
- Text messages
- Phone calls
- Sales tasks
- Appointment reminders
- Pipeline movement
- Lead assignment
- Reporting
- Website forms
- Advertising attribution
- Customer notifications
That is not a side project.
It is business infrastructure.
If the CRM stops working, parts of the business may stop working with it.
The interface is only a fraction of the system
AI coding tools are very good at producing visible results.
A polished dashboard feels like progress because you can see it.
But most of the difficult CRM work happens underneath the interface.
You need to consider:
- Database architecture
- User permissions
- Data encryption
- Authentication
- Audit logs
- Backups
- Recovery procedures
- API security
- Webhook reliability
- Email deliverability
- Duplicate management
- Data retention
- Rate limits
- Error handling
- Monitoring
- System performance
- Software dependencies
- Testing
- Deployment
- Security patches
The visible pipeline might take a day to create.
Making sure it behaves properly for several years is the real project.
Who monitors it when nobody is looking?
Software does not only break when somebody is actively changing it.
External services change.
APIs release new versions.
Access tokens expire.
Email providers update authentication requirements.
Browsers change how they handle security.
Dependencies become outdated.
Operating systems and hosting environments receive updates.
Attackers discover new vulnerabilities.
A custom CRM requires someone to monitor:
- Failed processes
- Server health
- Database performance
- Integration errors
- Security warnings
- Login attempts
- Workflow failures
- Email delivery
- Backup completion
- Storage limits
- Application logs
If nobody is actively watching, bugs can continue unnoticed.
A form may stop creating contacts on Friday and nobody realizes until Tuesday.
A workflow may send the wrong email for two weeks.
An integration may quietly fail while the team assumes there are simply fewer leads.
The cost is not only fixing the bug.
It is the opportunities lost before anybody discovered it.
AI can fix a bug. It cannot take responsibility for one.
When a custom CRM fails, somebody needs to:
- Notice the problem.
- Understand the effect on the business.
- Reproduce the issue.
- Find the cause.
- Develop a fix.
- Test the fix.
- Deploy it safely.
- Confirm no data was damaged.
- Check whether customers were affected.
- Prevent the same issue happening again.
Claude can help with several of those steps.
But somebody still needs the technical knowledge to direct, review and approve the work.
If you do not have developers available, every serious problem becomes an emergency search for somebody who understands a system they did not build.
That is not a reliable operating model.
Your CRM will not automatically be compliant
A CRM holding personal information must be designed around data protection from the beginning.
Compliance is not something you add at the end by asking Claude:
“Make this GDPR compliant.”
The UK GDPR requires organizations to consider data protection at the design stage and throughout the system’s lifecycle.
That can include:
- Data minimization
- Purpose limitation
- Access control
- Retention periods
- Secure processing
- Data exports
- Deletion processes
- Consent records
- Marketing preferences
- Audit trails
- Subprocessor management
- International transfers
- Incident response
- Data subject rights
The Information Commissioner’s Office describes this as data protection by design and by default.
An AI-generated application is not compliant simply because the code works.
You need to understand:
- Which personal information is collected
- Why it is collected
- Where it is stored
- Who can access it
- Which providers receive it
- How long it is retained
- How it can be corrected, exported or deleted
- What happens if the system is compromised
If your custom CRM gets this wrong, your business remains responsible.
Security cannot be solved with one prompt
A basic login page is not a complete security system.
A production CRM may need:
- Strong authentication
- Password security
- Multifactor authentication
- Session management
- Role-based permissions
- Encryption
- Secure password recovery
- Protection against common attacks
- Logging
- Vulnerability management
- Secure development practices
- Incident procedures
- Regular testing
The UK National Cyber Security Centre recommends a secure development lifecycle where security is considered from design through deployment and ongoing operation.
This is continuous work.
Software dependencies also need attention.
A package that was safe when the CRM launched may later develop a known vulnerability. Someone must identify it, assess the effect, test an update and deploy the fix.
Claude can help review code.
It does not remove the need for security ownership.
Permissions become complicated quickly
At first, a custom CRM may only have two users.
Both are administrators.
Everything seems simple.
Then the business grows.
Salespeople should only see their own opportunities.
Managers should see team performance.
Finance needs access to billing but not private customer notes.
External contractors need temporary access.
Administrators need to control users without viewing sensitive information unnecessarily.
Some records need restricted access.
Former employees need to be removed immediately.
This requires a properly designed permission system.
One mistake can expose customer information to the wrong person.
Permissions are one of the areas where a simple prototype often starts falling apart under real business use.
Data integrity problems are expensive
A CRM is supposed to become the business’s source of truth.
That only works if the data can be trusted.
Custom systems need to handle:
- Duplicate contacts
- Merged records
- Simultaneous edits
- Import errors
- Field validation
- Accidental deletion
- Partial form submissions
- Failed integrations
- Incorrect pipeline movement
- Time zone differences
- Historical changes
- Conflicting customer information
What happens if two employees edit the same record?
What happens if an import contains 50,000 contacts?
What happens if a workflow runs twice?
What happens if a customer has two email addresses?
What happens if a record is deleted accidentally?
What happens if an integration sends incomplete data?
These situations are not exciting to build.
They are still essential.
Backups are worthless until restoration is tested
Many custom systems claim to have backups.
That sounds reassuring.
But several questions still need answered:
- How often are backups created?
- Where are they stored?
- Are they encrypted?
- Can one customer be restored?
- Can the entire database be restored?
- How long would restoration take?
- Who is responsible for doing it?
- Has the process ever been tested?
- What happens to information created after the latest backup?
A backup that cannot be restored is not a backup.
It is a comforting idea.
Established software providers normally invest in resilience, redundancy and recovery processes because thousands of customers depend on the service.
When you build your own CRM, that responsibility becomes yours.
Integrations do not stay finished
Your CRM will probably connect to other services.
That could include:
- Email providers
- Phone systems
- Text messaging
- Payment processors
- Calendars
- Advertising platforms
- Website forms
- Accounting software
- Data providers
- Automation platforms
Every integration creates another point of failure.
Providers change APIs.
Permissions change.
Tokens expire.
Webhook formats change.
Rate limits are introduced.
Features are removed.
Authentication standards are updated.
The integration that works today may need maintenance six months from now.
Established CRM providers have a commercial reason to keep major integrations working.
With a custom CRM, you need somebody to notice the change and update the system.
Communication compliance is more complicated than it looks
Adding a “Send Email” or “Send Text” button is easy.
Managing business communications responsibly is not.
You may need to handle:
- Consent
- Opt-outs
- Suppression lists
- Unsubscribe links
- Sender identification
- Message history
- Quiet hours
- Country-specific rules
- Carrier requirements
- Number registration
- Failed delivery
- Spam complaints
- Email authentication
- Reputation monitoring
If your custom CRM sends the wrong message to the wrong person, the customer does not blame Claude.
They blame your company.
If a carrier blocks your number, Claude does not contact the provider.
Your team does.
If an email domain develops a poor reputation, the custom CRM does not automatically repair it.
Somebody needs to understand what happened.
You become responsible for every feature request
Once employees start using the CRM, they will want changes.
Can we add another pipeline?
Can we report by salesperson?
Can we change how commissions are calculated?
Can we add call recording?
Can we connect WhatsApp?
Can we build a mobile app?
Can customers access their own records?
Can managers approve discounts?
Can we export this report?
Can we add AI summaries?
Can we automate reviews?
Can we create a booking calendar?
Every request becomes another development project.
Every new feature can also affect the existing system.
A change to contact records may break reporting.
A new pipeline rule may trigger workflows incorrectly.
A new permission may expose information.
A new integration may create duplicates.
Software development never really finishes.
Established CRM platforms improve while you sleep
A proper CRM company is not only selling the version that exists today.
It is maintaining and improving the platform continuously.
Its teams may be working on:
- Security updates
- Performance
- New integrations
- Mobile applications
- Reporting
- Automation
- AI features
- Communication tools
- Compliance controls
- User experience
- Documentation
- Infrastructure
- Bug fixes
The provider receives feedback from many customers.
A bug found by one business can be fixed for everyone.
A new integration can become available without every customer building it independently.
A security patch can be applied across the platform.
When you build a custom CRM, you receive none of that shared improvement unless you pay someone to create it.
Your system only improves when you invest more time and money into it.
The hidden cost is not the initial build
The custom CRM might appear inexpensive at the beginning.
Claude produces a large amount of code quickly.
Hosting looks cheap.
The first version works.
The real cost appears later through:
- Developer time
- Bug fixing
- Security reviews
- Hosting management
- Monitoring
- Testing
- Backups
- Integration maintenance
- Compliance work
- Staff training
- Documentation
- Feature development
- Data migration
- Emergency support
You also need to include the cost of your own time.
Every hour spent managing custom software is an hour not spent selling, delivering or improving the actual business.
The cheapest CRM is not the one with the lowest monthly fee.
It is the one that provides the required outcome with the lowest total operational cost and risk.
You create key-person risk
Custom systems are often understood by one person.
That might be:
- The employee who prompted Claude
- A freelance developer
- A technical founder
- A small external agency
What happens when that person leaves?
Does anyone else understand:
- The database
- The hosting
- The integrations
- The deployment process
- The security controls
- The backup system
- The codebase
- The business logic
If the answer is no, the company has built a critical system around one person’s availability.
That is a serious operational risk.
The business becomes trapped by its own software
Companies often build a custom CRM because they want complete control.
Several years later, that control can become a trap.
The system is too important to abandon but too outdated to improve easily.
Integrations have been added without a consistent plan.
Different developers have used different approaches.
Documentation is incomplete.
Nobody wants to change a critical feature because they do not know what else might break.
Moving to another platform becomes expensive because the data structure is unique.
Custom software can remove vendor lock-in and replace it with codebase lock-in.
When does building a custom CRM make sense?
There are situations where a custom CRM can be the right decision.
It may make sense when:
- The workflow is genuinely unique
- The CRM itself creates a competitive advantage
- Existing platforms cannot support a critical requirement
- The business has an experienced internal development team
- Security and compliance expertise are available
- The company can fund continuous development
- There is a clear product owner
- Monitoring and support are properly resourced
- The long-term economics justify the investment
In other words, building a custom CRM can make sense when the company deliberately wants to operate software as part of its core business.
It makes less sense when somebody simply wants a nicer pipeline or a few custom automations.
The smarter approach is to customize an established platform
Most businesses do not need a custom CRM.
They need an established CRM customized around their process.
There is a major difference.
Building a custom CRM means owning:
- The code
- The infrastructure
- The security
- The maintenance
- The integrations
- The bugs
- The roadmap
- The support
Customizing an established CRM means configuring:
- Pipelines
- Fields
- Workflows
- Forms
- Calendars
- Dashboards
- Permissions
- Messages
- Automations
- Integrations
- AI tools
You receive the flexibility without rebuilding the basic software infrastructure.
Customize the business process.
Do not rebuild the plumbing unless the plumbing is your business.
Where Claude is genuinely useful
Claude can still play an important role.
Use it to:
- Design CRM processes
- Plan automations
- Create custom integrations
- Write internal documentation
- Develop reporting logic
- Build controlled extensions
- Produce data migration scripts
- Create custom front-end tools
- Review workflow logic
- Help developers work faster
The strongest approach is often combining AI development with an established platform.
The CRM handles the proven foundation.
Claude helps create the specific pieces that make the system fit your business.
That is very different from asking Claude to become the entire CRM.
Frequently asked questions
Can Claude build a custom CRM?
Yes. Claude can generate code, database structures, interfaces and integrations that form part of a CRM.
However, building the first version is only one part of running production software. The system still requires technical review, testing, security, monitoring, backups, maintenance and support.
Is a custom CRM cheaper than paying for software?
It may be cheaper to create the first prototype.
It is rarely sensible to compare only the initial build with a monthly software subscription.
The proper comparison must include ongoing development, hosting, maintenance, security, compliance, monitoring, integrations and internal management time.
Is an AI-generated CRM GDPR compliant?
Not automatically.
Compliance depends on how the system is designed, hosted, secured and operated throughout its lifecycle.
A prompt cannot replace a proper assessment of data flows, lawful purposes, access, retention, security and individual rights.
Is using Claude for software development unsafe?
Not inherently.
Claude can be a powerful development tool when its work is reviewed, tested and deployed through a suitable software development process.
The danger is treating generated code as automatically safe or production ready.
What is the best alternative to building a custom CRM?
For most businesses, the better option is an established CRM platform configured around their sales, marketing, service and operational processes.
Custom development can then be used selectively where it creates genuine value.
Do not build another problem while trying to solve one
The appeal of building a custom CRM with Claude is obvious.
You can move quickly.
You can create something that looks exactly how you want.
You avoid another monthly software subscription.
You feel in control.
But the moment the CRM stores customer information and supports daily operations, it becomes a serious responsibility.
If nobody is monitoring it, maintaining it and improving it, the system will eventually create more problems than it solves.
Claude can help you write the code.
It cannot own the outcome.
Build on a platform designed to keep improving
Gateway CRM gives businesses a configurable platform for customer management, pipelines, communication, calendars, forms, automation, reporting and AI.
It can be customized around how your business operates without making your company responsible for maintaining an entire CRM codebase.
You get the flexibility of a tailored system while continuing to benefit from ongoing platform development and new capabilities.
Use custom development where it gives your business an advantage.
Use an established CRM for the infrastructure that should simply work.