Tools We Actually Use to Run This Company

Why we are sharing this

We sell a privacy-focused product. It seems only fair to show what our own operation looks like under the hood. The short version: it is small, it is deliberate, and it does not track you.

Static site hosting

This marketing site is static HTML, CSS, and a bit of JavaScript. No frameworks. No build step. No server-side rendering. We host it on Cloudflare Pages because the free tier is generous, the CDN is fast, and we do not need anything more complex. The entire site deploys from a Git push in under 30 seconds.

We chose static hosting deliberately. No server means no server logs capturing your IP address, no session cookies, no server-side tracking of any kind. The site loads fast, works offline after the first visit, and does not phone home.

Payments: Stripe

Stripe handles all payment processing. We use Stripe Checkout for the purchase flow, which means your credit card details go directly to Stripe and never touch our infrastructure. License keys are generated and delivered via Stripe's webhook system.

We chose Stripe because it is the standard for a reason: PCI compliance handled, fraud detection built in, and a clean API. We do not store payment information. Stripe does. We store a customer ID and license key, and that is it.

Email support

Support runs through a shared inbox. No ticketing system. No CRM. When you email us, a human reads it and responds, usually the same human who wrote the code you are asking about. The median response time is under 4 hours during business hours.

We considered helpdesk software and decided against it. At our current volume, a shared inbox is simpler, faster, and does not require us to hand your email address to a third-party ticketing platform.

Browser testing

The extension is tested manually across Chrome, Edge, and Brave on Windows, macOS, and Linux. We use BrowserStack for cross-platform testing when we cannot reproduce an issue locally. Automated tests cover the core logic (conflict detection, ICS parsing, event normalization) but UI testing for a browser extension is still largely a manual process.

We also dogfood the product aggressively. The person building manyCalendars uses manyCalendars to manage their own multi-client calendar. Bugs get found fast when the developer is also the user.

Analytics: none

We do not run Google Analytics, Plausible, Fathom, or any other analytics tool on this site. No tracking pixels. No session recording. No heatmaps. We do not know how many people visit this page, how long they stay, or where they click.

This is a deliberate choice, not an oversight. We build a privacy tool. Running analytics on our marketing site would undermine the thing we are selling. We know our product is working when people buy licenses and when support volume stays manageable. Those are the only metrics that matter.

What we do not use

No CRM. No marketing automation. No retargeting ads. No affiliate program. No A/B testing framework. No chatbot. No "can I help you?" popup. No cookie banner (because there are no cookies to consent to).

We are a small team building a focused product for a specific audience. The toolstack reflects that. Every tool earns its place by solving a real problem, not by looking good on a "tech stack" blog post.

Speaking of focused products for specific audiences, manyCalendars is built the same way. No bloat, no tracking, no complexity you did not ask for. Just your calendars, in one place, on your machine.