Dit is de eerste aflevering van een serie berichten, hier kun je snel naar andere delen springen:

• Online een onlinemarktplaats opbouwen - orderverwerking
• Een onlinemarktplaats van de grond af opbouwen - de duistere kant van Salesforce-limieten
  
• Minder unit test meer logs
• Programmatische e-mails met API-first-providers

De recente studie van Gartner " Wat is er zo goed in digitale handel? " Over trends in digitale handel, markeert Marktplaatsintegratie en API-gebaseerde handelsplatforms. Het document ondersteunt deze concepten met "strategieën die bedoeld zijn om hen te helpen [digitale handelsbedrijven] op een bekwame wijze een uitstekende ervaring te bieden zonder aanzienlijke initiële investeringen." Klinkt serieus, toch? Als u een e-commercebedrijf runt en u bent nieuwsgierig naar hoe deze strategieën kunnen worden vertaald in technologie en activiteiten, bent u bij ons aan het juiste adres. 

Met deze reeks berichten willen we ons concentreren op het technische oogpunt en laten we u zien hoe u de hoogstaande concepten in de architectuur van de werksoftware kunt brengen. We zullen dit proberen te doen door een online marktplaatsarchitectuur helemaal opnieuw te ontwerpen. 

LATEN WE MET SOMMIGE DEFINITIES BEGINNEN

Onze werkdefinitie - een online marktplaats is een virtuele plaats waar verkopers en kopers elkaar ontmoeten om goederen of diensten uit te wisselen. De uitwisseling heeft meestal de vorm van transacties die worden beheerd door de marktplaatsbeheerder. 

De operator meet het algehele succespercentage van de markt door het aantal deals tussen kopers en verkopers. Dit komt omdat ze meestal een commissie krijgen van elke transactie. Om inkomsten te genereren, is het dus de taak van de operator om een ​​vriendelijke omgeving te bouwen die het volgende aanmoedigt: 

• Verkopers om te exposeren
• Kopers om ... kopen

(meestal in deze volgorde). 

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. 

WHAT IS IT THAT YOU 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!