Last week, I used Claude to build a working CRM web application. Java backend, PostgreSQL database, React frontend. It has Leads, Accounts, Contacts, Opportunities, Quotes, Orders, Products, Pricebooks, line items. Lead qualification that auto-creates Account, Contact, and Opportunity. A dashboard with pipeline charts and an opportunity funnel. Custom entity creation. Custom fields of any type, including lookups.
I deployed it on a cloud VPS. It works. It was publicly accessible. I am not a developer. I have been a tester my entire career. Imagine what a few matured developers can build? Claude could build a working driver for a old model printer on MAC for someone in few hours!
Now, a reasonable person would look at this and say: "If a non-developer can build a CRM in 3 hours, why would anyone pay Salesforce lakhs of rupees per year?"
It is a fair question. Let me walk through why the answer is not what you think.
Think about a company like Apollo Tyres. They are a manufacturing company. They purchased Salesforce Manufacturing Cloud to manage their dealer network, order management, account planning, demand forecasting, and everything that ties their sales engine to their production floor.
Now imagine someone walks into their boardroom and says: "We can build this ourselves with AI. We will save crores annually."
Here is what actually happens in each scenario.
--
Scenario 1: Apollo Tyres builds it themselves
Their engineers know tyres. They know rubber compounds, tread patterns, curing processes, and dealer distribution networks. They do not know database schema migration strategies, OAuth token refresh flows, or how to handle a race condition when two sales reps update the same opportunity simultaneously.
So they hire 5-6 developers. The initial build goes well. The demo looks impressive. Management is thrilled.
Then month 4 arrives. A developer leaves. The replacement takes 6 weeks to understand the codebase. Meanwhile, the forecast module has a rounding error that is silently misattributing revenue across regions. Nobody notices until the CFO sees numbers that do not match the ERP.
Month 8. They need to integrate with their SAP system. Their ERP team says the API changed in the last upgrade. The CRM team says they were never told. There is no integration middleware, no event bus, no retry mechanism. Someone writes a cron job that runs every 15 minutes. It works until it does not.
Month 14. A security audit reveals that their custom authentication module has not been patched in 9 months. The PII of 30,000 dealer contacts is sitting behind a single API endpoint with no rate limiting.
The CTO is now spending 40% of their time managing a CRM project that was supposed to save money. Apollo Tyres is a tyre company. They are now also, unwillingly, a software company. Their institutional knowledge, their competitive edge, their decades of manufacturing wisdom - none of that helps them here. Every hour the CTO spends on CRM firefighting is an hour not spent on what actually makes Apollo Tyres money.
--
Scenario 2: Apollo Tyres hires a boutique software firm
This is the one that looks smart on paper. A 10-15 person company. Hungry, agile, affordable. They promise delivery in 3 months at a fraction of the Salesforce contract.
And they probably deliver something decent. The first version.
But here is the structural problem with small software firms: they are fragile.
Their lead architect gets poached by a bigger company. Their project manager goes on maternity leave and the replacement does not know the client's business process. Two key developers decide to start their own venture (because, as we established, everyone can now build software).
Worse, they have 5-6 other clients. When Apollo Tyres calls with an urgent production issue during quarter-end close, they are also fielding calls from 4 other clients with their own urgent issues. There is no bench strength. There is no escalation matrix. There is no SLA with teeth.
And then the real nightmare scenario: the firm folds. It happens more often than people admit. The founders disagree. The cash flow dries up. A key client does not pay. Suddenly Apollo Tyres has a mission-critical system with no one to maintain it, no documentation (or documentation that only made sense to the people who wrote it), and a codebase that a new vendor will need months to understand.
Apollo Tyres is now in worse shape than before. They have a system that sort of works, no one who fully understands it, and a quarter-end pipeline review in 2 weeks.
--
Scenario 3: Apollo Tyres hires a mid-size IT services company
This seems like the middle ground. A company with 200-500 people. Established, but not expensive like the big consulting firms.
The problem here is different. These companies survive on volume, not depth. They staff projects with whoever is available, not whoever is best. The architect who designed the system moves to another account after 3 months. The developers who replace them follow the documentation but do not truly understand the design decisions behind it. Why was this particular data model chosen? Why does this workflow have that specific exception handling? The answers left with the architect.
These firms also have their own institutional incentives. They bill by the hour or by the resource. Fixing things quickly is not in their financial interest. A problem that should take 2 days somehow takes 2 weeks. Not out of malice, but because their delivery model is optimized for utilization, not velocity.
And when something truly breaks - a data corruption issue, a failed migration, a compliance gap - they point to the scope document and say it was not covered. The change request process begins. By the time it is approved, scoped, staffed, and delivered, Apollo Tyres has already lost a quarter of clean data.
--
Scenario 4: Apollo Tyres stays with Salesforce
Here is what they actually get, beyond the software.
They get 25+ years of accumulated knowledge about how sales organizations actually work. Not how they should work in theory. How they actually work. The edge cases, the exceptions, the "but our process is different" scenarios that Salesforce has seen thousands of times across thousands of companies.
They get three releases a year, automatically. No migration projects. No weekend deployments. No rollback plans. Features just appear. Some are useful, some are not, but the platform moves forward without Apollo Tyres lifting a finger.
They get a security team that employs more people than most of their vendors have in total. SOC 2, ISO 27001, GDPR, HIPAA - not as checkboxes on a sales deck, but as continuously audited, continuously monitored compliance standards.
They get an ecosystem. 5000+ apps on AppExchange. When they need CPQ, they do not build it. When they need e-signatures, they do not build it. When they need marketing automation, they do not build it. They configure it. And if the first app does not fit, there are 4 others that might.
They get a consulting partner ecosystem. If their current SI is not performing, they switch. The new partner already knows Salesforce. The ramp-up is weeks, not months. The knowledge is in the platform, not locked inside one vendor's head.
They get a talent pool. There are over 4 million Salesforce professionals worldwide. When Apollo Tyres needs to hire a Salesforce admin or developer, they have candidates. When they need to hire someone who knows their custom-built Java/React CRM, they have no one.
Most importantly, they get to stay a tyre company. Their management does not have to understand why the nightly batch job failed. Their CTO does not have to arbitrate between the frontend team and the backend team about API contracts. Their CFO does not have to explain to the board why the "cost-saving" CRM project is now 3x over budget.
Salesforce is not just software. It is an institutional shock absorber. It absorbs the complexity of building, maintaining, securing, upgrading, integrating, and staffing enterprise software so that the customer can focus on what they actually do.
--
Now, back to my 3-hour CRM. (Actually, it took several more hours to reach a decent level, but initial AshishCRM was ready
It works. It genuinely works. And that is precisely the danger. Because it works well enough to fool someone into thinking the hard part is over.
The hard part was never building version 1. The hard part is version 1.1, and 1.2, and 2.0. The hard part is what happens when 200 users are on it simultaneously and the database locks up. When the audit team asks for a complete trail of every field change on every record for the last 3 years. When the European subsidiary says they need the system in German with GDPR-compliant data residency. When the CEO wants a board-ready forecast report by tomorrow morning and the data is spread across 4 systems.
The hard part is the next 10 years, not the first 3 hours.
AI is making it spectacularly easy to build software. And that is wonderful. It is democratizing creation in ways we have not seen before. But building software and running a business on software are fundamentally different activities. The first is a creative act. The second is an operational discipline.
Every enterprise software company - Salesforce, ServiceNow, SAP, Oracle - should look at what AI can build in 3 hours and feel more confident, not less. Because the gap between "I built a working prototype" and "I run my business on this" is where their entire value proposition lives. And that gap is not shrinking. If anything, as the ease of building V1 increases, the number of people who will discover the hard way that V1 is not enough will also increase. And they will come back to the platforms that were built to handle what comes after V1.
The moat was never the code. The moat was always everything around the code.
