Introduction

One of the joy’s of building the amigoals platform is that I get to use it myself 😊 , both as a mentor and a mentee!

Hence, I always ask myself, how do we further improve the user flow of approaching a mentor, as a mentee?

One pain points / or area of resistance is the scheduling of the timing’s for the 1:1 call! Usually, the mentor and mentee would shoot each back and forth email until they agreed on a time. Can we improve this?

User Flow / Design

Mentor Set Available Times

We added a setting where the mentor can set at which time’s they are free each week

Mentee can view and book mentor’s available times

Mentee’s can then view which times that the mentor are free

Mentor can view mentee’s pending booking request

Backend Design

We store the available times of each day in minutes

Hence, if the user is free on friday, from 10am to 3pm, the user will have a row with the following

{
  fk_user_id: USER_ID,
  week_day: 5, 
  start_time: 600,
  end_time: 900,
}

CREATE TABLE user_availability (
	id serial NOT NULL,
	fk_user_id VARCHAR(50) NOT NULL,
	week_day int not null,
	start_time int4 NOT NULL DEFAULT 0,
	end_time int4 NOT NULL DEFAULT 1440,
	created_at timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
	updated_at timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
 	PRIMARY KEY (id),
 	FOREIGN KEY (fk_user_id) REFERENCES tbl_user(id)
);

create index user_availability_user_index on user_availability (fk_user_id);

A mentee can view the mentor’s available time for a particular month via the following

Mentee sends the following (with their own timezone)
  mentee_month_start, mentee_month_end

avail_times = []

get available times via:

for each DAY of the month:
  weekday <- getWeekday(DAY)

  availStartTime, availEndTime <- get start and end time from db (base on weekday)

  add (availStartTime, availEndTime) to avail_times

  # NOTE: we need to reconcile the start and end of the months 
  # based on the timezone difference of the mentee and mentor. 
  # this is actually more trivial then aspected 
  # (take the earlier datetime for the start of the month, 
  # and the later datetime for the end of the month)

BUSY_TIMES <- invertIntervals(avail_times)

get all of the mentor's future bookings this month and add it to the BUSY_TIMES

return BUSY_TIMES

BUSY_TIMES is returned to front end as an array of intervals of busy times

Frontend will then render 1 hour blocks that are not contained/overlapping with the BUSY_TIMES

Notes

For this particular feature, we had to add effective unit tests on the backend to test the functionality of the various functions such as

• Get available times
• Invert intervals

Learnings:

The above implementation was a solution that arise at the end of alot of mistakes.

Initial Potential Solutions

calendly.com

What it does: people can integrate their calender. and other people can book their time based on the availability

• Functionality fits our use case,
• Calendly is really easy to use
• API’s for integration looks really promising!

However it’s Not free

calendso.com

opensource version of calendly?

Pros

• Free
• Has zoom, gmail and outlook365 integration

Cons:

• Still in alpha
• Poor Documentation for integration, integration may require hack
• It’s a seperate service from amigoals main backend
• Tech difference: amigoals uses go , calendso uses next.js
• A quick look at the github repo looks like its buggy

implement ourself

Pros:

• Flexible

Cons:

• It’s a large feature?
• Why should we do it ourselves when other’s have implemented it

Mistake

We started trying to integration with calendso because it made the most sense that it was open source and the logic has been implemented alr. However, this was a big failure from a product management perspective:

Scope was too large

By thinking that calendso has all the integration logic inplace, we tried to do all 3 integrations (zoom, gmail and outlook365) in a sprint.

Didn’t understand the system

We viewed calendso as an abstraction/ black box of a booking system that we can just integration and use, instead of truly understanding what we need and what we dont

Overlapping functionalities

Both amigoals and calendso sends email as booking confirmation. As such, we had to reconcile this issue by modifying calendso’s code

Lesson

• Try to release incrementally
• Understand the solution/ system first