What We Are Building Next (H2 Roadmap Preview)

Transparency is the point

We are publishing our roadmap because we believe you should know where your tools are headed. Too many products ship features in silence and sunset them the same way. We would rather tell you what we are planning, get your input, and be accountable for delivery.

Everything below represents our current priorities for the second half of 2026. Timelines are estimates, not promises. If something ships early, great. If something needs more time to get right, we will take it. Quality over speed, always.

Improved recurring event support (July-August)

Recurring events are deceptively complex. A weekly standup that gets rescheduled for one week, cancelled for another, and moved to a new time permanently starting next month creates a tangle of exceptions that calendar providers represent inconsistently.

Our current recurring event handling works well for simple patterns but struggles with heavy exceptions. The H2 work focuses on correctly parsing and displaying RRULE exceptions from ICS feeds, handling recurring event modifications in synced calendars, and ensuring conflict detection evaluates each individual occurrence rather than the pattern.

This is the most-requested fix from our community roundtable, and it is our top priority for the summer.

Calendar sharing between manyCalendars users (August-September)

This is the feature that moves manyCalendars from a solo tool to a collaborative one. The concept: you share a masked version of your unified calendar with another manyCalendars user. They see your busy/free status across all your calendars without seeing the details. They can overlay it with their own unified view to find mutual availability.

The technical challenge is doing this without a server. Our current design uses encrypted peer-to-peer sharing via WebRTC, with the shared calendar state living in both users' local storage. No central server ever sees the data. This is harder to build than a simple API, but it preserves the local-first principle that defines manyCalendars.

Initial release will support sharing between two users. Group sharing (three or more) comes later, pending feedback on the initial implementation.

Mobile companion view (September-October)

We are not building a full mobile app. That would be a different product with different constraints. Instead, we are building a lightweight mobile companion: a PWA that syncs with your desktop manyCalendars instance and shows today's events, upcoming conflicts, and your availability at a glance.

The sync mechanism uses the same local-first approach as the rest of manyCalendars. Your phone connects directly to your desktop browser (when both are on the same network) or syncs via an encrypted local relay. No cloud storage, no account, no server-side data.

The mobile view is read-only at launch. You cannot add or edit calendars from your phone. That keeps the scope manageable and the experience reliable. If users want mobile editing, we will consider it for 2027.

Smarter conflict resolution suggestions (October-November)

Today, manyCalendars tells you that two events conflict. In H2, it will also suggest what to do about it. Based on event metadata (which event was booked first, which has more attendees, which is recurring versus one-off), manyCalendars will offer resolution suggestions: "This is a 1:1 that has been rescheduled twice. The other event is a team standup with 8 people. Consider moving the 1:1."

These suggestions are advisory, never automatic. manyCalendars will never reschedule or decline events on your behalf. But giving you a suggested action alongside the conflict flag reduces the cognitive work of resolving it.

API for power users (November-December)

Some users want to integrate manyCalendars data into their own workflows. A local API (accessible only from localhost) will expose read access to your unified calendar, conflicts, and availability. This lets power users build custom dashboards, feed manyCalendars data into scripts, or connect it to automation tools.

The API is local-only. It does not expose data over the network. It does not require authentication beyond being on the same machine. It is designed for developers who want to extend manyCalendars, not for third-party services to access your data.

That is the plan. Now help us prioritize.

These five items are our H2 focus. But within that set, sequencing is flexible. If you have strong opinions about what should ship first, tell us. The community roundtable, the feedback form in the extension, and our Discord are all places where your voice directly influences what we build next.

And if you are reading this thinking "I should probably try this tool before I weigh in on its roadmap," you are right. Install manyCalendars for free, kick the tires, and then tell us what it is missing. The roadmap is better when the people who use the tool help write it.