The week my calendar app stopped being just mine
I built Calendula for myself. I wanted a fast, good-looking, privacy-respecting calendar that didn’t own my data, couldn’t find one, and so I made one. For a while that was all it was: my app, my phone, my taste.
Then people showed up. Not many, not all at once — but enough, in about two weeks, that the project stopped feeling like a thing I have and started feeling like a thing I’m responsible for. This is a note about that shift, because nobody tells you how quickly it happens.
From requests to a rhythm
The first issues were classic solo-dev fare: someone asked for a setting to choose which view the app opens on. I shipped it in v2.9.0 within hours, and “that was quick!” came back. Then a tappable month grid; then a Saturday week-start — each one small, each one turned around fast. Then: limit the agenda view to today, or this week, or the next 30 days — and here the exchange got interesting, because I stopped just building the literal request and started asking what options would you actually want, and we designed it together in the thread.
That rhythm — report, discuss, ship, “thank you” — is the engine of a small open project. It’s also a trap if you let it: not every request should be built. The hard skill isn’t saying yes fast, it’s saying no well, and keeping the app inside its lane while the person still leaves happy.
The moment it gets real
There’s a specific sentence that changes how you feel about a side project. Mine arrived on an issue about registering an intent filter, from someone who’d hit a papercut on GrapheneOS:
I have been looking out for a well-designed and fast calendar since switching to Android four years ago and your software seems to be on point.
Four years of waiting. That’s the kind of line that reframes a side project — someone who’s been holding out for exactly this and is ready to depend on it. The same thread is where I admitted a limitation honestly (there’s no Android API to set yourself as the default calendar, so no in-app button is possible — only the system picker), and that honesty landed better than a workaround would have. Relied-upon software is built on trust, and trust is mostly just not overpromising.
When users become co-designers
The real tell that a community is forming isn’t traffic — it’s when people start doing the thinking with you, not just the reporting.
On a request to make the view quick-switch button configurable, the conversation turned into an actual design debate: should reordering live in a settings tab, or should you long-press and drag items in place? Would drag-in-place cause accidental reordering? We went back and forth on the interaction, not the feature. On the contact-birthdays feature, a user who wasn’t even the original reporter created test contacts — one Google, one CardDAV — to help me isolate why some birthdays showed up and others didn’t. That’s not filing a bug. That’s debugging with me.
I don’t have a big community. I have a handful of people who care about a good calendar as much as I do, and who’ve started treating its rough edges as our problem. That’s the shift.
The unglamorous parts, on purpose
None of this is a highlight reel. In the same fortnight I shipped a release that mangled the month widget’s switching buttons — a regression a user caught and I had to go dig out of a recent change. The birthday feature still doesn’t handle every account type. Writing this, I could have quietly left those out. But the point of doing this in the open, on a public tracker, is that the reasoning and the mistakes are all readable — the terse “closed” label replaced by an actual conversation anyone can follow later.
A project stops being just yours the moment someone else would notice if it broke. Calendula crossed that line quietly, in a week of issue threads, and it changed how I write every commit since. The question stopped being “does this please me” and became “would I want to explain this decision to the people in the comments.” The second one is the one worth answering.