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, which can erode the cost benefits of SaaS.
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.
⚠️ Caution: BigCommerce’s documentation supports changes to styling, but discourages modifying the HTML or introducing functional changes via JavaScript. Such changes:
- Are unsupported by BigCommerce
- Introduce risks related to:
- Security and compliance
- Browser compatibility
- Page performance
- User experience
- Are vulnerable to breaking when BigCommerce updates the checkout code
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?
Bottom Line
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.
Create custom solutions only when the business impact of not doing so outweighs the lifetime cost of maintaining a forked app.