What I learned replacing Salesforce with a custom system

The business

The client provides managed internet to MDUs, multi-dwelling units such as apartment buildings. The system needed to cover:

• Sales: new business, opportunities, contract renewals, and pipeline reporting
• Service: cases for residents and property managers
• A property manager portal to see buildings, units, and residents
• A tenant portal where residents manage their in-unit Wi-Fi
• Network integrations to monitor the network and provision personalized Wi-Fi networks and passwords for each unit

Building it on Salesforce first

Sales tracking and service cases were straightforward in Salesforce. The data model was not.

The business revolves around properties, units, and the residents who live in them. Building owners change over time. Property management companies manage buildings on the owners' behalf. Residents move between units and between properties.

Salesforce only emails Leads and Contacts natively. There are ways to email a custom field, but you lose standard email tracking and the activity history that Service Cloud depends on. So residents had to be Contacts. Contacts have to belong to an Account. I considered Person Accounts, which are clunky, and a placeholder account, which is worse. The workable answer was to make each property an Account, with residents as its Contacts, the building owner as the parent account, and a lookup to the property management company.

It worked, and record types and separate page layouts helped. But it meant the Accounts tab held building owners, management companies, vendors, and properties. Contacts were sometimes employees of a company and sometimes residents of a building. That is hard to explain, and everyone who uses the system has to learn it. Without a Salesforce background it feels awkward. The platform's design forced that model on the business.

The custom code piled up

Much of what made the system good was not configuration.

• Network status. On a unit, the team needed to see whether the gateway was online, whether the network chain above it was healthy, which devices were connected, and how much bandwidth was in use, and to take action from there. Standard page layouts could not do that, so I built custom Lightning Web Components. It solved the problem, but still inside the Salesforce layout.
• Move-ins and move-outs. Moving a resident in means matching an existing person, checking whether they live in another unit, checking for overlapping residency in the same unit, and closing out the previous resident. Flow could do it, but the result was clunky, so I wrote it in Apex.
• Portals. The property manager portal on Experience Cloud was clunky too. I rebuilt it outside Salesforce with custom code, integrated back to Salesforce, and the experience became cleaner and easier to understand. It also ended the licensing debate. A Customer Community Plus license is $15 per member per month, or $6 per login, and we spent real time trying to predict whether each customer would log in more than two or three times a month to pick the cheaper option. With a custom portal, every customer can be invited at no per-user cost.

Integrations hit the same wall. Salesforce has limits and an architecture you work around. Outside Salesforce, integrations can be built the way they should be.

Why replace it

As the system grew, more and more of it was custom code. I had seen how fast and well AI coding tools handled the Apex, the components, and the portals, and the roadmap held plenty more that would need code on Salesforce. At that point Salesforce was mostly adding license cost and constraints on top of a custom build.

The license math would have justified it on its own. The plan was about 30 Sales and Service Cloud users, 10 of them in a contact center, plus 30 portal users to start. At Salesforce's published prices, $175 per user per month for Enterprise, a $125 contact center add-on, and $15 per portal member, that is about $83,000 a year. The company planned to roll the system out to other business units: about 100 Salesforce users and hundreds of portal users, well over $200,000 a year in licenses alone.

And with the business already understood and AI coding tools this capable, the question became: why not build the system the business actually needs?

How the replacement was done

Design: one to two weeks. The discovery was already done, because I had built the business on Salesforce. I used the existing data model, configuration, metadata, and code repository as the starting point, and defined the changes: properties, residents, building owners, and property management companies as their own entities, with vendors as general accounts. The client already ran on Microsoft, so the system is built on Azure in their own tenant. For a company starting from a system someone else built, I would budget one to two months of design.

Build: three to four weeks. Claude Code wrote the system and configured Azure. It can read the Salesforce repository, and if you choose, Salesforce itself through a read-only user. Most of the time goes to the volume of code, the roadblocks that come up, and the decisions that need a human. I would budget a month.

Testing. Most of the testing is automated. Playwright runs browser-based tests against every test case through GitHub, and manual testing confirms the results at the end. For a brand-new system with nothing live yet, you can deploy straight to production and test there. Once it is live, you move to proper environments: develop in a sandbox, test in staging, deploy to production, and roll back if needed.

Data migration, twice.

1. Create the users and run a first migration of current data.
2. Train and onboard users on real data. Confirm their access and that they can see and do everything they need.
3. Pick a cutover date. Set Salesforce to read only and run the final migration.
4. Users go live on the new system. They can still look things up in Salesforce, but not change anything.
5. After one to three months, take a final backup and cancel the licenses or let them lapse at renewal.

AI does most of the migration work: mapping old objects to the new model and reconciling record counts and values. I used to verify migrations by hand with totals and side-by-side list views. Now I spot check.

What got better

• A data model that matches the business. Properties, residents, owners, and management companies are each their own thing. Navigation makes sense without training on Salesforce conventions.
• Speed. Salesforce is multi-tenant: every customer shares the same platform, and your objects and fields are configuration stored in it. A custom system has a real database built for one company. It is faster and cleaner, and the interface is noticeably snappier.
• The interface. If something should look or work a certain way, you build it that way. No workarounds, and no accepting the platform's way of doing it.
• Help built in. The documentation was written alongside the system. A help icon on every page shows articles relevant to where you are, and covers both how to use the system and how the business process works. Salesforce documents Salesforce, not your company.
• Permissions around real work. Roles and permissions are defined around the actual functions of the business, not configured through a huge platform built for everyone.
• No per-user licenses for staff or portal users.

The admin interface becomes AI

This was the biggest shift in how I think about it. Salesforce is built for point-and-click configuration, and anything that could not be clicked was done in code. Even on Salesforce, I now do the point-and-click work with Claude Code: objects, fields, permission sets, page layouts, reports, and dashboards. It is faster and more accurate than the setup screens, where renaming or deleting a field can take half an hour.

That changes what a custom system needs. You do not need to rebuild Salesforce's setup screens. New fields, reports, validation rules, workflows, list views, and layout changes are made by an AI coding tool working in the code repository. The admin interface is a conversation.

What I would tell a CEO considering this

• Count the full license bill at the size you plan to be, including portals and contact center seats. If you already spend hundreds of thousands a year, the savings alone can justify the move.
• Look at how much of your Salesforce system is already custom code. If the answer is a lot, you are paying licenses for a platform that is mostly getting in the way.
• The build is no longer the hard part. The design is: the data model, the processes, and the experience for your staff and customers.
• Plan the cutover carefully: two migrations, training on real data, and Salesforce read only for a while.
• Decide who runs it afterward. Monitoring, security, backups, and changes still need an owner.

Everything was easier than I expected.

Where Opero fits

Opero designs, builds, and operates custom systems that replace SaaS platforms like Salesforce. See Salesforce replacement and custom systems for telecom, ISPs, and MDU providers, or start with a free review.