Why does the world need another calendar app?
It probably doesn't.
Google Calendar exists. Apple Calendar exists. Fantastical, Cron, cal.com, Notion Calendar — the list goes on. I know this. I thought about it for a while before starting anyway.
Here's what I kept coming back to: every calendar I use is a closed island. My reminders live in one place, my tasks in another, my notes somewhere else. And when I want to connect them — run something when an event is created, push a notification to a custom channel, sync with an internal tool — I'm either stuck with whatever integrations the app decided to support, or I'm duct-taping Zapier between everything.
What I actually want is a calendar that behaves like infrastructure. One where the plugin system isn't an afterthought — it's the point.
That's the idea behind We Remember (結繩記事 in Chinese — after the ancient practice of tying knots in rope to remember things).
The name
In ancient China, people tied knots to record events — each knot a small, physical piece of memory. The practice is called 結繩記事 (jié shéng jì shì).
The "we" in We Remember was always intentional. Not just personal memory — collective memory. Every plugin, every integration, is a knot anyone can tie. The end goal is a web of memory that isn't locked inside one app.
That's a long-term vision. For now: it's me, a laptop, and Django.
What I'm actually building
The core is straightforward: a calendar with a solid reminder engine and a clean way to connect it to other things. Events, recurrence, notifications — the basics done well.
The part I care most about is keeping it open by design. Not open source necessarily, but open in the sense that it shouldn't be a dead end. Whatever I build, I want other tools to be able to talk to it.
Milestone 0.1 — Infrastructure Foundation
Before any feature ships, I want a production environment that's solid and boring. This is the milestone I just finished planning.
Done when:
- The app runs locally and on a VPS with a single command (Docker Compose)
- Every push passes CI and triggers an automatic deploy via GitHub Actions
- A
/healthendpoint returns app and database status - The environment is fully reproducible from scratch following the README No features in this milestone. Just a foundation that won't need to be rebuilt later. The interesting part — what actually happened versus what I planned — comes in the next post.
What build in public means to me
Build in public, for me, means sharing the process: the decisions, the tradeoffs, the things I got wrong, the things that turned out surprisingly well.
I'm a student learning product, design, writing, and business alongside technical skills. I'm not following a weekly cadence — I'll write when a milestone closes or a decision is worth documenting. Quality over consistency.
So that's what I'll do. X threads for small updates and decisions. dev.to for milestone retrospectives.
What's next
Implementing milestone 0.1. When it's done and deployed, I'll write about what actually happened versus what I planned — the interesting part of any milestone is always the gap between the two.
If you're building a side project as a learning vehicle, I'd love to hear how you think about sequencing your first milestones. And if you want to follow along, I'll be posting updates as things develop.
The knots are just getting tied.
We Remember (結繩記事) — a calendar platform built around a plugin ecosystem. Building in public as a student learning product development end-to-end.