This series of articles describes one of the modern approaches to designing and building e-commerce applications. It focuses on showing how to ship CRM-related features fast, so the business gets decent time to market. If you want to get along with business people or you’re thinking of becoming a CTO, then this series might well be worth reading.
This is the first installment of a series of posts, here you can quickly jump to other parts:
The recent Gartner’s study on digital commerce trends highlights Marketplace Integration and API-Based Commerce Platforms. The paper brackets these concepts with “strategies intended to help them [digital commerce companies] nimbly provide an outstanding experience without significant upfront investment.” Sounds serious, right? If you run an ecommerce business and you’re curious about how these strategies can be translated into technology and operations, you’ve come to the right place.
“Provide an outstanding customer experience without significant upfront investment”
With this series of posts, we’d like to focus on the tech point of view and show you how to map the high-level concepts into working software architecture. We’ll try to do this by way of designing an online marketplace architecture from scratch.
LET’S START WITH SOME DEFINITIONS
Our working definition — an online marketplace is a virtual place where sellers and buyers meet to exchange goods or services. The exchange usually takes the form of transactions managed by the marketplace operator.
The operator measures the overall success rate of the marketplace by the number of deals between buyers and sellers. This is because they typically get a commission out of every transaction. So, to generate revenue it is the operator’s role to build a friendly environment which encourages:
- Sellers to exhibit
- Buyers to… buy
(usually in this order).
There are many niches you can target with an online marketplace. On top of this, there are many types of marketplace. So far, the market has come up with B2B, B2C, service, or C2C type. Yet the core mechanics of any marketplace platform are pretty much the same. Paraphrasing Mirakl, a well-oiled marketplace should provide these features:
- a promise of ever-growing traffic — to attract new sellers,
- a product catalog which stands out — and generates the traffic,
- a buyer-seller-operator communication and sales tooling — to spark off the confidence in buying
- a legal framework and transparent payment system — to finally close the sale, guarantee the quality, make buyers come back and start the cycle again
As you can imagine, these essentials have a huge impact on the design of the software the platform works on. What’s more, they often change over time. As much as we’d like to, we cannot cover all the cases up front. This is why, before we dig into the bloody details of the platform architecture, let’s talk a little bit about the context and key assumptions.
ASSUMPTIONS
In this story, we assume we’ll be designing an early stage marketplace. Moreover, it’ll be a company which starts in a competitive market. You can call it a startup.
These 2 assumptions imply that the venture business model won’t be battle-tested. And this, in turn, entails particular requirements for the software underneath. In other words, to get a good time-to-market the platform should, therefore, be:
- Open to quickly handle new, unexpected business scenarios
- Super easy to change on a daily basis
- Ready to onboard and offboard developers fast
But it should also give the ability to:
- Learn from data
- Reasonably scale when unexpected traffic hits the platform
- Connect different departments
Also, the very fact of the article title introduces a serious assumption; we want to build marketplace software from scratch but why and what does “from scratch” mean after all?
FROM “SCRATCH” REDEFINED
Usually, when I hear this term, something positive pops into my head. Why? Because I immediately imagine a greenfield project with the freedom to choose the software practices and toolkit. I assume that having this kind of freedom should let me build the right software the right way.
“Build for today, design for tomorrow”
But is this not a contradiction in connection with the speed of development we assumed to be our primary concern? Is implementing every part of a marketplace on your own doomed to be slow? We don’t really know. It depends on so many factors we don’t want to jump to any conclusions.
What we’d like to lay out instead is a different approach to building ecommerce software. We’ve seen this successfully deployed in a fast-growing Internet business twice; actually, we’ve been a part of both these projects.
It treats the speed of development requirement as a priority and, at the same time, gives the dev team a sufficient degree of freedom to roll-out their own software architecture practices.
What we suggest is to assemble an early stage marketplace platform by mixing modern yet proven API-first platforms. We’ll focus in particular on:
- CRM and other sales support tools
- Marketing & e-commerce APIs
- Customer service SaaS
In the next posts, we’re going to outline how to actually create such a setup and how to keep it up and running until the business becomes mature enough to rethink and maybe insource some parts of the system. In particular, we’re going to describe:
- overall architecture,
- integration best practices,
- implementation tips,
- and finally, the advantages and drawbacks of the 3rd party API platforms
All of these in light of improving time-to-market for online marketplaces.
Last but not least, while this setup has proven to be effective for us, we’ve also learned its downsides. We’re happy to share them too.
Unfortunately, we didn’t come up with any fancy name for this setup. If you have an idea, let us know via @voucherifyio. However, we randomly scattered some cheesy-yet-hopefully-accurate buzzwords all over the article to catch the attention of people who just scroll.
“Agile model driven development: the key to scaling agile software development”
WHAT IS IT THAT YOU CAN ACTUALLY WANT TO BUILD?
Without further ado, we’re gonna build a marketplace that matches the hardware designers with the hardware manufacturer. It’s like tindie.com/biz but instead of being a recommendation board, it’s gonna oversee the transactions. Let’s call our platform Manufaktura (which is a Polish word for “craft production”)
The business model goes as follows: imagine you have designed a prototype, your Kickstarter campaign worked well and now you’re looking for a trusted supplier. This is when Manufaktura comes into play. You describe your needs and submit a request and manufacturers can then place their bids.
Besides, the management has noticed another related niche. They predict the platform could be an agency for recurrent support & maintenance contracts. This isn’t to consider for the first stage, but something to keep in the back of your head.
There’s one more thing to keep in mind. The business starts with tight competition. There are already 2 other companies that want to conquer a similar niche. We have to hurry up because chances are that the market leader will take it all. So, let’s get down to business.
Disclaimer: There are many unknowns when building a marketplace like this one. Figuring out “the right way” requires a helluva lot of work. So, we have no idea if this business could be a sustainable one and we’re far from claiming that any of our business assumptions would hold true. Nonetheless, we’d like to show you how Manufaktura could work and overcome some made-up-but-potential business hurdles.
COMPONENTS OF THE MARKETPLACE
Marketplaces are complex beasts. There are plenty of things you have to think of. To make matters worse, the individual parts of the platform are often interweaved and it’s hard to pinpoint clear cut components. To make matters even worse, naming things is hard. So please bear with us when some categories don’t correspond with the conventions you’ve learned.
We’ve discerned the following pillars. This breakdown will be mapped into upcoming posts:
- Order management — how to handle orders through the platform in a way which allows multiple people/departments to collaborate
- Platform infrastructure & monitoring & recovery — deploying monitoring and alerting measures, error handling guidelines, manual and automatic recovery
- Email & SMS marketing — the use of email and SMS APIs in marketing channels
- Payments & invoices — different payment options and gateways, recurring payments, billing and invoice operations
- Customer service — creating email campaigns for customer onboarding, organizing support and case management
- Customer tracking — how to track marketing channels and users online, A/B testing
- Reporting — collecting and visualizing data
- Promotions — how to generate more traffic and re-engage existing customers
- Shipping — automating shipping
And to give you a sneak peek of the infrastructure, we can say we’ll be using lots of SaaS/API platforms and a small backoffice system hosted on Heroku. The overall architecture looks as follows:
THE FIRST POST
The first post won’t be about preparing a developer environment. No Jenkins, no Docker, no AWS, no DB schema design at this time. There’s no time for those things at the moment. The Excel orders sheet is becoming worse and worse in maintenance and is delaying Manufaktura’s bid process. Let’s replace it with a proper ordering system!
Originally published at www.voucherify.io.
