Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is how much of your Salesforce platform becomes custom software, and who maintains it. Code is the part of a Salesforce implementation that ages. Configuration moves with the platform when Salesforce ships a release; custom code has to be checked, and sometimes rewritten. Choose a development company that writes a lot of it without asking why, and you inherit a maintenance bill that grows every year.
Configuration first, custom code where it pays
A good Salesforce development company starts from configuration: standard objects, Flow for automation and the settings the platform already offers. It writes code, usually Apex on the server side and Lightning Web Components in the interface, when configuration cannot meet a requirement or would become too complex to maintain. That boundary is a judgement call, and the reasoning behind it should be written down.
The light case is a process that fits the standard data model with some automation. The heavy case is complex pricing logic, high-volume integrations or a custom interface for store staff. Both are legitimate. Paying developers to rebuild what Salesforce already ships is not, and it is a frequent source of technical debt, meaning work you have to redo later because of a shortcut now. Before you pick a developer, the broader questions in our guide on how to choose a Salesforce consultant are worth settling.
Integration is usually the hardest code
Connecting Salesforce to an enterprise resource planning (ERP) system, a warehouse system or a payment provider is where much of the custom development effort goes. The code has to handle errors, retries and data that arrives in the wrong order. Middleware such as MuleSoft helps in complex landscapes, and a direct connection can be enough for one or two systems. Our piece on choosing a Salesforce integration partner covers that choice.
When something breaks at the boundary, you need to know whether the fault sits in your code or in the platform. FORWARD has weekly calls with Salesforce product management, so a blocking platform bug reaches people who can act on it instead of waiting in a support queue.
Code you can own after the project
The code belongs to you, and so should everything around it. Ask for the source code in a repository your organisation controls, documentation that explains why each custom component exists, and a handover that a new team could pick up. Without that, switching supplier means paying someone to reverse-engineer your own platform.
Ownership also covers decisions. A short record of each design choice, with the alternative that was rejected, saves weeks when someone later asks why a component works the way it does.
Testing and releases decide the running cost
Salesforce ships three major releases a year, and each one can affect custom code. A development company should test in sandboxes, which are copies of your environment, before every release reaches production. Salesforce also requires automated tests covering at least 75 percent of Apex code before it can be deployed to production, but coverage alone proves little. Good tests check the business outcome, such as a discount calculated correctly.
Ask how releases move from development to production, who approves them and how a failed release is rolled back. The answers tell you more about running cost than any portfolio. Use the list below in the first technical conversation:
- How do you decide between configuration and code, and where is that decision recorded?
- Which automated tests run before each deployment, and who reviews the code?
- How do you prepare our custom code for each Salesforce release?
- What does the handover package contain if another team takes over?
