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:

q. Automatic Updates Cease: Your store no longer receives automatic security patches or features from BigCommerce for that component.

1. Manual Maintenance Begins: Developers must manually track upstream changes, merge them with custom code, resolve conflicts, and redeploy.
2. Support Complexity: If a checkout issue arises, BigCommerce support may be limited because the code is no longer the “standard” version. 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:

JavaScript Injection for Minor Modifications

While I generally do not recommend it—because relying on client-side JavaScript is risky—there is an alternative approach for minor adjustments: injecting custom JavaScript directly into the native BigCommerce Checkout page, leveraging Mutation Observers and Event Listeners.

Remember, the functionality these apps provide is critical to ecommerce success. Introducing risk in this area can lead to instability and support challenges that compromise the reliability of the SaaS model.

The main risk of this approach is that it can break if BigCommerce changes the underlying page structure—though this is uncommon. It should be reserved for small, narrowly scoped changes. Ideally, all checkout customizations should be avoided, but when they cannot be, limiting their scope is the safest alternative.

Checkout Extensions (Beta)

Currently in beta, BigCommerce has introduced a new tool—Checkout Extensions—designed to introduce custom functionality into the checkout flow in a standardized, platform-supported manner.

Checkout Extensions allow developers to build an app that injects content into predefined regions of the Native One Page Checkout via a sandboxed iframe. This provides a “pluggable” architecture where custom logic can live inside the native experience without the need to fork the entire codebase.

The benefits:

• Preserves SaaS Benefits: Because it works with the Native One Page Checkout, you continue to receive automatic platform updates and security patches.
• Standardized Integration: Unlike JavaScript injection, which relies on targeting unstable HTML elements, Extensions use official BigCommerce APIs and designated UI regions.
• Reduced Risk: The sandboxed nature of the iframe provides a layer of security and prevents custom code from inadvertently breaking core checkout scripts.

The trade-offs:

• App Development Overhead: Using extensions requires developing and hosting a custom app to manage the extension’s logic.
• Contained Flexibility: You are limited to “predefined regions.” If your requirement involves changing the fundamental layout or core logic of the checkout (e.g., reordering the entire shipping/billing flow), an extension may not be sufficient.
• Beta Limitations: As a beta feature, documentation and available regions may still be evolving.

Checkout Extensions are the preferred path for adding functional blocks (like BOPIS [Buy Online, Pickup In-Store], gift wrapping options, loyalty point displays, or tipping options) while adhering to the “Don’t Customize Checkout” rule. It is a more robust and “elegant” solution than JavaScript injection, though it requires more upfront development effort.

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.