Blog

Should you custom build?

Off the shelf (OTS) or custom build?

We are often asked this question, with the expectation that it is a binary decision.
As with most projects, we do not need to define this as a black and white choice.
Instead we try to let the project requirements guide our recommendations, as each option will carry its own trade-offs in speed, cost, flexibility and control.

Let us explore our different options below:

Off the Shelf

Off the shelf can be a very powerful choice for problems that have already been solved, and should be considered when speed is a priority, or internal development resources are limited.
These solutions come with prebuilt functionality, documentation, support, and user interfaces.
They help teams avoid reinventing well solved problems.
This is not to say that OTS doesn't come with its own big risks.

Example: Salesforce

Salesforce is a popular OTS choice for sales and customer relationship management. Out of the box, it offers lead tracking, reporting, email integration, and automation. It’s a fast and proven option for teams that need structured CRM functionality, creating value almost instantly.

When you are solving non-unique problems and speed to market is a priority, Salesforce may be a very powerful option.

However, as companies grow and want more complex workflows or integrated data models, Salesforce can become a liability. Extending its functionality often requires engineers with Salesforce specific skills, which are more expensive and harder to hire than standard engineers.

The vendor lock-in risk is real too. Once customizations are built using Salesforce, migrating off the platform becomes costly and time consuming. Over time, subscription pricing can also rise significantly, especially as usage expands across departments. In many companies, what started as a departmental tool becomes a core operational system that’s difficult to replace or negotiate down, leading to what can feel like a hostage situation.

When to consider OTS

  • Common functionality such as authentication, content management, analytics, email delivery or payroll
  • Tight deadlines or limited internal development resources
  • Low to moderate total usage so subscription fees remain predictable
  • A need for compliance, backups and enterprise-grade reliability with minimal setup

Pros

  • Fast time to market
  • Lower initial cash outlay versus full development salaries
  • Access to proven integrations and community extensions

Cons

  • Vendor lock-in, where data models and customizations make it hard to migrate
  • Rising subscription costs as head count or usage grows
  • Limited ability to tailor workflows or user experiences beyond what the vendor offers

Custom Development

Custom development makes sense when your requirements are unique or strategic.
If the software you need is tightly linked to your competitive advantage, buying a general purpose solution may force painful trade-offs.

Building your own software gives you full control over behaviour, data models and user experience.
It lets you create proprietary algorithms and processes that competitors cannot easily replicate.

However, custom systems often require more resources than expected. Maintenance, upgrades, and documentation can mean a lasting burden. Budgeting only for the initial build ignores the real cost of ownership.

When to consider a custom build

  • Core features directly tied to competitive advantage
  • Unique workflows or specialised integrations that no product supports
  • High-volume usage where per-user or per-transaction fees would exceed development costs
  • A long horizon for maintaining and evolving the system

Pros

  • Exact fit to business requirements allowing you to deliver on your key differentiators
  • Freedom to redesign or pivot without vendor constraints or lock in
  • Potentially lower operating costs at larger scales

Cons

  • Large initial effort and potential ongoing maintenance
  • Unforeseen architectural debt and technical support burden
  • Engineering team(s) can be expensive

The Middle Ground

Taking us back to the start - these decisions do not need to be binary. In many cases, the best approach is a hybrid.
Rather than building everything yourself or relying entirely on 3rd parties, teams can assemble systems using modular custom built components, open-source tools, and OTS platform services.

One option is a buy-then-build model: start with OTS tools to accelerate progress, then gradually replace or extend them with custom development if required as your needs become clearer or more demanding.
This buy-then-build model avoids premature optimization. It lets teams validate assumptions, control burn rate early, and build only what delivers real long-term value.

Example: Salesforce

A company might adopt Salesforce for sales pipeline tracking to move quickly at launch. Over time, as internal workflows diverge from Salesforce’s model and licensing fees grow, they may extract specific modules (like lead scoring or reporting) into in-house services. This keeps them operational while maintaining control where it matters.

Options

  • Customize open-source tools. Starting with open-source software provides a working base and the flexibility to modify logic. It avoids vendor lock-in and accelerates development without starting from zero.
  • Build only the value adders. Use OTS tools for commodity features (e.g. payments, auth, dashboards) but write your own code for domain-specific logic or user experiences.
  • Use modular architecture, like the hexagonal pattern. Design systems in a way that components can be swapped. This lets you migrate from vendor tools to custom code (or vice versa) as your business evolves.
  • Adopt platform services. Use cloud infrastructure, APIs, and managed databases to reduce operational overhead while retaining control over your application logic.
  • Delay building until it matters. Start with an OTS solution, and switch to custom development once you understand the limitations and have a clear need.

Final Thoughts

You don’t have to choose only one path.

Build what makes your product valuable. Buy what doesn’t. Give yourself room to adjust. Most importantly, make your decision based not only on current needs, but on where your business is headed. The key is knowing when each approach is appropriate and revisiting the decision as you grow.

Author

Byron Cobb