Building a Marketplace from Scratch – Part 1: Early Learnings

So you wanna build a marketplace? And… you’re thinking about building it from scratch? If so – you’ve come to the right place!

I recently joined forces with John Doherty to build the next evolution of his business, Credo. Part of that evolution is building a new platform to serve a marketplace business model. We spent all of 2019 building this new marketplace – both technically and strategically.

This post gives you some insight into how we’re doing that and what we’ve learned so far.

Some pre-context:

1. We’ve built the platform from the ground up. This means completely new UX and code.
2. We’re 100% bootstrapped. This means our own financial and human resources (no funding).
3. We’re transitioning an existing business into this marketplace. This means we have existing revenue and users to leverage, as opposed to a brand new startup.

Our Business Model

Next, let’s break down our business model.

Credo helps businesses find top digital marketing talent. We evaluate your marketing needs and then match you with an agency or consultant within our exclusive network who can deliver the work. We are the TopTal of digital marketing.

As it relates to that business model, we needed a new marketplace/platform to facilitate the matching of businesses with talent. Most marketplaces have two types of users:

A) Buyer

B) Seller

In our case, we have clients and pros as the respective buyer and seller. The clients are the businesses looking for talent (buyers), and the pros are the talent who deliver the work (sellers). The marketplace brings them together to meet the market need.

Early Learnings

Now that you understand the context and business model of our marketplace it’s time to reflect on what we’ve learned in the last 12 months.

Learning #1: Managing Supply & Demand

For starters, I can speak for everyone who’s ever built or attempted a marketplace in saying that marketplaces are tough. In fact, I ask myself frequently why I thought this was a good venture. And then of course, John reminds me of the potential 🙂

But in all fairness, marketplaces are harder than other types of online business. For example, I’ve built the following business types that are much easier:

• Agency
• SAAS
• Membership

Why are marketplaces harder than agencies, SAAS products or membership businesses?

You have to constantly manage supply and demand economics.

For example, you always have a buyer-to-seller relationship that needs attention on both sides. You need enough demand from the buyer side, and then you need to fulfill that demand with enough supply from the seller side. This is the core attribute that defines a marketplace. It’s also one of the most exhausting aspects of running a marketplace!

The “double vision” effect

With agencies, SAAS products and membership businesses you only have one side to manage – the customer. So you can focus your sales/marketing efforts on them and then fulfill demand with your own team/resources. You can also focus all your product development efforts on building for one user type. I call this “single vision.”

Whereas a marketplace requires “double vision” for the product since two parties are using the site/platform. For example, a new feature could [and usually does] impact both parties. You typically have to double your sales/marketing efforts as well, since both parties need to be engaged, onboarded and sold to in one way or another.

Everything is essentially doubled, including (but not limited to):

• Marketing
• Lead generation
• Onboarding
• Product development
• Support
• etc.

So you can imagine the thought of 2x work across the board. Not always fun.

Supplier fulfillment

One of the other inherit aspects, and challenges, of supply/demand economics is having 3rd party supplier fulfillment. In other words, having your suppliers deliver the end product to buyers. In our case, this is having pros deliver the work to clients. This involves some guidance, monitoring and regulation of the demand fulfillment to maintain quality control from the sellers.

Now some would argue that it’s easier to have other people do the work (fulfill the demand) since you no longer have to. Sure, that can certainly be the case and is ultimately the goal. But… there’s A LOT that goes into supporting a seller network, which leads to my next learning.

Learning #2: Supporting a Network

The supplier side of our business is unique in a sense that it’s a network or digital marketing “pros.” These pros are consultants and agencies who can fulfill the project needs of the clients (buyers). So unlike a traditional marketplace where the suppliers are simply offering a product, our pros (suppliers) are offering services.

For example, our pros help clients with the following types of digital marketing channels:

• SEO
• Google ads
• Facebook / Social marketing
• Content marketing
• Amazon marketing
• etc.

So every pro in our network has to be competent and experienced in at least one of those project channels.

Network vetting

Each pro must also go through our vetting process to prove that they’re skilled and experienced in their respective area of digital marketing. This is how we maintain top talent and ensure that our clients are getting quality service. Hence my point above about quality control.

Luckily for us, this vetting was mostly already in place by John before we switched to the marketplace model. So the level of effort was minimal compared to other areas of the business.

Network dependency

One of early realizations we encountered was how dependent our marketplace would be on the network. We often reference the following statement:

“Our network is our net worth.”

In other words, the value our business can create is directly tied to the value of our network as a whole. Because without them, we can’t fulfill the needs of clients. To use another example – AirBnB would have no business if they didn’t have homes to list on the supply side. This is an example of the supply and demand economics I mentioned above.

However, it’s important to realize that this relationship goes both ways. We have many pros who rely on us to deliver new clients/projects every month. So in a way they are very dependent on us as well.

This is why supporting a network plays such a big part in our business. We rely on them and they rely on us. If we can create value for them and help them grow their businesses, they will ultimately help the Credo marketplace [and business] grow. It’s a beautiful win/win relationship if the economics play out.

Learning #3: Controlling Payments

One of the core responsibilities and functions of a marketplace is controlling the payments. In other words, collecting money from the buyers and then distributing it to the sellers. There are many ways to achieve this, including a range of processes and solutions.

Here are some of the major things to consider:

• How much you want to automate vs keep manual (ex: invoicing)
• Which payment gateway or service(s) you plan to use
• How to structure your transactions + commission fees
• Online payment security
• etc.

This piece is pretty big, because let’s face it – without a payments system there really is no marketplace!

In retrospect, this part of the business took A LOT of time and energy to plan, develop, and maintain. In fact, it’s still one of the biggest areas of the business and we continue to work on it.

Main consideration = level of automation

That said, the main consideration [and learning] here is how much you automate. Why? Because this dictates how much engineering effort you allocate vs human effort.

For example, here are some ways to achieve this with various levels of automation:

1. You could manually send invoices and distribute payouts (completely manual)
2. You could use software + online forms to collect payments, and then distribute payouts manually (somewhat automated)
3. You could develop complete marketplace payments via Stripe (or similar gateway), and then use Stripe’s API for payouts (mostly automated)
4. You could engineer the entire system to run on buyer/seller actions and not require any human intervention (completely automated)

Everyone wants option 4, obviously. However, option 4 is extremely expensive from an engineering effort. It also gives you very little room to test and learn before you actually engineer all the parts to make that work.

Our journey landed on option 2 in the beginning and has since moved into option 3. In doing so, we were able to see how the payment flow looked before investing tons of engineering effort. We also have a good sense of what will be required to pull off option 4.

Stripe Lessons

I wouldn’t be doing this post justice if I didn’t speak a bit about Stripe. It’s the payment gateway we chose and the industry leader in the category of collecting online payments. We are using their Stripe Connect offering, which is ideal for a marketplace. I won’t get into the weeds with exactly how we’re using that in this post… but it’s a HUGE part of our tech stack and certainly a topic for another day.

Here’s a quick summarization of our experience using Stripe thus far:

• Stripe Connect does give you the proper [marketplace] infrastructure to take payments from buyers and distribute funds too sellers. In other words, it’s designed to make managing a marketplace easier.
• However, their Stripe Connect offering is much less stable than their normal Stripe Payments offering. I can tell you this with confidence since I’ve been a customer/user of both. For example, some API doc references are not accurate and we’ve encountered multiple large feature bugs that were still in development by the Stripe team. So be cautious if you spin up a Stripe Connect account for your next project.
• When using Stripe Connect you have 3 account type options:
  • 1) Standard
  • 2) Express
  • 3) Custom
  • We chose Express to get some built in features + enough flexibility to use their API and customize things as needed. The new user onboarding that Express provides saved us a lot of engineering time, for example. That said, you should do deep research here before choosing the right account type. It will have long-term effects that get harder to reverse as your marketplace grows.
• Their support for technical issues is lacking. This means you’ll generally have to bounce around a few support people/threads before getting a technical answer from someone with knowledge. This can be very frustrating for engineers who value their time (like me!). That said, when you do get to the “right” support person they generally have the type of answer you were after. So the trick is figuring out how to skip the line!
• Their development vs production environments can be quite different as you get deeper into the API. For example, some things that happen in production don’t happen the same way, or at all, in development (or vice versa). You can imagine the frustration and confusion that this causes when building deep features. We encountered an example of this when testing ACH payments through Plaid. These API details can be sensitive… so I give some grace here, but accurate testing and development environments are a HUGE part of stable payment infrastructure. So test things vigorously if you’re interfacing with the API.
• On a positive note, they do give you an assortment of tools to develop against and test. It’s easy to point out all their shortcomings, but in reality, they still are the industry leader for good reason. And more importantly, we would have spent a lot more time and energy without them.

So while I certainly have my frustrations with Stripe, I also appreciate the service they provide! Their platform helped us build our initial MVP close to the specs we had in mind, which includes a variety of payment processing and payout infrastructure. They saved us a lot of time, and tedious coding, that quite frankly isn’t the most fun or rewarding work.

Stripe Connect is built for marketplaces.

So thank you, Stripe 🙂

Learning #4: Manual Processes vs Automation

This one is huge. I could, and probably will, write an entire post on this alone. There is an ongoing list of business processes we should automate vs keep manual. This applies to all software businesses, not just marketplaces. But with Learning #1 and the balance of buyer/seller needs, the amount of business processes can become quite exhaustive. You have to embrace automation.

The cost of automation

That said, creating automation generally requires coding or technical resources. This becomes quite expensive as you stack up tasks and features. Not only do they take time to program or configure, but they often touch other parts of your codebase/stack and lead to deeper resourcing.

In contrast, almost any business process can be handled manually by humans. However, that comes with a cost as well. Humans must be compensated and they are imperfect at best, meaning there is always risk of human error. This is why it’s generally more cost effective to automate software businesses (for the long-term) than employ a bunch of humans.

Needless to say, we’re constantly faced with the decision on when to automate something vs keep it manual.

When to automate

The decision to automate usually comes down to a few factors:

1. How big is the problem we’re trying to solve?
2. Is the automation tied to revenue?
3. Are we really tired of doing this?

Small problems that are tied to revenue get automated quickly. Whereas, larger problems that have no revenue implication take longer to automate. However, the last point about being “tired” is something new we came up with to help balance our personal needs. Sometimes you just get tired of doing something… and for us, that means it’s time to automate!

Regardless, there will always be something [else] to automate. That’s the nature of building and growing a software business. However, we’ve learned to let our 3-factor criteria above help inform us when we automate.

The business should inform you when something should be automated.

For example, in the beginning we felt like everything should be automated at some point. There were an endless list of tasks and technical stories that we knew we had to do. This flooded our PM software boards and influenced conversations around automation weekly, if not daily. And before we knew it this type of conversation led to frequent discussions about future strategy/features/growth + dependencies on automation.

Every online business deals with this kind of decision making, so it’s not uncommon. However, the key is to accept this and focus on prioritization of what you automate and when. If you follow a 3-factor criteria (like ours above), the business will help inform you when something needs to be automated. This will save you a lot of time and energy that would otherwise be spent discussing what to automate.

Wait [and test] before you automate

Now that we’re over a year in we’re content knowing that some things will just take time, or never actually reach, true automation. In fact, one of our “experimental” methodologies forces us to hold off on automation as long as possible in lieu of testing, or validating, its value to the business. So keep this in mind if you start to feel overwhelmed by the amount of human processes you incur. See if you can test something before you invest in automation.

Learning #5: Unpredictable Revenue

This is the last and most volatile learning as it relates to growing the business. Marketplaces are unique [and risky] in the sense that you can never truly predict revenue. Or said differently – you can’t predict revenue as accurately as other business models. This is the bi-product of having a supply and demand model with various types of products.

Product variance = less predictability

To be more specific, we’re not selling one or two simple products. We have consultants and agencies delivering all types of work – from smaller SEO audit projects (1-3k) to large marketing retainers (5k/month+). So you can imagine the challenge in trying to predict sales and revenue given the spread of product offerings. This is vastly different than a SAAS business where you have a few subscription options and a sales team marching towards revenue goals.

To give you a better idea of the challenge, let’s take another marketplace as an example – AirBnB.

AirBnB has no idea how many people will search for a place to stay every month. Their best prediction is based on historical data – i.e. how many people searched last month or the year before at the same time. So they likely base their sales and revenue goals off these predictions. And even with this prediction, the amount of people who search for apartments vs mansions is an entirely different data set. Which again, will be forecasted from previous data. This ultimately means they cannot predict revenue with accuracy until they have large and stable data sets.

This takes time. Period.

On the contrary, a non marketplace business can more easily predict revenue based on their simplified product offering.

For example, a SAAS business has two subscriptions – $99 and $199/month. They likely have accurate data around previous traffic, leads, and other KPIs that inform their revenue goals. With these 2 price points they can quickly build predictions around future revenue. This does not take nearly as much time as that of a marketplace.

Predictable revenue just takes time.

So the lesson here is to know that you’ll have no true sense of revenue until the marketplace starts running. Especially in situations like ours, where you have a wide range of product offerings. This takes time and patience to establish meaningful data you can forecast against.

Let me repeat that one more time just so we’re all clear – predictable revenue takes time and patience.

John and I have had to remind ourselves of this often, which is why it bears repeating 🙂

Summary

To be fair, there are A LOT more learnings! This was just the tip of the iceberg… and I plan to share more of those learnings in some future posts. But this gives a pretty good snapshot of what we’ve learned in the first 12 months.

I will close with this –

Marketplaces are hard. There’s no debate there. However, with that challenge comes new learning, which is part of what inspired me to join John on this adventure. We are learning and growing every day. There is a lot of complexity to navigate with a marketplace… but in turn, there are also some nice effects that enable a marketplace to run on its own. That’s where things get exciting from a business perspective.

Stay tuned for part 2 later this year!

---

Photo credit: Geoff Greenwood on Unsplash

---