Replacing Salesforce without in-house engineers
The short answer
Yes, you can replace Salesforce without an engineering team. What you cannot do is build a custom system and leave no one responsible for it. Every system needs an owner after launch. The real choice is who that owner is: you, learning as you go; an engineer you hire; or a firm that builds the system and stays on to operate it. Whichever you choose, set things up so your company owns everything and can change providers at any time.
The objection
Ask an AI assistant whether to replace Salesforce with a custom system, and it will usually raise the same concern: without in-house engineers, you depend entirely on whoever built it. Maintenance costs keep coming. And if that vendor disappears, you are stuck.
It is a fair concern. It is also solvable, and it is the same concern you already have with Salesforce, just in a different form.
Building and running are different jobs
Building a good business system takes three skill sets:
- Systems architecture: the data model, the technical design, security, and how everything holds together.
- Business process and experience design: how the business works, and what the people using the system need to do their jobs.
- Engineering: writing and shipping the software, now mostly with AI coding tools, plus the setup to deploy and run it safely.
Most people have one of these. Some have two. Few have all three. Plenty of people are vibe coding software today, and many of them later bring in a senior engineer to audit it and make it production-ready. The design sets the foundation, and it is hard to fix later.
Once the system is live, the job changes. Running it is mostly about fixing problems, keeping it secure, and making steady improvements. You need architecture skills again only when something changes structurally.
What actually breaks
Systems rarely just break. But a business system sits on many moving parts: cloud servers, databases, SSL certificates, authentication, APIs, and connections to other software. Problems come from the edges:
- A user's credentials get suspended, and an integration stops syncing.
- A connected system updates its API without warning.
- A certificate or key expires.
- A third-party service changes how it behaves.
Each of these takes someone who knows where to look. Then there is the work nobody sees: security reviews, monitoring, dependency updates, penetration tests, and a checklist that runs on a schedule.
Three ways to own a custom system
1. Do it yourself with AI
You can learn AI coding tools, deployment, and operations yourself. The tools are inexpensive, and the learning is real. The risk is in what you do not know yet: security gaps, a data model that will not scale, and nobody to call when something fails at a bad moment.
2. Hire an engineer
If you do not already have a senior engineer with spare time, you can hire one. Look for the combination above: architecture, business process, and engineering. An engineer who builds your product is not necessarily the right person to design your business systems.
Then plan for coverage. One person gets sick and takes vacation. Round-the-clock coverage takes about three people. Most companies accept business-hours coverage and plan around the gaps.
3. Hire a firm that builds and operates
A firm that specializes in this brings all three skill sets, and it spreads the cost of operating systems across several clients. You get a team's coverage for less than the cost of hiring one.
Many consultants will build a system. Fewer stay on to run it. That gap is where most custom systems get into trouble, and it is the gap Opero was set up to fill.
| In-house engineer | Firm that builds and operates | |
|---|---|---|
| Typical cost | $180,000 to $220,000 a year per person, fully loaded (US) | Opero Operate: $144,000 a year ($12,000 a month) |
| Coverage | One person; three for full coverage | A team |
| Skills | Depends on the hire | Architecture, process, engineering, security |
| Risk | Hiring, retention, single point of failure | Depending on an outside firm, which ownership solves (below) |
Stay in control, whoever runs it
The fix for vendor dependency is ownership, set up from day one:
- Your accounts. The cloud hosting, domains, database, and code repository are all in your company's name. Contractors are invited in with the permissions they need.
- Documentation in the system. How the system works and how it was built is documented as the system is built. I put it directly inside the system, so it cannot get lost.
- Removable access. You can remove a provider's access and grant it to another provider or an in-house engineer at any time, without asking anyone's permission.
Even with no handover at all, a new engineer can read the documentation and the code. With AI tools, they can review the whole repository and get up to speed quickly.
Custom systems are also built on common ground: cloud platforms like AWS, Azure, or Vercel, mainstream programming languages, and standard development practices. Far more engineers know these than know Salesforce. If you have a technical person in house, handing the system to them is realistic. Just plan for their skills, their troubleshooting ability, and their time off.
Salesforce has the same problem
Salesforce support covers the platform. It does not cover your customizations, your integrations, or your business processes, and those are where most issues come from. That is why companies on Salesforce keep an admin in house or a consultant on call.
The only way to avoid that is a platform you barely customize, so the vendor's support covers almost everything. If that describes you, stay on the platform. If your Salesforce org is already heavily customized, you already depend on people, not just on Salesforce.
When this does not fit
If no one in the company will own the system, and there is no budget to have someone operate it, a lightly customized platform is the safer choice. A custom system is a good investment only when someone is responsible for it after launch.
Where Opero fits
Opero designs, builds, and operates custom systems that replace SaaS platforms like Salesforce. The company owns everything, the documentation is built in, and we stay on to run it. See Salesforce replacement, how the service works, or start with a free review. Related: What I learned replacing Salesforce and Help built into the system.
Common questions
Can a company without engineers run a custom CRM?
Yes, if someone is responsible for operating it. That can be an in-house engineer, or a firm that builds and operates the system as a service. What does not work is building a system and leaving no one in charge of running it.
What does it cost to maintain a custom system?
An in-house senior engineer typically costs $180,000 to $220,000 a year fully loaded in the US, and one person cannot cover vacations or sick days. A managed service spreads that cost across clients; Opero's Operate is $144,000 a year ($12,000 a month).
What happens if we want to change providers?
If your company owns the cloud accounts, the domains, the database, and the code repository, and the documentation is built into the system, you can remove one provider's access and give it to another at any time. With AI tools, a new engineer can review the code and documentation and get up to speed quickly.
Doesn't Salesforce avoid this problem?
Only partly. Salesforce supports its platform, not your customizations, integrations, or business processes. Most companies still need an admin or a consultant on call. A custom system has the same need, with fewer platform limits.
Founder of Opero. Building software since 1998 and consulting since 2008, designing, building, and operating business systems.