Two Data Scientists Build a Marketplace
My friend Archy de Berker and I love building things from scratch. At the start of the pandemic, we released an epidemiological model to forecast the spread of COVID-19 depending on people’s adoption of social distancing measures. This was something we were used to: start with data, model it, and let people visualise your conclusions.
Recently, we tackled something pretty far outside our comfort zone. After quitting our jobs following 6 months of demotivating remote work, we built a marketplace to ease social isolation within corporate teams. What follows is a technical dive into how we built it.
But… why though?
Cholla is a marketplace which allows employers to find awesome virtual events for their teams.
The idea arose from our own frustrations with remote work this summer. Not going into the office means less social contact with colleagues, and less socially connected teams are less satisfied and less productive. We had tried to solve the problem internally. As a team, we had a recurring calendar invite meant for us to chat and socialise. We quickly realised that virtual happy hours where 12 people stare at a screen and try to talk simultaneously simply don’t cut it.
We also tried trivia, which I hosted. But hosting anything more than impromptu happy hours requires a significant time investment, whether you’re organising in-house like I did or coordinating with external providers. Our marketplace solves these issues by letting team leads browse exciting experiences and schedule them in just a few clicks.
You can read more about our motivation here. Let’s get to the juicy technical content.
Ground zero
Cholla is a two-sided marketplace: corporate teams buying remote socials on one side, and anyone who thinks they can entertain a dozen grownups for an hour or two on the other. To quickly test companies’ appetite, we decided to keep the supplier side of the market closed and partner with a dozen or so trusted providers to start with.
While we love building things, we did our best to stick to one rule: don’t start from scratch unless you need to. We wanted to avoid unnecessary work until we knew teams would pay for our offering.
We realised that we could get started quickly with a Shopify store. After all, we wanted to offer a collection of items that team leads could browse and order easily. Shopify was offering a 3 month free trial, so it was easy to get started. The only significant difference from your standard Shopify store is the ability to choose a time and invite other team members, but we should be able to find Shopify apps among the thousands available that would solve this problem… right?
The Shopify apps twilight zone
Since Shopify does not provide support for attendees and scheduling out of the box, we set out to explore the Shopify app ecosystem… and hit a wall. The biggest hurdle was scheduling. There are scheduling apps out there, but they’re very rigid and tailored to one or two use cases.
All in all, we could have released a first version only using Shopify and its apps. But the required workarounds meant we would have to do a whole lot of painfully manual work, and the user experience on our store would have been terrible.
So after a long discussion about the trade offs, we decided to essentially re-build Shopify (so much for avoiding coding things from scratch), baking in our custom features.
Code… beautiful code…
Turns out, someone’s already come up with a good solution for us. Trevor Harmon’s Github repo and blogposts got us up and running in no time. He maintains a library that lets you connect your static Gatsby site to Shopify. You can query the Shopify API using GraphQL at build time to create pages for your products, and use the Shopify cart as a backend at runtime. This solution was perfect for us as it lets us customise our user experience while keeping the Shopify product catalogue, cart, and payment processing functionalities.
The core value we foresee adding for our users, apart from aggregation, is a seamless booking experience. We want to amaze team leads with how easily they can book memorable events, compared with the alternative of coordinating with the event supplier through email. To do so, we designed this user experience:
- Select event you’re interested in
- Select time from supplier availability
- Select number of guests
- Checkout and pay
- Automatically receive a calendar invite from the supplier
- Receive a signup link to share with participants
We realised we would need a database or CMS to keep supplier availability, bookings, and participant information. We chose Airtable as a no-code option that offers lots of flexibility and an easy-to-use API.
Exposing availability
For availability, we ask suppliers to send us times during the week where they could guarantee they’d be free, and enter those into Airtable. We wrapped the Airtable API behind our own REST API which lets us perform some custom logic, like crosschecking for already booked times and accounting for lead time.
Handling bookings
To automate the processes following an order, we use Zapier, a fantastic workflow automation tool. Its Shopify integration allows us to send a calendar invite to the purchaser and the supplier after a new order. With the Airtable integration (is there anything these guys don’t integrate with?) we can store the booking within Airtable immediately as well. Side note on Zapier: while it’s a “no-code” tool, it has a Code block which lets you do pretty much anything including hitting an external API! You can pass your results to the following steps in your Zap. We ended up relying on Zapier pretty heavily.
Participant signup
Finally, to allow users to register for an event, we use an Airtable form linked to a Participants table. We need to ensure that signups are capped at the number of guests purchased upfront, and enforce a signup deadline to give suppliers enough time to prepare the event. So we added a signup route to our own API, wrapping the Airtable form. Upon purchase, we send the buyer a link to this route to share with participants. As they try and sign up, we check information from the specific order. If all spots are not already taken and the deadline has not passed, we simply redirect the user to the Airtable form which the participant can fill out.
Au Québec, on parle français
The last piece of functionality we needed was a bilingual site. Living in Quebec, we want to allow both francophone and anglophone companies to host fun team events.
There are a couple ways to build multilingual Gatsby sites, but the best and most straightforward implementation we found was outlined in this blog post. Building multilingual sites in a maintainable way is harder than it looks, but this implementation allows you to define all translations in one document, and elegantly handle routing and switching languages.
There was a bit of custom implementation to resolve conflicts between Gatsby hooks used for translations and Shopify data pulls, but at this point we were salivating for an opportunity to code something custom.
What we did well
We built a fully functional, mostly automated marketplace in 6 weeks, which we are very proud of. Within those six weeks, we also sourced partners for events and spoke to lots of employers. We only spent about 30% of our time coding, and the rest speaking to our users and learning about the market. We think this is a pretty good ratio of the time you should spend building at the start of a venture.
The only way to achieve this was to use open-source code and exploit no-code solutions. We also refrained from building too much before people actually started booking events. There is always time to add bells and whistles if you find that you’re solving a painful problem for your users.
What we can improve
There is a trade off to re-using other people’s building blocks. You save lots of time and resources, but you give up functionality and control. For instance, when we started, we found that the functionality we gave up by using Shopify was too critical to our user experience and we moved away from its beautiful templates.
For some other problems, we chose to save time and implement imperfect solutions. For instance, the downside to using Zapier is that our integrations only pull data every couple of minutes, which could lead to problematic race conditions. Two people could theoretically book events at the same time if they purchase within minutes of each other. But we figured that starting out, the chances of this happening are low enough. If it does become a problem because too many people book events, we’ll have plenty of resources to upgrade our Zapier plan. Similarly, we gave up some control by using Airtable instead of implementing our own database. But for now we feel that the drawbacks are not mission critical, although we may need to revisit them in the future.
What we learned
The no-code revolution is coming. Scratch that, it’s here. We give Zapier and Airtable two thumbs up. Non-technical users can use them easily, and technical folks can extend their functionality quite a bit. Plus, clicking through a beautiful UI gets you off the ground faster than scratching your head over Postgresql CLI commands. We’re technical users and we still prefer a solution like Airtable.
When starting out with an idea, it’s worth looking into existing solutions to your problems, whether they be no-code or open-source code. You won’t wow your end user with thousands of lines of code. You will win them over by showing them how your product makes their life much better. Getting there takes many iterations, and with lightweight code implementations, your turn around time will be much faster.
