Building a Modern B2B E-Commerce Tech Stack
Most articles about building e-commerce software focus on B2C (business-to-consumer) settings. While B2C is widely written about, there are far fewer technical guides for developers in the $1.3 trillion B2B (business-to-business) e-commerce industry. B2B e-commerce is notably different from B2C retailing, and building software for this industry poses a unique set of challenges.
In this post, I’ll shed some light on building a modern, scalable B2B e-commerce platform. I’ll share some of the technical considerations you’ll make and architectural decisions you’ll encounter. Along the way, I’ll mention a few tools that will help you build B2B e-commerce software faster.
Technical Considerations for B2B E-Commerce
Traditionally, businesses have sold to other businesses through print catalogs or human-to-human sales processes, but with more companies favoring online purchasing, the norms are shifting. Software is handling more of the complex logic required to process and fulfill these orders.
Take for example Grainger. When I started my career in mechanical engineering, I kept a massive Grainger catalog at my desk to order new parts and replacements. Now, Grainger is aiming to make 80 percent of its sales online. Digital transformations like this are the norm, so if you’re in a company making B2B sales, you’re probably seeing similar trends.
For software engineers who are new to B2B e-commerce, a few things are worth noting. Before I get into the technical decisions you’ll need to make, keep the following factors in mind about your platform.
1. Payment and Pricing
In B2C e-commerce, customers typically all see the same price and make payments via credit card up front. In B2B e-commerce, each customer might have their own prices, payment terms, and catalog of available products. You may have to build custom contracts for some accounts or internal tooling for your sales team to manipulate discount rates for each customer.
This adds considerable complexity to the pricing and payment process, but it’s not something that can be ignored. This is one of the biggest reasons that typical B2C e-commerce platforms won’t work well in a B2B setting, and it’s a huge driver in the case for using a robust pricing engine like the one offered by Fabric.
2. Recurring Purchases
Most B2B buyers make the same purchases from the same vendors repeatedly for years, so your user experience should reflect this. Making customers dig through a huge list of previous orders or search your catalog to find their regular purchases results in a very poor experience, and makes customers think you don’t understand their needs.
From an analytics perspective, you should be able to track these recurring purchases. Retention of B2B customers is an important part of your e-commerce platform, and if you know what people are regularly buying, you can offer incentives and discounts to keep them coming back.
3. Product Customization
In some B2B settings, each product might be heavily customized for the customer. For example, you might allow customers to upload a logo to be printed on each item as Mallory does for its safety vests, or you might let them swap out subcomponents on each order. Because many B2B customers are ordering large batches, you might even custom build each product based on their specifications. On the backend, developers have to build tools to help their fulfillment teams understand these customizations and get the right products out on time.
Supporting this level of flexibility is challenging, and it’s one of the reasons that many businesses purchase a PIM (product information manager) rather than build their own from scratch.
4. Fulfillment and Shipping
In B2C e-commerce, customers typically place orders and select their preferred shipping method based on the cost and estimated time to deliver. In B2B e-commerce, shipping is rarely that simple.
Business buyers often negotiate bulk shipping rates or have all their orders shipped in batches each week to consolidate shipping costs. The specifics of these terms might be negotiated at the customer level, so smaller customers might use traditional shipping methods (UPS, DSL, or FedEx), while larger customers might use a third-party logistics company or have their own trucks.
These options need to be built into your B2B e-commerce platform. From tracking to reporting to handling returns, the complexity of B2B shipping makes fulfillment an especially interesting challenge to solve.
5. Multiple Decision-Makers
Finally, B2B purchases are rarely made by a single stakeholder, and the larger each purchase is, the more people will likely be involved. For developers, this means that your platform needs to allow company or organization-level accounts that can share lists, carts, and purchase histories. Features like this are rare in B2C e-commerce but essential for B2B.
“Adding to the complexity in B2B is not only multiple decision-makers, but the complicated matrix of B2B customer segments vs. transactional buyers. B2B personas can include variables defined by their contract and assortment/pricing, by compliance needs in their business sector (especially .gov customers) and other factors specific to the market in which you’re attempting to gain share. Many companies are realizing the monolithic ERPs they built to manage B2B in the 90s & 2000s can’t scale to provide the eCommerce needs of the 2020s.” – Stanley Harris, Sr. Agile Program Manager @ Staples
Architectural Decisions for B2B E-Commerce
Once you understand the constraints and requirements of your system, you can start to make some of the core architectural decisions. While I like the idea of YAGNI, in practice, some things need to be decided before you start building your software.
Here are some of the key technical decisions you need to make when building a B2B e-commerce experience. While it’s impossible to pick the “right” answer for every situation, I’ll offer some of my opinions based on my years leading software development teams.
1. Headless vs. Full-Stack
Until the mid-2010s, most web applications were built on full-stack, server-side frameworks. In the past few years, preferences have swung dramatically in favor of separated front and backends, often using a headless CMS or RESTful API. Headless e-commerce has some big advantages for certain B2B retailers, but it’s not right for everyone:
“As you expand beyond finding product market fit into a midmarket company, you must begin to do things like uniquely express your brand experience, add customer segments beyond your early adopters, add product selection, and start to add channels including retail, wholesale, third-party marketplaces, and more. Growing up is awesome, but you need to be really thoughtful to make sure your starter tech stack doesn’t limit your growth.” –Faisal Masud, CEO at Fabric
So if your development team is small and your B2B e-commerce experience is simple, you can probably skip the headless approach. On the other hand, if you’re scaling up your distribution channels, you want more control over the customer experience, or you want to improve performance dramatically, a headless e-commerce platform is the way to go. Among the many options available, Fabric is uniquely positioned to work with B2B retailers.
2. Microservices vs. Monolith
If you choose a headless approach, your next choice is whether to use a monolithic backend (perhaps a single API replicated to multiple data centers) or a service-oriented architecture that allows you to scale up parts of the backend individually. Microservices offer some definite advantages for larger B2B retailers. For example, Staples made the move to microservices in 2017 so it could decouple pieces of the backend and minimize third-party lock-in:
“We’ve over time moved to microservices for all of our key customer journey areas online and decoupled from the larger IBM WebSphere environment to having our own microservices for things like cart, checkout, and managing SKUs and payments and single sign-on. It gives us the flexibility to use it across multiple platforms because we can use it for our other properties, such as our sister properties in Canada and our commercial enterprise business.” –Staples Moves to Microservices and Cognitive Computing for Flexibility and Growth
On the other hand, microservices add a lot of complexity. You have to decide how to integrate them, pass data between them, manage the logs for each of them, and more. A service mesh can help, but even that means more code to run and maintain.
If you build your own microservices, expect to put a lot of developer hours into the effort. To get the scalability benefits without the time investment, you can use a third-party microservice provider like Fabric. You can use some or all of their e-commerce services to help you bridge the gap between building microservices from scratch and ensuring that your backend is reliable and scalable.
3. Data Model and Storage
After you decide on the approaches above, the next question is how you’ll store your B2B e-commerce data. Typically, relational databases like Postgres and MySQL have been most common in e-commerce, but the increased need for flexibility might make a NoSQL or hybrid approach an interesting option.
Once you decide on your primary database, modeling is the next step. While you’ll need to modify this structure for B2B e-commerce, you can start with the detailed data model here.
4. Programming Languages, Frameworks, and Libraries
Modern microservices are being written in almost every programming language, but Go, Java, and Node all seem to get the most attention. Opting for a widely used programming language typically makes it easier to hire developers, but they might not always offer the best performance. Rust, C++, and Fortran are all typically faster than the aforementioned languages, but they’re more difficult to work with.
Another factor in picking the best programming language for B2B e-commerce is the availability of useful frameworks and libraries. Starting a greenfield project with a framework that gives your application structure and established patterns can help new developers get up to speed more quickly. Similarly, if open source libraries already exist for your chosen language, you can cut down on development time when you need to integrate with third-party services or build common functionality.
5. Third-Party vs. In-House Platform
As you assess the factors above, another thread to keep in mind is how much of this software you want to build yourself.
Even if you have a software development team, building a robust B2B e-commerce platform is a lot of work, and the prevalence of specialized APIs as a service means that the argument for building everything in-house is much weaker than it used to be.
A best-of-both-worlds approach that I have used in the past involves building core “glue” code in-house and relying on third-party vendors for individual functionality that they are best equipped to provide. For example, you could use Fabric’s PIM and Order Management System, but handle the frontend development in-house. This lets you control the user interface while leveraging the power of a microservice-based headless platform that’s ready to use.
Conclusion
With the unique challenges that B2B e-commerce presents, it’s important to select or build a platform that’s especially designed to meet these challenges. Too many developers naively think that well-known B2C e-commerce platforms can be made to work for business-to-business. Avoid this trap by selecting partners and platforms that understand the pricing and payment options, multiple purchasers, product customization, and fulfillment requirements of B2B commerce.
Finally, consider a hybrid approach. Using a platform like Fabric as your headless backend gives you access to flexible, scalable microservices that you can easily integrate with your existing ERP, frontend, and back office systems.
Tech advocate and writer @ fabric. Previously CTO @ Graide Network.
Related Content
