The question that decides it
Not "can the platform do this" — it usually can, somehow. It is "is this process one the platform's model was designed for?" Fighting the model is what makes extensions expensive, and the cost arrives as maintenance rather than as a quote.
Every business reaches a point where the platform does not do what it needs. The choice at that point shapes the next five years of cost.
Three options, not two
| Option | Suits | Fails when |
|---|---|---|
| Configure within the platform | Requirement is close to the standard model | Configuration becomes a maze |
| Extend the platform | Requirement fits the model but needs custom logic | You are working around the model |
| Build alongside, integrated | The process is genuinely yours and central | You rebuild what the platform already does |
The middle option is where most teams should land, and the third is where teams go too early — usually because configuration was never properly attempted.
Signals for each
Extend when
- The platform's data model fits
- Users live in the platform already
- The requirement is a variation, not a departure
- The platform handles the hard parts
- Time to value matters
Build alongside when
- The process is your differentiator
- The data model genuinely does not fit
- You keep hitting platform limits
- Users are outside the platform
- Performance requirements exceed it
"Our process is unique" is true far less often than it is claimed. Most processes described as unique are a standard process with local vocabulary and a few genuine differences. Separating the real differences from the habits is the most valuable hour in this decision — and it usually shrinks the scope considerably.
The cost comparison people get wrong
| Cost | Extension | Custom build |
|---|---|---|
| Initial development | Lower | Higher |
| Authentication, permissions, audit | Inherited | You build it |
| Hosting and operations | Platform's problem | Yours |
| Platform upgrade compatibility | Ongoing effort | Not applicable |
| Working around the model | Compounds over time | Not applicable |
| Freedom to change direction | Constrained | Full |
Authentication, permissions, audit logging and operations are substantial engineering that extensions get for free. Underestimating them is the most common reason custom builds overrun.
The hybrid that usually wins
- The platform stays the system of record for standard entities — customers, orders, tickets.
- Your differentiated process runs in your own service, where it can evolve freely.
- A clean integration boundary between them, with one system owning each field.
- Users work in the platform where possible, with your capability surfaced inside it.
- The boundary is documented, so either side can be replaced without archaeology.
Keep the boundary clean from day one, whichever way you go. The teams who can extract a component in a defined project are the ones who drew a line early. The teams facing a rewrite are the ones whose custom logic grew tendrils into every corner of the platform configuration.
Deciding in a week
- Write the process down as it actually runs, not as documented.
- Mark each step as standard, local variation, or genuinely differentiated.
- Attempt the standard steps in configuration. Actually try it.
- Scope extension work for the variations.
- Consider a separate build only for the differentiated steps, if any survive step two.
- Cost all three over five years, including maintenance.
The warning sign that you chose wrong
If your team's conversations are consistently about how to make the platform accept something rather than about the business problem, the extension has outgrown its fit. That is a signal to extract the offending piece — not to add another workaround on top of the existing ones.
Facing this decision? Describe the process and where the platform resists it — we build both and will say which serves you. See our Salesforce and Zoho services, and over-customisation warning signs.