CHRIS: Yeah, that's a great point. And I mean, I think it's really probably the most important thing to take away from this checklist when you're looking at software is, can adapt to my scenario? Because one of the things that led us to create a marketplace website software, for seven or eight years we worked with off-the-shelf tools exclusively.
And what we found in that process was that the last mile, the last five to ten percent off functionality tended to be such that we were literally painted into a corner, because we had completed ninty to ninety-five percent with this, quote-unquote, off-the-shelf functionality. But the business, in order to fully realize its objectives of self-service and low friction for the users, it really had to have these three capabilities. That's where the bottleneck in the B2B marketplace solution was.
Frankly, Ron, this has been an accumulation over those seven to eight years, and then ten years after that, of validating it for the entire ten years—this is really the bottom line. You need a set of core features, and you really do want to understand what are those core features are. And there should be a reasonable set of core capabilities within whatever marketplace platform you choose.
Most importantly—and this depends on your business, if your business is mature enough or is complex enough that you know you need certain things and you know that they're bottlenecks, or you are projecting that they reasonably will be—does the platform you're working with really have a set of architecture that is friendly toward that?
And what do I mean? Well, let's just take an example. Let's look at the example of Legos versus clay. You know, clay is great. You can make whatever you want, but once you bake it, it's set. And I'm not a clay expert, but I don't really think a lot of people add more clay after the fact.
But with Legos you can add and remove as you need. And ultimately the point is , once a platform is set in stone, if it's not well-made, it's going to be like clay that's been baked. It looks really good, it's really cool. It can be used for that specific purpose, but really not a lot else. And it's brittle, and if you if you crack it, it's gone.
Whereas with Legos, they're really made to be interchanged. And with our software, that is very much the case. Add B2B auctions, add a marketplace. Depending on how the software was architected and written, it can either do really well with a specific set of tasks, or it can do really well at the specific set of tasks and be adaptive to new tasks.
If you think about it, what is the basis for B2C marketplaces? Was it made to be adaptive, and was it made to be compatible with changes and adaptations that you're going to have? And without going into super detail on the technical front, I will just say that some keywords that you should look for are things like “plugins” or “modules,” the ability to “override” or “extend.” And then look for examples of where, mechanically, you can see that, “Okay, all of these different areas of this eCommerce marketplace platform were overridden, and I can see actual examples of that. And it's a viable solution.
One of the key questions that I would always ask around that is, what are the limitations? What are the areas that can't be extended or overridden, and why? If you get those answers, you can understand what the limitations actually are. The answer should be, effectively, there are no limitations, but there may be more overhead to overriding or extending a core feature, and you need to know what that is, ideally.
RON: Yeah, my big litmus test is the API, right? As I'm doing demos, I have a lot of people come in and ask us about our marketplace eCommerce platform and we start talking through that and they're like, “Well, how does it stack up to this?” And they'll say, “Well, have you looked at the documentation for the API for that B2C marketplace?”
And they're like, “No,” and we'll Google it, we'll open it up and we'll walk through the API together. And I'll show that most APIs out there have anywhere from about 200 to 500 endpoints. Right? And they're like, “See, look at all the stuff it has there. It's all documented. It can do everything.” And I said, “Yeah, watch this.” And I pop into our B2C marketplace platform, I go to the API documentation, and we have over 11,000 endpoints documented within the platform.
So when you start taking 500 endpoints and 500 functions that you can do within a platform to 11,000, they don't even compare, right? Our platform was literally made to be infinitely scalable and was designed that way first, even with ERP marketplace integration.
So for me, the litmus test is, I go look at the API. So once I write all my features down, can I go in and integrate all those features? For example—I'm not picking on WooCommerce, it's the most widely distributed eCommerce plugin in the world—but WooCommerce has about anywhere from two to 400 endpoints, depending on which documentation you're looking at.
But it doesn't do B2B invoicing at all. So when you go to B2B eCommerce, and we try to go integrate that with—I've got clients that have WooCommerce on the front end, but then they come to us to integrate Dynamics AX on the backend, which those two just don't even sync. But now all of a sudden they've got all this invoicing and all this multi-warehouse. It got all this capability in their ERP that can't be exposed in WooCommerce, because even if there's a plug in that adds B2B invoices generation to WooCommerce—which there is—those plugins don't extend the API. So now we don't have the ability unless we directly integrate directly to the database, which everyone knows is not the way to integrate.
This is the most important reason, for me, why you get these features written down, so that you can go validate the true capability to extend and support that functionality when you build a multi-vendor marketplace in the future.