Your calendar is a database with only two columns

We don't think of a calendar as a database.

We think of it as a tool for checking what's next, for not forgetting appointments, for laying a day out in hourly blocks. But look at it slightly differently and a calendar is close to the oldest personal database most of us keep.

Every day you add new records, edit times, set recurrence rules, and search old entries. You maintain it more consistently than any database you've ever touched — and you do it without a second thought.

The problem is that this database has an almost embarrassingly thin schema.

For most calendar events, the fields you can actually fill in come down to two:

time
title

You can add a description if you want, but that's just a free-form text box.

A calendar records when you intended to do something. It does not record, as structured data, whether the thing actually got done, which project it belonged to, how focused you were, whether it needs to happen again, or how you'd rate that time in hindsight.

Calendars are exquisitely precise about time and strangely indifferent to what that time meant.

So you end up recording the same day more than once

For a long time I split my day across tools.

Plans went into Google Calendar. Project status and reviews went into Notion. Stray thoughts went into Obsidian. To-dos lived in a separate task manager. For a while I even kept a paper bullet journal.

Each tool was good on its own. The problem showed up after the day was over.

I'd look at my calendar to remember what I'd actually done, copy completed items into another doc, write up what came out of a meeting, and note why the plan and the reality had diverged.

I was recording time I had already recorded once.

Say I did product development from 2 to 4 PM. That fact already exists in my calendar. But to write a weekly review, I have to reopen that event and move information like this somewhere else:

• Did I actually finish it?
• Which project does it belong to?
• Was it deep work?
• Did it take longer than expected?
• Am I happy with the result?
• Does it need a follow-up?

If that data had lived on the event from the start, there'd be nothing to move.

We don't hate recording things. What we can't stand is recording the same fact over and over in different formats.

A calendar only has an x-axis

It helps to think of a calendar as a coordinate system. The first axis is time.

x-axis: when did it happen

This is the axis calendars are great at.

They express when an event starts and ends, how long it lasts, whether it repeats, whether it overlaps with something else. The interface for dragging events along the timeline and resizing them has been refined for decades.

But the content of an event collapses into a single line of title text.

10:00–11:00  Weekly meeting
11:00–13:00  Product development
14:00–15:00  Client call

Precise about time, poor about everything else. That's where a second axis comes in.

y-axis: what was that time

Add structured properties to an event and the same block of time becomes far richer data.

Title:      Product development
Project:    Velprium
Status:     Done
Type:       Deep work
Energy:     High
Rating:     4
Follow-up:  Fix onboarding copy

Now the calendar isn't a schedule — it's a record you can analyze.

How many hours went to product work this week. What share of meetings turned into an actual follow-up. Which times of day you were most focused.

You could write all of that into a free-form note. But information buried in prose is hard to aggregate or filter. You need structured properties to compare many events against a single dimension.

At first I thought this was the whole answer: put the time on the x-axis, add properties on the y-axis, done. But building the actual product surfaced a third problem.

z-axis: which lens are you looking through

The same event wants to look different depending on the moment.

On Monday morning I want to see it as a plan.

What should I do?

While I'm working I want to see it as execution.

What am I doing now?

On the weekend I want it as material for reflection.

What actually happened?

Same data, different question.

Most tools build a separate screen and a separate data structure for each of these. Plans go in the calendar, execution in a task manager, reflection in notes or docs.

But these aren't three different pieces of data. They're the same time viewed through different lenses.

That's when I stopped believing time and properties were enough. I needed a third axis — a way to look at the same time data as planning, doing, journaling, or reviewing.

Three times I tried to make "task" its own entity

I didn't arrive at that cleanly.

My first design made calendar events and tasks separate things. An event is a schedule; a task is a to-do; surely they should be different entities. Logically it looked natural.

Then I started implementing, and the questions piled up:

• A task placed at 2 PM — is it an event or a task?
• If I move an unfinished event to tomorrow, does it become a task?
• Between a calendar event and its linked task, which one is the source of truth?
• If I change the event's time, should the task's scheduled time change too?

The state and sync rules needed to hold the two together kept multiplying.

I rebuilt the task model. Then I deleted it. I renamed the entities and their relationships and built it a third time — and landed back on the same problem.

It wasn't failing because the model was complex. It was failing because I was artificially splitting one piece of time into two pieces of data.

"Product development" can be a plan and a to-do at the same time. It can be work in progress, and once it's done it becomes a record of the day. The object isn't changing — the perspective I'm looking at it through is.

Instead of endlessly patching a separate task entity, it was far more natural to add status, properties, and perspective to the event itself.

Why I couldn't see this two years ago

I tried to build something similar about two years ago.

Back then I approached it by bolting features onto an existing calendar one at a time. Add a to-do list. Add a logging screen. Attach some stats. Each feature worked, but the whole thing kept getting more complicated — because every feature had its own data model.

Plan data and actual records split apart. Tasks and events split apart. Review data spun off into yet another place. I wanted users to avoid entering the same thing twice, while internally I was duplicating the same fact across several tables.

The more features I added, the blurrier the product's center got.

At the time I told myself I stopped because I ran out of dev time. Looking back, time wasn't the only problem. I didn't have a conceptual model that could hold the whole product together.

Before deciding what else to build, I should have decided what to treat as a single piece of data.

What paper bullet journaling taught me

The interesting thing about a paper bullet journal is that recording and planning are never fully separated.

An item you didn't get to today gets a changed mark and migrates to the next day or the next month. A finished item stays as a record. One line is a plan, then a status, and later a piece of the past.

Digital tools usually split that arc into different objects. You create a task, place it on the calendar, complete it, and then rewrite it into a review doc. On paper, only the symbol next to the item changes. In software, the data travels between tools.

I used to think of bullet-journal migration as a tidy little habit. Designing this product, I realized it was a hint about the data model:

A record isn't separate from a plan. A review isn't the act of writing new data. It's adding meaning to time data that already exists, and looking at it again.

There's no reason a calendar can't hold more

We already maintain our calendars diligently.

Meetings, coding, workouts, commutes, appointments, rest — all of it lands on the timeline. It may be the record you own that's closest to your actual day.

And yet, to analyze that data, you have to export it to another service, manually re-categorize it, or reconstruct a review from memory.

Not because the calendar is lacking. Because we've spent so long thinking of it as a schedule-display interface and nothing more.

See time as the x-axis, extend it with properties on the y-axis, and add perspective as the z-axis, and the calendar can become a different kind of tool:

• A planning tool that is also a record of what you did.
• A journal that is also a project database.
• Something that shows not just what you meant to do this week, but how you actually spent your time.

So I'm building Velprium

Velprium is the product that started from this idea.

It's not trying to replace your calendar. It pulls in the events that already exist in your Google Calendar, lets you add properties like status, tags, ratings, and notes, and lets you view the same data through planning, doing, journaling, and review.

There's still plenty to figure out. Adding properties can't feel like a new chore. Recurring events and sync have to be handled gracefully. And the model has to stay simple even as people use it in very different ways.

But the starting point is simple:

A calendar isn't a schedule.
It's the time-based database you already maintain every day.

If that database had more columns and more perspectives than it does today, maybe we wouldn't have to record the same day across three different tools.

You can read the full version — time (x), properties (y), and perspective (z) — in the Coordinate Model docs. And I'd genuinely like to hear how you think about the gap between "when" and "what" in your own calendar; it's the question this whole project is built around.