Open-Source Minded, Self-Funded, and Staying That Way

Why we did not raise money

Venture capital is a specific tool for a specific kind of business. It makes sense when you need to scale infrastructure rapidly, hire a large team, and capture a market before competitors do. It does not make sense when your product has near-zero infrastructure costs, works best as a small focused tool, and serves a niche audience that values privacy above growth.

manyCalendars is a browser extension. It has no servers to scale. It has no database to migrate. It has no cloud infrastructure bill that grows with user count. The marginal cost of a new user is effectively zero, because all the computation and storage happens on the user's own device.

Raising venture capital would have created pressure to justify the investment. That pressure typically manifests as: add a server-side component (to create a moat), collect user data (to monetize or improve retention metrics), raise prices aggressively, or pivot to enterprise sales with long contract cycles. Every one of those moves would make manyCalendars worse for the people who actually use it.

Incentive alignment is not abstract

When a company is funded by its users, the incentive is simple: make the product good enough that people keep paying for it. Ship features users ask for. Fix bugs quickly. Do not break things that work.

When a company is funded by investors, the incentive shifts. Growth metrics matter more than user satisfaction. Monthly active users, retention curves, and expansion revenue become the priorities. Features get built to drive engagement metrics, not because users need them. The product becomes a vehicle for the business model rather than the other way around.

This is not cynicism. It is the documented pattern of nearly every VC-backed productivity tool over the past decade. The product is great at launch, adequate at Series B, and loaded with upsells and dark patterns by Series C. The word for this process has entered the vocabulary: enshittification.

We are choosing not to play that game.

Auditable code and why it matters

Browser extensions are distributed as JavaScript. Unlike compiled desktop applications or server-side SaaS products, the code that runs in your browser can be inspected directly. You can read it. You can verify that it does what we claim. You can confirm that it does not send data to external servers.

We think this is a feature, not a vulnerability. When we say "your calendars are read and merged on your device, not in our cloud," you do not have to take our word for it. You can check. Security researchers can check. Your company's IT team can check. The code is the documentation.

This is what "open-source minded" means for us. The code is inspectable and auditable. We build in the open, even if the license is not a traditional open-source license. Transparency is the point.

What "sustainable" looks like at near-zero cost

Traditional SaaS sustainability requires enough revenue to cover server costs, employee salaries, office space, and investor returns. The number is large. A small SaaS company might need $50,000 per month just to keep the lights on. That creates pressure to grow the user base, raise prices, or cut costs in ways that affect quality.

manyCalendars's cost structure is different. No servers. No cloud infrastructure. No large team. The ongoing costs are: Chrome Web Store developer fee (a one-time payment), domain registration, and the time spent building and maintaining the product. The sustainability threshold is correspondingly low.

This means manyCalendars does not need to become a different product to survive. It does not need to add a server-side component to justify higher pricing. It does not need to chase enterprise contracts to hit revenue targets. It can stay exactly what it is: a focused, private, local-first calendar tool that does one thing well.

A commitment, not a promise

Promises are easy to make and easier to break. So instead of promising anything, we will describe the structural constraints we have chosen:

No investors to satisfy. No board to report to. No growth targets that require compromising the product. No server infrastructure that creates incentives to collect data. No dependency on a business model that conflicts with user privacy.

These are not just principles. They are architectural decisions baked into how the product works. You cannot enshittify a product that has no server to add trackers to, no user accounts to gate features behind, and no data to sell.

We built manyCalendars because we needed it. We are funding it because we use it. And we are keeping it exactly the way it is because the moment we change it, we lose the thing that makes it worth using. Install manyCalendars and support the kind of software you wish existed more often.