Building in Public: Decisions We Made (and Reversed) This Quarter

Transparency is not just a marketing word

Building a product involves making dozens of decisions every week. Some of them are right. Some of them are wrong. And the only way to find out which is which is to ship, observe, and adjust. This quarter, we made several decisions that seemed smart at the time but did not survive contact with reality. Here is what happened.

The feature we built and then removed

We built a "smart scheduling" feature that would analyze your calendar patterns and suggest optimal times for new meetings. The idea was solid: manyCalendars already knows when you are busy across all calendars, so why not recommend windows that minimize context-switching and maximize focus time?

We shipped it. Users tried it. And the feedback was clear: it was too opinionated. The algorithm would suggest Tuesday at 2 PM for a client call, but it did not know that Tuesday afternoons were informally reserved for a different client's ad-hoc requests. It did not know that you prefer morning meetings with East Coast clients and afternoon meetings with West Coast clients. It did not know that your "free" slot at 11 AM was actually when you eat lunch at your desk.

The suggestions were technically correct but practically wrong. And a wrong suggestion is worse than no suggestion, because users spent time evaluating and dismissing recommendations instead of just picking a time themselves. We pulled the feature after three weeks. It might return someday with better personalization, but for now, we decided that manyCalendars should show you the data and let you make the decision.

The pricing change we considered and rejected

We explored switching from a flat monthly fee to usage-based pricing: free for up to 3 calendars, then $3/month per additional calendar. The logic was that heavier users get more value and should pay proportionally.

We modeled it out. For the average user (3-4 calendars), the cost would have been roughly the same. For power users (6+ calendars), it would have been more expensive. And that felt wrong. Power users are our most valuable advocates. They are the ones who recommend manyCalendars to other multi-client professionals. Penalizing them for being exactly the audience we built this for seemed like a strategic mistake.

We also realized that usage-based pricing creates a perverse incentive: users might avoid adding a calendar to avoid the cost, which defeats the purpose of a unified view. If someone hesitates to add their fifth calendar because of a pricing tier, we have failed at our core value proposition.

The flat fee stays. Add as many calendars as you need. That is the point.

The technical approach we tried and abandoned

We spent two weeks exploring whether we could use a Service Worker to keep ICS feeds syncing in the background, even when the manyCalendars tab was not open. The idea was compelling: instead of relying on the user to have manyCalendars open for feeds to refresh, the Service Worker would periodically fetch ICS URLs and update the local cache.

The implementation worked in testing. Then we hit reality. Browser vendors have been progressively restricting Service Worker capabilities to conserve battery and prevent abuse. Chrome limits background sync frequency. Firefox kills long-running Service Workers aggressively. The behavior was inconsistent across browsers and versions, which meant we could not guarantee reliable background sync.

Worse, debugging Service Worker issues is painful for users. When something goes wrong, there is no visible error. The feed just quietly stops updating. Diagnosing whether the problem is the Service Worker lifecycle, the browser's throttling, or an actual network issue would have generated support tickets we could not easily resolve.

We abandoned the approach. ICS feeds sync when manyCalendars is open. It is less magical but more reliable, and reliability wins over magic every time.

Why we share this

Building in public means showing the process, not just the polished result. Every removed feature represents learning. Every rejected pricing model represents a values decision. Every abandoned technical approach represents respect for the user's experience over the developer's ambition.

manyCalendars is a better product because of the decisions we reversed, not in spite of them. We would rather ship something we are confident in than something that is merely impressive on a feature list.

Want to use a product built by people who care more about getting it right than getting it shipped? That is a low bar, honestly, but you would be surprised how many tools fail to clear it. Try manyCalendars. If we build something that does not work for you, we will be the first to admit it. Apparently, we have a track record.