BigCommerce offers an Open Source Checkout app and an Open Source B2B Buyer Portal app. By default, merchants benefit from a maintained and supported version of these apps, providing a robust out-of-the-box SaaS experience. However, both apps can be forked and customized to meet specific business requirements. This flexibility is powerful—but it comes at a cost.

The Value of SaaS

A key advantage of SaaS is reduced overhead. With the default versions of the Checkout app and Buyer Portal:

• The core platform “just works.”
• Security patches, bug fixes, and feature enhancements are delivered automatically.
• Merchants avoid ongoing development and maintenance efforts.

This reliability is achieved through standardization, where consistency across implementations enables seamless updates and vendor support.

The Trade-Off of Customization

Creating a custom (forked) version of one of these apps breaks that standardization. Once customized:

• Your store no longer receives automatic updates or security patches from BigCommerce.
• Developers must manually:
  • Track upstream changes
  • Merge them with custom code
  • Resolve conflicts
  • Redeploy the app
• The effort required for ongoing maintenance increases with the extent of customization.

As a result, custom apps require a recurring investment of developer time and attention, eroding the benefits of SaaS; in fact, BigCommerce even surfaces one such warning to this effect:

A Risky Alternative: JavaScript Injection for Minor Modifications

While we generally do not recommend it, because relying on client-side JavaScript is risky, there is an alternative approach for minor changes—injecting custom JavaScript directly into the native BigCommerce Checkout page.

Keep in mind, the functionality which these apps provide is essential to ecommerce success. Introducing risk into these areas can lead to instability and support challenges that undermine the reliability of the SaaS model.

When Customization Makes Sense

Given these trade-offs, customization—whether via a full fork or unsupported JavaScript—should be reserved for situations where the value clearly outweighs the cost:

• Significant changes to core functionality are needed
• Out-of-the-box features do not meet critical business requirements

If only minor modifications are necessary, it is typically not worth sacrificing the maintainability, security, and efficiency that come with the default SaaS solution.

Key Questions to Decide

Ask the following before committing to a custom implementation:

• Is this change critical for operations or revenue?
• Can it be achieved using supported APIs, themes, or styling?
• Are we prepared to commit developer resources indefinitely?
• What’s the cost of not customizing (e.g., lost sales, inefficiencies)?
• What is the possible impact of a worst-case-scenario; i.e. checkout failing due to unexpected compatibility issues? Help rework this (provide the results as markdown in a code block, so that it can be copied and pasted):

All or Nothing

While customizing the BigCommerce Open Source Checkout or B2B Buyer Portal can unlock powerful capabilities, it also introduces risk and complexity. For most merchants, the optimal balance of flexibility and reliability comes from leveraging SaaS benefits while using supported customization paths like styling, APIs, or extensions.

When evaluating whether to go custom, there is a clear inflection point. Using the native solution is cost effective and carries the least amount of risk, while any customization to these apps—no matter how small—increases both cost and risk. This tradeoff is particularly significant in checkout and the buyer portal, where sensitive user data and business-critical workflows are involved.

Because of this, checkout customization is often avoided through one of two strategies:

1. Making concessions in requirements (accepting reduced or altered functionality), or
2. Implementing workarounds earlier in the buyer journey, typically on or before the cart page, while leaving checkout untouched.

When requirements are modest, these approaches are usually the correct tradeoff—even when the result is a slightly suboptimal, yet acceptable, user experience.

However, some requirements simply cannot be satisfied this way. At a certain point, the need for a custom solution becomes unavoidable. Like a singularity in physics, the system behaves predictably (according to the the platform’s rules and constraints)—until this threshold is crossed. However, once the decision to customize Checkout (or the Buyer Portal) is made, the calculus changes. The assumptions that previously governed cost, risk, and flexibility no longer apply. At that moment, you’ve crossed the Rubicon. There is little value in continuing to contort the experience through pre-checkout or cart-level workarounds. Customization is no longer something to avoid or minimize; it becomes a tool to use deliberately. Once on the other side, customization unlocks broader and more meaningful possibilities, often enabling a more cohesive, intentional user experience than can be achieved through pre-checkout workarounds.

This creates an “all or nothing” decision:

• Optimize for lower cost and risk: accept platform constraints, make requirement concessions, and rely on workarounds.
• Optimize for capability and experience: accept the higher cost and risk of ownership, and design a fully custom experience without constraints.

My recommendation: Pursue custom solutions only when their business value outweighs the long-term cost of ownership and maintenance.