Buy vs. build has been debated in the B2B industry for many years. While buying an ecommerce platform is often faster and more affordable, many platforms may not be able to meet the complex needs of B2B. Some organizations opt to build their own platform, investing the time, talent, and financial resources necessary not only to build but keep it operating and improving.
But as technology evolves, so has this debate. Operations within a B2B organization are often extremely complex. These organizations need to differentiate in order to compete, but they also need to be efficient.
We recently sat down with Aaron Sheehan, OroCommerce’s Vice President of Strategy and Partnerships, to talk about how B2B ecommerce leaders are thinking about the buy vs. build debate today.
Joe Albrect, Xngage CEO and Managing Partner: Aaron, what is your take on this topic: Build vs. buy?
Aaron Sheehan: It’s a conversation that has been going on for a very long time. It happens outside of ecommerce, as well. But it’s always a hot topic. Generally, there are lots of reasons why a company might want to build. There are a lot of good reasons why a company might want to buy. I think that the question I always lead with when I’m speaking to a manufacturer or distributor is: Are you an IT company or are you prepared to be an IT company? Because if you decide on building from scratch, you have become an IT company. And that is not a bad decision, it is not a good decision – it is a decision. But it is a decision that comes with consequences that need to be thoroughly looked at, as are the consequences of buying something off the shelf.
Joe: I picked up on “from scratch.” Rarely have I seen organizations choosing to build an ecommerce solution from scratch. Although, ten years ago, I have worked with companies that have built in house simply due to the fact that B2B sales processes are very different from consumer platforms, and at the time, there weren’t so many tools around. So, in the past, I’ve seen several clients having a team in house – not necessarily a full software organization, but larger distributors, enterprises, have built their own solutions. I know one client of mine where the CEO himself coded up the entire ERP system and also the ecommerce bolt-on that they had. And yes, we often came in to re-platform as the platforms became more available in the market, and obviously OroCommerce was around as one of the leading B2B ecommerce platforms in the market.
Aaron, as you pointed out, having a team, a software organization, being a software company is a very different thing and different undertaking than being a distributor or a manufacturer. So, what are some other aspects where it makes sense to strategically build?
Aaron: So, what is involved in building your own? You mentioned employing a team of developers – that’s correct, but there’s also a platform mindset that you have to bring to it: security, infrastructure, QA, roadmap ownership. One of the things I have seen is many times when companies do decide to build their own is it often starts from the ERP and then unfolds outward into various portals and tools. One of the things that happens is that the ability of that team to deploy features or improvements or bug fixes becomes very tethered to the ERP itself. So, that means that the same team that’s writing a report for an end-of-quarter financial report is the same that has to deploy an update to the security model or a new feature. You end up with a lot of the natural tension that you have at any software company between: Am I dialing between compliance and safety? Am I dialing towards daily internal operations? Am I dialing towards customer service?
And one of the things I have repeatedly seen from this is that the customer is the one person who’s not in the room when you’re doing your spring meeting. So, your CFO is in the room; your COO is in the room; your senior VP is in the room. The customer is not. And often you find that what they need is hard to prioritize because there is no stakeholder in that conversation.
One reason why you would buy instead of build is that you are buying your roadmap from that vendor. So, the improvements to the customer experience, the improvements to your back office, they come to you with you having to de-prioritize something that your operations or finance team needs to have done. And so, it’s a great way to continue getting forward velocity and to evolve your offering without having to continually tweak your resourcing.
Joe: I like that idea of buying a roadmap – so important. I think you’re buying the stack – the technology – the hosting model, and you’re buying into a roadmap of the vendor. These are the three big ingredients. To me, often, this is over-looked in platform selection approaches because it’s all focused on: do we have that feature or this feature? But it’s really these three components that at the end make it the right choice or the right fit because you do still have to still integrate and tailor the platform if you buy into your own organization and adjust it to your business needs. You do have a hosting solution, ideally, offered by that vendor, but if it isn’t allowing you to customize on top of it, it’s going to become problematic. And if you are not pairing with a vendor that has a strong roadmap, what are you buying into, right?
But I want to ask you directly, since you’re with OroCommerce, how do you guys balance building something that is turnkey and provides a lot of functionality but, at the same token, provides flexibility to be adjusted and tailored to individual business needs on both the platform side as well as the hosting model?
Aaron: That’s a really great question. OroCommerce is an open-sourced ecommerce platform and was built by the team that originally gave us Magento, which I know we have both spent some time in. One of the great things about open-source platforms is that they provide a full platform with features, but they also provide the scaffolding to extend and customize those platforms. So, our approach has always been to focus on the needs of B2B companies, companies who sell to other companies: manufacturers, distributors and wholesalers, and to create out-of-the-box features that work for them. We’re not trying to build an ecommerce platform for every possible use case and every possible business model. Competition is good and healthy, and there are platforms out there that focus on direct-to-consumer or drop-shipping models that do a great job. But B2B is often very complicated and needs certain architectural decisions made – like decoupling price lists from product data – that are often not true in a B2C context. And so, I would say: focusing on B2B, building it in an open-source way so that it can be safely and securely extended to customize to meet a particular customer’s commerce logic or business logic. And finally, securely hosting it when needed in a single-tenant SaaS model that gives the customer complete control over the file system and database and extensions, but also takes a lot of the infrastructure and security model and becomes that we deliver in a SaaS model to our customers, so that my customers do not have to become infrastructure experts on how to build and host an ecommerce platform – because that’s often a very different proposition that what you might be doing with your internal ERP or WMS systems.
Joe: For the audience, help them understand the key difference between a single-tenant SaaS vs. a SaaS platform that are multi-tenant. What are the big differences and maybe the limitations or the pros and cons?
Aaron: Of course. A multi-tenant SaaS platform is one where all of the customers are effectively on the same server or set of servers which often means they are sharing the same codebase. So, everybody gets the same features, everybody gets the same bugs, and everybody gets the same experience. Everyone’s customers get the same experience, and everyone’s buyers and sellers get the same experience.
If you think of it like: if you open up your browser window and go to Gmail – fundamentally, Gmail is a SaaS app. I got to Gmail, I access it through my browser, and I get the same experience, Joe, that you have. For better and for worse, we get the same exact features, we get the same bugs, and we get the same user logic. The good thing about multi-tenant SaaS is that you never have to upgrade the actual application itself – that is a service that is provided to you by the vendor – and so you are completely hands-off the wheel. It shows up on your computer screen, you use it, and then you close it. The value proposition is: you get it, you get it quick, and you never have to think about anything.
The downside to that model is that your hands are off the wheel which means that you don’t have control over the roadmap. You don’t have control over what is being built and delivered. And you are completely, I would say, “at the mercy,” – that sounds negative – but you are beholden to your vendor’s vision of where they think the market is going and what they think the right experiences are for your customers. Sometimes in a niche and focused platform, they have a strong opinion on what direct-to-consumer commerce looks like, what that full ecosystem of apps and experiences look like. And what you’re buying is not so much software as it is a point of view. And if you agree with that point of view, and you think that point of view will evolve with you and always be true, it is an excellent way to get value if what that vendor is offering you maps exactly to what you need. That is a great thing to have.
Obviously, Oro offers both on-premise and single-tenancy cloud model. That is for customers that want to host their own or want to have their own dedicated, isolated instance with full control. When you have full control, you can build the experience that works for your business, your customers, your users, your back office. But that comes with responsibility. Now, you have to think about customizations; you have to think about upgrades; you have to think about integrations. Those are all healthy things for a mature business to own, in my opinion. If this is foundational to your retention and to your revenue growth, these are things you should be responsible for, in my opinion. But the downside is that there is slightly higher costs sometimes in owning and operating a single-tenant or on-premise model.
So, instead of renting a house with someone else’s furniture, you buy a house and put your own furniture in it. And there’s lots of hybrid models in between there. But fundamentally, multi-tenancy is leasing a home and the couch and the dining room table and the chairs, and building is buying a home yourself and putting what you want in it. More money, but more control.
Joe: And I would just say, after doing more than 70 implementations over the last 10 years, we have been working exclusively with the single-tenant model, which OroCommerce has. In B2B, it’s almost impossible to get away with buying into the mindset and the vision of someone, like you said. You have to adjust to the business realities. You have to integrate with bespoke ERP systems. This piece alone in a multi-tenant SaaS model means the only way to do this is through APIs. And that’s not always an efficient way to do it, number one. Number two, when you want to customize anything in these pure API-accessible tools, you have to host your custom business logic typically outside of these APIs. That means now you’re spinning up additional infrastructure to make a business center your reality to then, yes, integrate with this SaaS API, but you are spinning up additional hosting infrastructure to host that code, that business logic. That that becomes a very brittle set up and also a costly one at the end of the day. Now, of course, if you’re in that mindset and you buy into that philosophy, into the program, that’s a different story. But that’s rarely a good fit in B2B, from experience.
I think we’re seeing a lot of arguments for buying technology or platforms, but we’re also seeing a lot of need to customize. What is your experience, being a part of many clients' implementations from the Oro perspective? I know you have a lot of flexibility within the platform. How would you quantify the percentage of your customer base that take it as it is, use the out-of-the-box, and on the other side of the spectrum, those that customize it and really build on top?
Aaron: My judgement, working with many customers and doing many, many implementations on many open-source and SaaS platforms, is that our customers is that they’re using at least 50 percent of Oro out-of-the-box – up to 80 to 95 percent of Oro out-of-the-box. What that 50 to 10 percent is that’s left over for them to customize varies wildly. So, for some of our customers, they operate in highly regulated industries. They operate a business where their commerce logic and the IP around their commerce logic is actually their market differentiator. It could be the pricing engine behind it – let’s say they’re selling like commodities, and they need spot pricing. Or they’re in a highly regulated industry, and there are a lot of checks and validations that go into any kind of buying process that rely on heavy customizations, lots of beefy business logic. Those are the folks that are using maybe 50 percent of Oro. What they are using are the fundamentals of the platform. They’re using the infrastructure. They’re using the roles and permissions that are built into the platform. They may be building a custom, headless frontend on top of it. They may be outsourcing some of Oro’s pricing logic to an ERP or a separate pricing engine. But they’re using the guts of Oro effictively to solve problems for them, so they don’t have to solve those problems – things like security, things like a software development lifecycle, things like having full API coverage, things like having scaffolding for AI tools. Things like that are all available for them to use, and then the actual business logic, the surface area that someone is clicking around in can be highly customized.
But some of our customers are using 80 to 90 percent of the platform as it is out-of-the-box, and that is because the philosophy and vision of OroCommerce matches with their philosophy and vision. So, they are using a very standard deployment of Oro, and that works for them because they didn’t need to build something.
And as an integrator, Joe, I’m sure you’ve had the conversation many times where you are acting as a voice in the room when one of your customers in thinking about customizing something and you are asking, “Do you really need to? Is that really going to add value? We can do it if you pay us to, but will that be the right decision for you long term? Could you change the business a little bit to fit what’s out-of-the-box?” Because I had that conversation many, many times, trying to act as an advocate for the long-term interests of my customers. And sometimes, people can run away with their own ideas a little bit in terms of what they think they need to customize, and there always needs to be a process internal to any manufacturer or distributor that asks the question: is this customization actually going to make us faster, make my customers happier, and make me money? And if you can’t answer one of those three things with a very affirmative yes, you may not need that customization. That’s a conversation that really needs to happen, and it can only happen profitably if you have the platform to evaluate the requirement against because if you’re starting from building everything from scratch, every customization, every feature becomes a custom project and that’s how a lot of bad decisions can creep in. There is no standard to evaluate that request against, so when everything becomes custom, everything becomes custom.
Joe: Yes, exactly, and that is a model for large enterprises. They operate their own ecommerce team internally that they have 20 developers on the team, and they have a development lifecycle. But that’s a rarity. I think I’m in the camp of always looking to advise to buy the platform – buy the correct platform, not the wrong platform, that’s very important. But buying the technology, the platform, isn’t enough. It’s a necessity, but you have to also implement it into your organization. That is why we exist. And there is enough to do to get that done, so if you want to get live in a reasonable time frame, if you want to get to an MVP, that’s when you start having this discussion.
Do you really need to customize everything right now or can you adopt more of the out-of-the-box? What are the key business rules we need to customize for to make it functionally work? Can you change the business process? Yes, sometimes. So, instead of having the most complex pricing model, instead of having 400 different shipping rules and fees – can it be simplified? You have to have these discussions, but it’s always buying the platform and building on top of it. Building business value, I think, is indispensable. You can’t just buy technology and expect to be online tomorrow. So, from my side, it’s not build or buy, it’s a buy and then build on top. Any closing thoughts, Aaron?
Aaron: I completely agree with you: buy a strong foundation and then build the layer that makes you you, as a business: industry-specific logic, integrations, buyer workflows. I would say that the emergence of AI has kind of shifted the calculation and the conversation. I am now beginning to hear the phrase “vibe code” quite a bit in even very large enterprises around this topic. So, things that used to require a full engineering team are, theoretically, doable by a smaller team with the aid of AI and agentic tools. I do think that the jury is still out on this topic in terms of the solidity, the reliability. I would say that AI can generate lines of code, but it cannot generate security and safety by itself, and it cannot generate a point of view on what your business and what your customers actually need. And so, AI is a great tool, but I’m bringing it up, Joe, because I am hearing cautionary tales already about people who are trying to build custom things, outsourcing it to AI, and they’re getting code but what they’re getting is an interactive figma. They’re not getting an actual, enterprise-grade solution. Not that they can’t get there, but the journey from A to Z always takes longer than you think that it will even with your AI helper. So, when you’re costing it out, be sure that you’re pricing in tokens and that you are governing and you have the right oversight on anything that you are building on top of. And when you are building, build on top of a secure framework and product that gets you something to build on top of. I would not vibe code on top of a swamp.
Joe: The topic of tokens is an interesting one because even if you end up building it, you’ll end up paying quite a bit for tokens. But that’s another discussion we can have!