Case study: Building a Two-sided Marketplace in Bubble - TaskHer

Codemap expert: Luc Meijer

Project website: https://www.taskher.co.uk/

About TaskHer

The trades industry has a bit of a bad rep regarding gender inequality. The trades industry is dominated by men - nearly 95% of tradespeople worldwide are male. TaskHer is committed to tackling the issue of gender disparity in the trades. It is a platform that connects professional tradeswomen with homeowners who need something done in their homes.

Key Features of the Platform

The TaskHer platform has a few key features:

• Connecting tradeswomen with homeowners
• A dashboard for homeowners
• A dashboard for tradeswomen
• A payment system

The TaskHer platform is a two-sided marketplace: it connects two parties (tradeswomen and homeowners). The platform allows homeowners to find the right tradeswomen via their service finder. The homeowner answers a series of questions regarding the type of service required, their location, etc. Homeowners also receive an immediate quote for their requested service. In turn, tradeswomen in the TaskHer network that are eligible for the job get notified. If a tradeswoman is interested in the task and is available on the dates and times the homeowner suggested, they can accept the job. After the booking has been confirmed, the job appears on both the homeowner's and the tradeswoman's dashboard. TaskHer securely holds the payment until after the work is completed. Once the job is done, TaskHer will complete the payment process and transfer the funds to the tradeswoman.

Choosing the Right No-code Tool

Based on the key features listed above and keeping in mind some additional requirements like sending emails to customers, there are a few important decisions to make about what tools to use for a project like this. The first of which is: what tool should we use to build the platform itself? We see two legitimate options here:

1. Bubble

2. A combination of Webflow, Airtable, and Make/Zapier

Both have their pros and cons. Bubble allows for greater flexibility (primarily on the back-end side of things) and will generally have you run into fewer limitations because you're using just one tool. The second option will allow for greater flexibility in the frontend but will be more demanding on the back-end because you're integrating multiple tools with one another. In addition to running into limitations with synchronization between the tools, you may also run into other limitations that arise from using multiple tools instead of using one single tool.

For this project, we went with Bubble because we felt there was a greater emphasis on the back-end of the project rather than the front-end. Of course, we'd set out to create a beautiful front-end, which would've undoubtedly been easier in Webflow. But since the back-end was more complicated relative to the front-end, we thought it would be best to go with Bubble.

Besides choosing a primary no-code tool to build the platform, there are still some other tools to integrate. For example, Bubble doesn't offer a payment system natively. Nor does it offer a CRM. Both of these are essential for two-sided marketplace platforms like TaskHer. Choosing which payment system and which CRM to use are important decisions, but since they're not the focus of the article, we're not going to go in-depth into what influenced these decisions for this project. We ended up using Stripe and HubSpot, respectively, for this project.

Technical Challenges/Aspects

A well-structured development process is key when building projects (in Bubble). We've worked using the Scrum method, and the process was structured as follows:

1. UI Design

2. Database design & implementation

3. Front-end & back-end development

I can not overstate the importance of having a UI design of the project finished before you start working on the project's development. The UI design brings up many questions about how the platform should work that you will want to have answered before you start developing to prevent being blocked by vague features.

After completing the designs, you can start designing a database structure for the project.

Database Design & Implementation

Designing and implementing a database structure is a crucial part of app development. You must take the time to create a good structure that represents the designs of your project. It's unlikely you will design a database structure that won't change at all throughout the project, but the fewer changes you have to make, the easier the project management will be. Changing a database structure down the line is unfortunate because it can impose many other changes as a result.

Below is an entity-relationship diagram of the TaskHer platform. This diagram depicts the most important tables we have in our Bubble Data tab and how they're related to one another.

Image 1: Entity-Relationship Diagram of the TaskHer Platform

Users

In Bubble, there can only be one table for user management. This means that this user table should cover all roles in the platform. For TaskHer, we have the following roles: admin, homeowner, and tradeswoman. This can get quite messy at times because each role might need to use different data. In our case, the admin needs no other relationships. The homeowner needs a reference to the Booking table and the Service Finder Question table. The tradeswoman needs access to data from the Booking table and the Trade table. 

Both the tradeswoman and the homeowner use the Booking table. However, they don't use the same field in the User table because that could cause issues and could be confusing. In this particular case, the homeowner has a list of Bookings in the User table. The Booking table has a field to indicate which tradeswoman will be taking care of the job, but we'll get to that in a minute.

Trades

The connection to the Trade table is used to indicate which trades a tradeswoman specializes in. Trades have a name and also refer to the Booking Survey Question table, to indicate which is the first question of the service finder for a particular trade.

The Service Finder

To determine which tradeswomen qualify for a particular job, we ask the homeowner a series of questions. This process is called the Service Finder. From a data perspective, the service finder consists primarily of two tables: Service Finder Question and Service Finder Answer. Each question has a set of possible answers. Each answer refers to which question should follow if a particular answer is chosen during the Service Finder. There are many ways to implement a 'dynamic' survey, but we've opted to go this route to optimize for loading speed within Bubble and simplicity of development. Of course, this setup isn't very maintainable since there are many records in both tables that each have references to other records. It would require much (manual) work to change the order or content of the Service Finder. But since the client was relatively certain about the order and content, we've decided to go with this setup.

Bookings, Booking Items & Jobs

TaskHer creates a booking once the homeowner has gone through the Service Finder. This booking is populated with information such as where it should take place, but also of which booking items it consists. A booking item refers to a specific job like replacing a light or installing a new sink. During the service finder, a homeowner can select multiple jobs. Hence there is a separate table for booking items.

Front-end Development

Once you have designed and implemented the database structure (and maybe even populated it with some test data), the next step is to start front-end development as depicted by the UI designs. Front-end development in Bubble can be a bit tedious compared to other more specialized tools like Webflow.

When we started the project, Bubble's new responsive editor wasn't out yet. So, we decided to maintain separate versions for mobile and desktop. In retrospect, we probably shouldn't have done that. Instead, we should've tried a bit better to restructure elements from the design so it would be easier to develop a version that works well both on mobile and desktop.

However, with the release of the new responsive editor, creating responsive web pages in Bubble has become significantly more straightforward and a more pleasant experience.

The first step in implementing the designs should be to head over to the Styles tab in Bubble and recreate the style guide your designer has hopefully created. The style guide will contain various rules for applying and using styling in your project. Recreate the default styles in Bubble before starting development to prevent having to do the work twice or unnecessarily changing things at a later point.

Image 2: The Styling tab for TaskHer

In addition to implementing styles before the actual development of pages, it might be worth creating a separate page in Bubble that holds elements that often occur in the designs. These can be either in the form of reusable components, in which one could argue it would be overkill to have them on a separate page. But if you're working with multiple people, it will be handy to have an overview of frequently used elements on a single page with their names and perhaps descriptions alongside them.

Of course, implementing styles and common elements can be skipped if you're working with a Bubble front-end framework/design system like Frames.

When the front-end is set up, it's time to develop the pages from your UI design. You can choose to focus entirely on front-end development and develop pages that don't have any logic built-in. You can s implement pages while at the same time building the back-end logic that comes with the pages. We decided to build the front- and back-end simultaneously because this allowed us to showcase the progress in the project a lot better to our client.

Back-end Development

Finally, we arrive at the development of the back-end of the platform. In Bubble, most of this will occur in the Workflow tab; some of it might occur when selecting plugins from the Plugins tab.

Bubble's back-end consists of two parts:

1.   The back-end of a page. This part allows you to make 'functional' things happen on the front end. Do you want to save a piece of data that the user has entered in an input field? This is where you'd achieve that. This back-end can only be called upon from the page that the user is currently on.

2.   The back-end that's decoupled from pages. In Bubble this is called Back-end Workflows. This back-end runs irrespective of any page and thus is available to the entire application. If you have workflows that can be used on various pages in your app, this is where you'd place them. Also, if you have anything that you'd like to run on a schedule, you would use a back-end workflow to set that up.

When developing a complex application in Bubble, you'll quickly have lots of workflows on each page. To keep an overview of what every workflow is responsible for, you must give every workflow and each step within the workflow a descriptive name. This name should describe what the workflow/step does or what you're using it for. In addition to proper naming conventions, you can use colors to group workflows that perform similar tasks or are used in similar parts of a page.

During the development of your back-end, it's essential to thoroughly test the workflows you're building. Natively, Bubble doesn't have comprehensive tools for testing them. To ensure your data will be handled and transformed as expected, you should set up views in the Data tab under App data. These views will help you quickly find the correct data.

Image 3: App data views we've created to display booking information quickly

When something goes wrong in your workflow, and you can't figure out what's going wrong, you'll have to resort to the debugger. Rerunning back-end workflows step-by-step can help you understand what's going on in the back-end.

If something goes wrong in a back-end workflow that runs irrespective of pages, you'll have to resort to other debugging methods. Although somewhat cumbersome, you can either create a separate table in Bubble to which you post information that can help you figure out what's going wrong. Alternatively, you can send emails to yourself with relevant information about the workflow you're testing.

Integrating other tools

During the implementation of your back-end, you'll undoubtedly want to send data to other tools you're using. Maybe you're using an external service to send emails or handle payments (like Stripe). The first thing you'll want to do here is to check if there are any plugins in Bubble for your apps. Especially if a plugin is developed by the same company as the tool you're using, you're usually better off using their plugin rather than developing custom workflows.

Lastly, if any of the external services you're using do not have a plugin in Bubble, you'll probably want to use the plugin API Connector to be able to make custom API calls within your back-end to this service its API.

Image 4: The plugins used in the TaskHer project

If you're looking to hire top no-code/SaaS professionals to help you build your own marketplace business, you can learn more and get started at Codemap - world's 1st platform for elite no-code talent.

The process is easy! First, use our smart brief to describe your project. Next, upload it to the Codemap platform and start receiving proposals from freelancers or agencies within as little as 20 minutes. You can also screen the profiles and portfolios of our experts and request quotes when desired. 

Once you have decided on the right fit for your project, simply accept the offer and get started. Launch your next app in a matter of weeks!