MentorCruise’s initial software was born in 2017 and 2018 during about half a year of working on trains during a long commute, just a few minutes before going to sleep or on free weekends, which seems silly today, because the value of a marketplace is in no way the software stack.

Recently, some no-code solutions have made up for that and platforms like Sharetribe have risen up and made the process of starting a marketplace easier – at least from a technical perspective.

However, if you are a little bit of a perfectionist like me, or too stingy to pay $150/mo like me, or simply grew out of Sharetribe and are in need of a custom solution, this is what you’ll get into.

Two-Sided User Model

Something I didn’t expect to be such a big issue was the user model. From an engineering standpoint, this was quite straightforward: I created a Mentee profile, and a Mentor profile. What was more difficult was to make people understand which is which. There are certain things to look out for here:

• How do you handle people wanting to sign up as a supplier AND customer? (e.g. mentor and mentee). I solved this by using usernames for mentors and emails for mentees, which is leading to a lot of confusion, even today. Probably the best approach is to implement a selector after log-in.
• Are different profiles different users? Or is the user the same with different profiles? Security-wise, if one account is compromised, wouldn’t it be better to secure the other one? I decided to keep users apart, not sure if the right decision.
• How do you lead interested people to the right registration? Until today, most mentors (suppliers) will first create a customer profile, then realize they are at the wrong stage and go back.
• Social logins are used by 50% of my customer base, they are quick to integrate and easy to use. But are social logins for both users? By default, which profile is being created when you click the button first?

These are things you can solve, but the thing with authentication models is that the thing you decide to do in the beginning, is often the thing you have to stick with for a while, so choose wisely.

A billing system like you’ve never built before

That might be assuming a lot, but it’s really intense :)

If I could pick one thing that I would not want to build again and something I would gladly pay money for, it’s the billing system. Let me tell you a little bit of history.

• In 2017 I decided to go with PayPal as my main form of payments and payouts. I was able to integrate “Billing Agreements” for subscriptions, calculated the transactions once per month, then used the Mass Payments API to send out payments to a few dozen suppliers every month.
  
  This worked quite well, even though I got the one or other complaint that fees were too high (exchange rates and getting it to your bank account) or that Billing Agreements are not available in every country, but it worked.
  
• In 2018, PayPal turned off my (and most of other international people’s) access to Mass Payment off without warning. My billing system held up, but payments were done by hand once per month. A lot of work, a lot of time, and not a lot of margin for error.
  
• In 2019 I integrated Stripe Connect as a Payout option for the 20-something countries it is available in. The caveat – if you want to send payments internationally, you will have to give ownership of the transaction to your supplier, meaning if they mess up their account, they mess up your payment system too. This happens more often than I would like.
  
  It also meant that people were now only able to pay via credit card, which not everyone liked. I decided to send payments to other countries (about 50% of the volume) manually still.
  
• Since late 2020, I have worked on an unified API that does payouts using Stripe, Local Money Transfers and Wire Transfers, getting me to full global coverage at the lowest possible price and – almost more importantly – a full disconnect between payment and payout. I can now charge money in a variety of ways, calculate the splits in my backend, and just do the payouts via the API. I want to make this available to others later this year.

The billing system was for a long time my biggest worry. Not only was the situation with payouts and payments so complicated, you also need to double-check every single error that you get.

If you are running a SaaS business and one of your customers has an invalid credit card, it’s really no big deal… Try to get the payment, try to notify the customer, and kick them out if all else fails. If you run a marketplace, you will also have to notify the supplier about this, explain possible next steps, and be extremely confident that there is no way for a scam to slip through.

The same thing with refunds – as a SaaS founder, just give people a refund. It really makes no sense disputing it. As a marketplace, that’s not so easy. Who pays for the refund? Did the supplier not do their job? Did your platform promise wrong things? It happened more than once that I paid refunds and chargebacks out of my own pocket.

Communication Channels

This may not be applicable to you, but if you have made a purchase or a booking on a marketplace, it is quite common to provide a way to communicate after. This may be a simple share of e-mail information, but in some cases, you would not want to give people direct contact info.

In this case, you will have to think about implementing some type of messaging system, like a chat. Now if you are a programmer, that might sound easy – set up a websocket and or copy one of those ‘chat-demo’ projects and you’re done, but there is so much more to a 21st-century and consumer-facing chat than that.

Since my first version of a self-built chat, I had to add a proper way to interact with it on mobile, file-sharing, rich editing support, email notifications, browser notifications, push notifications, reminders via e-mail, multiple re-designs and had to fight with performance issues and blocked websockets since Day 1.

This would be another one I would outsource, it’s just not worth it.

A lot of FAQs and Support

If you thought that support was heavy for your SaaS, then double that and you have the support load of a marketplace.

Even if you work closely together with your suppliers or prefer to have direct conversations with them, you will have some that will contact you through every available channel nonetheless. Additionally, some of your suppliers are making a living (or at least some substantial income) from your site, so there is an added source of anxiety, which often manifests much stronger than your customers having an issue.

Be prepared to write a lot of documentation, and have a good way of bringing FAQs and your documentation across in the platform. Setting up a GitBooks page and just blurting everything out in there is not enough – you need to add pointers for your customers at key positions and provide context, or even 100 pages of documentation will not be enough.

I am still alone working on MentorCruise, but someone for support (or a general community manager) is the first position that I would hire.

Automation is key to a curated marketplace

Finally, a little trick to add up your sleeve. Curating a marketplace is hard. You will have a (hopefully) small subset of suppliers dropping out, ghosting you, and not adhering to rules, which destroys the experience of your customers.

The solution to this may be moderation, but at scale, it’s definitely a thing that automation can solve.

At MentorCruise, I am running over 10 cronjobs for automation, a subset of them are

• Reaching out to inactive users and potentially removing them
• Reaching out to users with bad reviews and removing them
• Reaching out to longterm customers and getting feedback
• Reaching out to recent churns and getting feedback
• Sending notifications
• Notifying users about open/unread requests

There is probably more I can’t think of right now. The gist: There will be stuff that is unoptimized, and not everyone will act in your best interest, so instead of playing moderator for your whole day, it makes sense to pick up some skills in automation and just let scripts run that part of the business for you.

‍