After a decade of software engineering work (professional and personal), particularly in front-end development, I’ve crafted something I’m proud of. In this article, I’ll walk you through my ideal tech stack and the intricate decisions that shaped MeetMomentum. Join me as we explore the nuts and bolts of building a tool designed to revolutionize how we manage time across global time zones. Project Overview In today’s connected world, tools to track global timezones aren’t just a necessity; they’re a lifeline for professionals and travellers alike. Unfortunately, most calendar solutions do not offer effective multi-time zone support when scheduling and I personally faced many struggles because of this. That’s how I started to come up with the MeetMomentum vision. I wanted to build something that truly accounts for infinite time zones, visually and intuitively. I also wanted to make sure it integrates with my existing calendar, so I don't have to look at multiple screens just to book a single meeting. Design The design was one of the biggest challenges. There is a good reason why most applications don't support more than two time zones. It is not possible to fit all that information, in a digestible manner. At least not with the existing approach. The existing approach is having all five days aligned and invitees’ agendas overlapping. Instead, we flipped the calendar view on it’s side, presenting each invitee's schedule on their own horizontal line, offset by their unique time zone. To navigate the calender users can simply swipe or scroll horizontally, and by maintaining the offset, we ensure perfect time zone alignment, in a very clean manner. This is the core of our innovation, however, it came with a surprising set of technical challenges! Have a play on the final outcome here: https://www.meetmomentum.tech/ Technical Stack Before diving any deeper, let's start by painting the landscape. Embarking on any software project requires a solid foundation, and the technical stack is where it all begins. In the development of MeetMomentum, choosing the right technologies was crucial to ensure flexibility, efficiency, and scalability. Programming Languages Used: TypeScript/JavaScript


CSS


Markdown/MDX for the blog Frameworks and Libraries: We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used Framer Motion for more custom animations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. TRPC for simple server-client connectivity. Zod for validation of data inputs. react-hook-form for user input with its great integration with zod. Tools and Development Environment: Currently, we’re just using npm but might lean into pnpm. We use prettier for formatting. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Nix is used to provide dependencies outside of node_modules. Stripe dev cli. Architecture Overview: The architecture leans serverless. Being on Vercel, we leverage functions for our serverside compute. As we use supabase, we can also utilize PostgREST and Row Level Security (RLS) to directly and securely access data in the database. And being React on NextJS we can lean into SSG and client-side processing. Database Management: As mentioned above the database is Postgres on Supabase with RLS and PostgREST being key plugins. Server Infrastructure: Hosting on Vercel. Design Patterns: Design patterns such as MVC don’t really map onto React very well. The general approach is to keep the state as close to where it’s used so updates are only triggered for relevant areas of the page. Optimizations can be made in cases where updates are triggered but inputs have not meaningfully changed. State that is important across the application is handled via Zustand. In some cases, components are split into the part that handles and provides state, and the part that is visual with elements and styles. This can help to build out the component’s style and debug without needing to replicate the exact state in a more real-world scenario. However, sometimes it’s easier to have a combined component just to get something finished. Continuous Integration/Continuous Deployment (CI/CD): Vercel integration with GH runs ‘build’ and we run most of our linting and tests as part of that build. With a focus on SSG and client-side processing server-side compute is reduced. The vast majority of server-side compute is tied to accounts that can be managed carefully, and Vercel has capabilities to defend against abuse such as a DDoS attack. So, in general, the platform should scale very well without much intervention. There is room to improve some actions so we can leverage caching more or consolidate some requests but these are not of high concern until we reach much larger scales and can be worked on in the background. Major Challenges As mentioned before, one of the biggest challenges was building the horizontal scroll for the scheduling offsets. This would technically be called an ‘infinite horizontal scroll sync,’ and it seems like we were the first use case for it! The reason why it was so challenging was managing the browsers’ performance while triggering many browser events due to scrolling and lining up timezones accounting for their offsets. Keep in mind that each horizontal line had to be kept independent, as the user could at any point change the order with our ‘drag and drop’ features. And to make things harder for ourselves, we also had multiple time pickers that worked by aligning the exact position of the scroller. We tried multiple approaches, like having individual hour elements, and had to restart on at least four different occasions. But the result was worth it! Another major challenge was transitioning from the public scheduler to a personalized one, that integrates with your agenda. This time, the problem lies in trying to fit the agenda-related information into a small horizontal view. To get to our fleshed-out product, we had to undertake a lot of iteration, trial and error, and of course, user feedback! We also faced multiple technical challenges, such as integrating with the Google Calendar APIs, getting permission to handle user’s data, and so on. Outcomes User feedback for MeetMomentum.tech has been very positive. Users enjoy the convenience and creativity aspects, but we are still very early in our journey. Stay tuned as we evolve, enhancing MeetMomentum.tech to better serve you and the global community; one update at a time. After a decade of software engineering work (professional and personal), particularly in front-end development, I’ve crafted something I’m proud of. In this article, I’ll walk you through my ideal tech stack and the intricate decisions that shaped MeetMomentum. Join me as we explore the nuts and bolts of building a tool designed to revolutionize how we manage time across global time zones. Project Overview In today’s connected world, tools to track global timezones aren’t just a necessity; they’re a lifeline for professionals and travellers alike. Unfortunately, most calendar solutions do not offer effective multi-time zone support when scheduling and I personally faced many struggles because of this. That’s how I started to come up with the MeetMomentum vision. I wanted to build something that truly accounts for infinite time zones, visually and intuitively. I also wanted to make sure it integrates with my existing calendar, so I don't have to look at multiple screens just to book a single meeting. Design The design was one of the biggest challenges. There is a good reason why most applications don't support more than two time zones. It is not possible to fit all that information, in a digestible manner. At least not with the existing approach. The existing approach is having all five days aligned and invitees’ agendas overlapping. Instead, we flipped the calendar view on it’s side, presenting each invitee's schedule on their own horizontal line, offset by their unique time zone. To navigate the calender users can simply swipe or scroll horizontally, and by maintaining the offset, we ensure perfect time zone alignment, in a very clean manner. This is the core of our innovation, however, it came with a surprising set of technical challenges! Have a play on the final outcome here: https://www.meetmomentum.tech/ https://www.meetmomentum.tech/ Technical Stack Before diving any deeper, let's start by painting the landscape. Embarking on any software project requires a solid foundation, and the technical stack is where it all begins. In the development of MeetMomentum, choosing the right technologies was crucial to ensure flexibility, efficiency, and scalability. Programming Languages Used: Programming Languages Used: TypeScript/JavaScript CSS Markdown/MDX for the blog TypeScript/JavaScript TypeScript/JavaScript CSS CSS Markdown/MDX for the blog Markdown/MDX for the blog Frameworks and Libraries: Frameworks and Libraries: We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used Framer Motion for more custom animations. We used Framer Motion for more custom animations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. TRPC for simple server-client connectivity. TRPC for simple server-client connectivity. Zod for validation of data inputs. Zod for validation of data inputs. react-hook-form for user input with its great integration with zod. react-hook-form for user input with its great integration with zod. react-hook-form for user input with its great integration with zod. Tools and Development Environment: Tools and Development Environment: Currently, we’re just using npm but might lean into pnpm. Currently, we’re just using npm but might lean into pnpm. We use prettier for formatting. We use prettier for formatting. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Nix is used to provide dependencies outside of node_modules. Nix is used to provide dependencies outside of node_modules. Stripe dev cli. Stripe dev cli. Architecture Overview: Architecture Overview: The architecture leans serverless. Being on Vercel, we leverage functions for our serverside compute. As we use supabase, we can also utilize PostgREST and Row Level Security (RLS) to directly and securely access data in the database. And being React on NextJS we can lean into SSG and client-side processing. Database Management: Database Management: As mentioned above the database is Postgres on Supabase with RLS and PostgREST being key plugins. Server Infrastructure: Server Infrastructure: Hosting on Vercel. Design Patterns: Design Patterns: Design patterns such as MVC don’t really map onto React very well. The general approach is to keep the state as close to where it’s used so updates are only triggered for relevant areas of the page. Optimizations can be made in cases where updates are triggered but inputs have not meaningfully changed. State that is important across the application is handled via Zustand. In some cases, components are split into the part that handles and provides state, and the part that is visual with elements and styles. This can help to build out the component’s style and debug without needing to replicate the exact state in a more real-world scenario. However, sometimes it’s easier to have a combined component just to get something finished. Continuous Integration/Continuous Deployment (CI/CD): Continuous Integration/Continuous Deployment (CI/CD): Vercel integration with GH runs ‘build’ and we run most of our linting and tests as part of that build. With a focus on SSG and client-side processing server-side compute is reduced. The vast majority of server-side compute is tied to accounts that can be managed carefully, and Vercel has capabilities to defend against abuse such as a DDoS attack. So, in general, the platform should scale very well without much intervention. There is room to improve some actions so we can leverage caching more or consolidate some requests but these are not of high concern until we reach much larger scales and can be worked on in the background. Major Challenges As mentioned before, one of the biggest challenges was building the horizontal scroll for the scheduling offsets. This would technically be called an ‘infinite horizontal scroll sync,’ and it seems like we were the first use case for it! The reason why it was so challenging was managing the browsers’ performance while triggering many browser events due to scrolling and lining up timezones accounting for their offsets. Keep in mind that each horizontal line had to be kept independent, as the user could at any point change the order with our ‘drag and drop’ features. And to make things harder for ourselves, we also had multiple time pickers that worked by aligning the exact position of the scroller. We tried multiple approaches, like having individual hour elements, and had to restart on at least four different occasions. But the result was worth it! Another major challenge was transitioning from the public scheduler to a personalized one, that integrates with your agenda. This time, the problem lies in trying to fit the agenda-related information into a small horizontal view. To get to our fleshed-out product, we had to undertake a lot of iteration, trial and error, and of course, user feedback! We also faced multiple technical challenges, such as integrating with the Google Calendar APIs, getting permission to handle user’s data, and so on. Outcomes User feedback for MeetMomentum.tech has been very positive. Users enjoy the convenience and creativity aspects, but we are still very early in our journey. Stay tuned as we evolve, enhancing MeetMomentum.tech to better serve you and the global community; one update at a time.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

How I Built MeetMomentum: Applying 10 Years of React Experience

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Comprehensive Guide to Choosing the Right Tech Platform for Neo Banks and FinTech Enterprises

Fullstack Ethics: Privacy Can't Be Just a Luxury Good

How a First Time CTO Can Choose the Right Techstack for Their Startup

How to Choose the Right Web Tech Stack

How to Optimize for Iteration: Choosing Your Early Startup's Tech Stack

PSA: Selecting Your Tech Stack Is Not The Most Important Part

A Comprehensive Guide to Choosing the Right Tech Platform for Neo Banks and FinTech Enterprises

Fullstack Ethics: Privacy Can't Be Just a Luxury Good

How a First Time CTO Can Choose the Right Techstack for Their Startup

How to Choose the Right Web Tech Stack

How to Optimize for Iteration: Choosing Your Early Startup's Tech Stack

PSA: Selecting Your Tech Stack Is Not The Most Important Part

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps