Documents Became Databases. Calendars Remained Timetables.

Document apps have become an entirely different tool over the last twenty years.

A program where you typed text onto a blank page grew into a workspace with blocks, databases, properties, relations, multiple views, and AI. A sentence became a block. A block got properties. A document became a database you could read as a table, a board, a gallery, or a timeline.

Now open a calendar event today. You still get the same familiar fields.

Start time
End time
Title
Description

Our work and our lives got much more complex in those twenty years. But the container we pour that complex time into barely changed.

So here's the question this whole post turns on:

Is our time really this simple?

Calendars did evolve — just in a different direction

Let me correct my own overstatement before it costs me your trust, because calendars absolutely did improve:

• sync across every device
• recurring events
• invitations and RSVPs
• one-tap video links
• shared team calendars
• natural-language event creation
• find-a-free-slot
• multiple time zones

That's a real list. But look at what kind of progress it is. Almost all of it makes an event easier to create, deliver, and coordinate.

The calendar became an excellent tool for coordinating commitments. It barely evolved into a tool for recording what those commitments mean.

Document apps expanded the meaning of content. Calendar apps improved the distribution of schedules. Both moved forward — in different directions.

Every event collapses into the same rectangle

Here's a normal day:

10:00–11:00  Client meeting
14:00–15:00  Product development
18:00–19:00  Workout

On the calendar, these are three identical one-hour rectangles. In reality they could not be more different.

Client meeting — fixed in time. External people. Hard to move. Generates follow-up work afterward.

Product development — movable. Needs a long unbroken stretch. More likely to actually happen in the morning. Belongs to a specific project.

Workout — flexible in time. Has a weekly target count. Quietly evaporates if you keep pushing it. Depends on your energy that day.

The calendar knows exactly when these three events start and end. It has no idea whether you can swap them.

Same-sized rectangles on the screen; completely different kinds of commitment to the person living them.

Why the thin model was fine for so long

For decades this simplicity caused no real problem — for one reason.

The calendar never had to make the judgment.

You already knew all of it:

• this meeting can't move
• this work has to happen in the morning
• if the workout doesn't happen today it moves to tomorrow
• this task isn't finished yet
• this block belongs to that project

The calendar only had to display the decision you'd already made:

a human understands the meaning
→ a human makes the judgment
→ only the final time goes into the calendar

In that arrangement, a thin data model is enough. All the rich context lived in your head, and you were the one doing the scheduling.

AI is what exposes the gap

Here's the turn.

Say you ask an AI: "Find me 10 hours for product development next week."

Finding ten empty hours is easy. Everything that actually matters is a separate problem:

• Does it need to be in blocks of two hours or more?
• Can you focus right after a meeting?
• Do you actually work in the evening?
• How far can existing events be moved?
• Is there a time of day where this repeatedly fails?
• Is this tied to a hard deadline?

Finding an empty slot is a computation problem. Finding a good slot is a context problem.

And here's the catch:

If the meaning of an event doesn't exist as data, the AI has to guess it from the title — or ask you again, every single time.

Which means the case for a richer calendar isn't really about dashboards or power users. It's the prerequisite for a calendar assistant that gives useful answers instead of plausible-looking ones. Better Calendar AI requires a better data model underneath it.

What an event might actually need

Before naming any product feature, picture a more capable event in the abstract:

Title: Product development
Project: Velprium
Status: In progress
Priority: High
Flexibility: Movable
Preferred time: Morning
Minimum duration: 90 minutes
Energy required: High
Result: Product Hunt gallery completed
Rating: 4/5
Next action: Record demo video

Not every field matters to every person. The point isn't the specific list — it's that an event should be able to answer questions like:

• What does this belong to?
• How important is it?
• Can it move?
• Did it actually get done?
• What did it produce?
• How did the plan differ from reality?
• What's the next action?

And notice the shape of the answer, because document apps already solved exactly this:

Documents didn't make every document complex. They gave blocks, properties, relations, and views to the people who needed them.

A calendar can grow the same way.

"But who wants a more complicated calendar?"

This objection has to be handled head-on, because it's the right instinct. The answer is a single principle:

Simple to use, rich underneath.

Think of a phone camera. You press one button. Behind that button: focus, exposure, color correction, stabilization, and a dozen more decisions you never see. The simplicity of the interface has nothing to do with the richness of the model behind it.

A calendar can go the same way:

• casual users keep entering just a time and a title
• the AI proposes project, flexibility, and category
• only the properties you actually use are surfaced
• power users configure their own properties and views
• everything else stays folded away until it's needed

Because the goal was never to make you fill out more forms.

The goal isn't to make you enter more information. It's to stop you from losing the context that already exists.

Where I got this wrong

I learned this the expensive way.

In an early version of Velprium, I modeled events, tasks, and records as separate data. Schedules lived in the calendar, to-dos lived in a task list, and outcomes lived in a retrospective screen. Every feature I added made more objects describe the same piece of work.

Is a development block placed at 2 p.m. an event, or a task? Once it's finished, does it have to become a third thing — a "record"?

Eventually I realized the problem wasn't missing features. I was splitting one piece of time into several objects far too early.

A schedule, a task, and a record often aren't different objects at all. They're the same block of time, seen in different states and from different points of view.

The plan, the doing, and the looking-back are one timestamp wearing three faces — not three things I needed to keep in sync.

What becomes possible when the model gets richer

Once an event can carry meaning, a few things open up — and notice none of them require re-entering your time:

• Records. Keep not just the plan but what actually happened.
• Retrospectives. See which projects ate your time and what kept slipping.
• Multiple views. Read the same event as a schedule, a diary, a project log, or a weekly review.
• An AI agent. One that understands your past behavior and proposes a more realistic next week.

The win isn't a longer feature list. It's this:

The same time data can be reused for many purposes without ever entering it twice.

So here's what I'm building

This is the thinking behind Velprium.

Rather than replace Google Calendar, it attaches context — status, project, rating, outcome — to the events you already have, and lets you read the same time data through several lenses: plan, execution, diary, retrospective. Lately I've been experimenting with using that same structure as context for an AI agent: instead of just finding empty slots, it draws on how past work actually went and the conditions attached to an event to propose a more realistic next week.

Document apps broke free from being digital copies of paper. Calendars are due to break free from being digital copies of the timetable on the wall.

Our schedules are already complex. It's time the calendar understood that complexity.