Building an online marketplace from scratch — introduction

Originally published by Mike Sedzielewski on August 28th 2017 951 reads

@msedzielewskiMike Sedzielewski

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.

Building an online marketplace from scratch — introduction

@msedzielewskiMike Sedzielewski

LET’S START WITH SOME DEFINITIONS

ASSUMPTIONS

FROM “SCRATCH” REDEFINED

WHAT IS IT THAT YOU CAN ACTUALLY WANT TO BUILD?

COMPONENTS OF THE MARKETPLACE

THE FIRST POST

Related

5 Different Angles To Look At Java

@hesselHessel Dijkstra

Open Source Myths and Half-Truths: Part 2

@ryandawsonukRyan Dawson

The Importance of Business Communication Software in 2020

@JHUMJosh Hummerston

Tags