Category: Best Practices
You’re in the market for a new eCommerce platform. Either you’re making the leap for the first time, or your existing platform isn’t cutting it anymore. You have your options narrowed down to three: a SaaS product, an open source product with enterprise-level support, and a headless API with rapid development and deployment tools (let’s call this one PaaS). You have a wishlist of 30 must-have or highly-desired eCommerce features. Let the games begin.
All 3 vendors have made their pitch, you’ve done a little homework of your own, and the dust has settled. Here is the final tally:
SaaS: 26 out of 30 features supported out of the box
Open Source: 18 out of 30 features supported out of the box
PaaS: 13 out of 30 features supported out of the box
It’s SaaS by a landslide. Game over. Your decision is made. Right?
Not so fast.
The problem with SaaS is that if eCommerce features aren’t supported “out of the box”, you’ve effectively hit a dead end. Yes, you could make a feature request to the vendor and hope that they consider the feature strategic enough (or you important enough) to land it on their roadmap and implement it to your liking within a reasonable timeframe. What are the chances of that happening? If it happens for 1 of the 4 missing features, consider it a big win.
With open source and PaaS, on the other hand, you can have the eCommerce features you want, on your terms. They acknowledge from the start that flexibility is more important than features and provide a clear model for custom-tailoring to your own needs, nothing more, nothing less.
Another advantage of these platforms is that your solution will be more future-proof. How likely is it that your list of 30 must-haves will not change over time? Hint: We think it’ll change before your new solution even goes live. Not likely? Ok, well, how long did your current platform last before you found yourself shopping for a new one? What happens when you acquire a new customer with radically different requirements? Your list will change, and sooner than you think.
So you’re starting to doubt SaaS. Back to the scorecard. 18 is better than 13, and open source is just as customizable as PaaS. So we can stop the debate now…right?
Let’s take a closer look.
Before even considering implementing new eCommerce features on the open source platform, let’s get the more important question out of the way: Do you have hosting figured out? Maybe you’ve already selected a hosting provider. Do you trust them to secure your customers’ data? Are they PCI compliant? (They’ll be facilitating financial transactions over this platform, and you’ve read a few news stories on the consequences of getting this part wrong, so I don’t need to convince you of the importance of getting it right.) Do they back up your customers’ data regularly? Do they have full redundancy? A disaster recovery plan? An SLA that meets your (and your customers’) expectations? Do your customers have other compliance requirements, such as HIPAA or SOC 2?
Okay, you’ve done your homework and are confident that you have a highly secure, highly reliable (and fast!) hosting solution. On to those missing features. If you’re somewhat new to all this, the first thing to know about open source is that it’s bound to a specific technology stack. That is, a specific programming language, a specific database platform, and in most cases a specific flavor of operating system. The developer you choose to implement those eCommerce features better know that whole technology stack well. In fact, anything less than a developer with knowledge and experience developing against that specific product is a risk. Just knowing Java, MySQL, and Linux (if that’s the product’s tech stack) might not be enough. eCommerce platforms are enormously complex, and knowing how to modify the source code (correctly) may imply a steep learning curve. If it’s hacked the wrong way, not only might you face nasty bugs, but that enterprise support contract may be nullified.
Let’s say you’ve passed this hurdle as well. You found a great developer with tons of experience coding against the open source platform, they finished on time and on budget and you had a successful launch. Seven months later, you get an email from the open source vendor stating that a critical security flaw has been discovered in MySQL and requires an upgrade to both the database software and the commerce platform itself. Clear instructions are provided to perform the upgrade, and it looks like you may not even need to re-engage the developer. Except for one problem: if you upgrade the commerce platform to the latest version, you’ll overwrite some or all of the developer’s customizations. Uh-oh.
So what does PaaS do to solve these problems? At this point, I’ll stop speaking in hypotheticals. Four51 OrderCloud is currently the only such platform in existence, so I’ll speak to how we solve these problems.
For starters, we are platform-agnostic. The only “languages” one needs to know are HTTP and JSON, which are not languages at all, but rather protocols/standards. The difference is that every tech stack used to create Web or mobile applications can “talk” to OrderCloud virtually out of the box, and every developer who builds these sorts of apps already knows how to do this. A developer who can use their tech stack of choice is a happy developer. (And you should never, ever underestimate a happy developer. ?)
Secondly, there is no risk of a developer getting into trouble by hacking our source code the wrong way, because there is no source code to hack. The line is clearly drawn; access to anything beneath the API surface is forbidden. An API is much like a user interface for developers. We expose all platform features through this well documented interface, and everything under the hood is off-limits.
Third, OrderCloud solves the hosting problem by completely “owning” it, much like SaaS. Data storage, and therefore data security, availability, backups, disaster recovery, etc. all sit behind our API and are direct concerns of the platform itself. You don’t need to shop for a hosting provider; we’ve got it covered.
Finally, enabling rapid development of applications that sit atop our API/platform is a big, big strategic priority for us. How big? One way to measure is how we allocate our tech resources. Our developers who build tools and resources in support of rapid application development outnumber our core platform developers by about a 4 to 1 ratio. Our API follows RESTful conventions and is fully documented, but if a developer prefers an added layer of abstraction specific to their tech stack, we currently provide SDKs for 7 popular languages. We have open-source application “seeds” (foundational starting points) available for HTML5, iOS, and Android. We have a growing library of user interface components available to virtually “drop-in” to a seed app. And for the ultimate rapid development experience, we provide application “accelerators”, which assemble the relevant pieces into a fully functional application without writing a line of code. And did I mention documentation? Tutorials? Developer training programs? If you haven’t done so, I’d encourage you to check out our Dev Center, home to these resources and so much more.
When it comes to selecting an eCommerce platform, you have many choices. But desired eCommerce features do not boil down to a simple yes/no.
No platform is going to have everything you want, and most won’t even have everything you need. It is important to ask what the platform provides out of the box, but it is more important, in our view, to ask how you can have the things it doesn’t.