-
-
Harmonise Logo
-
App Store Screenshots
-
Month View
-
Week View
-
Plan
-
Create Event
-
Paywall
-
Events List
-
Tasks List
-
Expanded Month View
Inspiration
Making appointments, organising dinner with friends, planning a group event or booking time with someone else. Each of these things all share the same problem: finding a common timing that works for everyone. Current platforms only provide services that solve a part of the problem. Users still have to manually compare calendars, enter availability, copy information across apps and still end up coordinating over messages and/or calls for convenience.
Instead of building another scheduling tool around calendars, we decided to start with a calendar itself. The reasoning for this is that your calendar already contains much of the information needed to understand when your are busy or when you may be available.
The long-term objective is simple: Finding a common timing should feel less like filling out a form and more like pressing a button.
What it does
Harmonise is a calendar-first application that is built around the idea that events and tasks understand each other - tasks can exist independently or be linked directly to an event or recurring event series.
We generally think of Events as activities that occupy a period of time, often including other individuals.
On the other hand, we think of Tasks as activities that needs to be done, often more personal, so a Task can have a Due Date and a Scheduled Date and Time that fits into your timetable.
Your weekly Sunday BBQ with your church members can be a Recurring Event. You can then attach Tasks to each BBQ, such as buying ingredients, marinating your oven-baked chicken or preparing your BBQ Pork Ribs, while deciding separately when you actually want to complete each task before the next BBQ.
How we built it
Our application is built using Expo and React Native. We designed our own UI system while leaving room for native Swift and Jetpack Compose components.
The backend is built with Java and Spring Boot, with PostgreSQL as the application database and Spring Security for server-side authorisation.
Our synchronisation system remains server authoritative while allowing supported clients to maintain durable local replicas for fast reads and offline access.
Challenges we ran into
One of the biggest challenge was defining what an Event and a Task actually means once they are allowed to interact.
A weekly Sunday BBQ may require different preparations across different weeks. Sometimes your church members want your special oven-baked chicken, while on another week, they might want your famous BBQ Pork Ribs.
Initially, linking a task to an event sounds simple. Recurrence is what makes the logic considerably harder. We needed to account of combinations such as:
- Standalone recurring task
- A one-off task linked to a recurring event.
- A recurring tasks that is linked to a recurring event.
- A task attached only from a particular recurring event onwards.
- Individual tasks in a recurring series being completed or customised without affecting every other occurrence. and so on...
Timezone behaviour also added another layer of complexity due to the need to preserve the intended local time of the user. Synchronisation proved difficult as well, especially when keeping events and tasks consistent across multiple devices.
Accomplishments that we're proud of
Much of the stack was self-taught by the two of us. We are proud that we managed to go beyond producing another calendar interface and instead built much of the foundation required for a larger scheduling platform.
We are also working towards web parity with the mobile app. While the web version has yet to launch, we have already designed the system to make its integration easier.
What we learned
We learnt that syncing is not easy.
Specifically, building a calendar is an exercise in edge cases. Timezone matters. Daylight-saving matters. Recurring events are not just \(\text{events} \times \text{no. of occurrences}\).
Building Harmonise forced us to think about optimistic concurrency, snapshots, date calculations and the boundary between server-authoritative data and local cached data.
Those distinctions now form much of the foundation for what we want to build next.
What's next for Harmonise
The next major step for Harmonise is turning the scheduling foundation we have built into the reason the product exists: Making find a common timing dramatically easier.
Rather than asking people to repeatedly fill in forms, our goal is for Harmonise to privately derive the scheduling information needed, reducing the process to a small number of meaningful decisions.
We want to combine optimisation models with on-device language models in the future to help interpret intent and create an engine that would handle the auto scheduling part to reduce friction.
Most importantly, finding a common time should not require exposing everyone's underlying calendars. We want to craft a model that is designed around privacy-shaped availability: the system should determine whether a time works without revealing why someone is unavailable.
From there, we want to expand the same idea beyond friends and meetings into appointments, group planning and eventually interactions between individuals and businesses.
We are also working on integrating pre-existing calendar providers such as Google Calendar, Apple Calendar, Microsoft Outlook and Yahoo Calendar.
Ultimately, we want to compress several messages, calendar checks and scheduling links to become one request and one confirmation while being the calendar that your other calendars report to.
Disclaimer
Harmonise is under active development, and we are continuing to iterate quickly based on testing and feedback as we work toward a broader public release.
Log in or sign up for Devpost to join the conversation.