DEV Community

Boris Churzin
Boris Churzin

Posted on

Shipping a Universe: A Post-Mortem

A PM–Dev dialogue about shipping a universe — and discovering that time is not a dependency, but a consequence.

Originally published on Medium

Try to picture no time

Not frozen. Not paused.

Literally no before, no after. No moment you could wait through.

Even the idea of stillness sneaks in an ordering — something that could change. Remove that, and there is no sequence to appeal to. No forward. No backward.

This isn't a limitation of imagination. It's a signal.

Time is not something added at setup. It appears the instant a system supports distinctions that must be ordered. The moment consequences exist—when choosing X instead of Y constrains what can also be true—an ordering appears. That ordering is what we call time.

Here's how a Product Manager and a deliberately obtuse Dev discovered that, one build at a time.

Build 0 — Just Space

PM: Need a universe. Keep it minimal. No matter, no energy — just space.

Dev: Any requirements beyond "exists"?

PM: Yes. It has to matter.

Dev: You said "no matter"!

PM: Constraints. Consequences. If one possibility excludes another, the system should reflect that.

Dev: Shipping infinite space. Perfectly uniform. Nothing in it.

PM: What state is the universe in?

Dev: …Yes

PM: That's not a state…

Dev: …It is

A perfectly uniform universe has no internal contrast. No alternatives. No distinctions. It technically exists, but it cannot produce more than a single description of itself.

PM: Does it have time?

Dev: No. You haven't asked for "time". It's perfect. One state, nothing changes.

Time does not exist first to allow change. Change — in the sense of distinguishable alternatives — is what allows time to exist.

Build 1 — Stuff That Bumps

PM: Add particles. Let them interact. Make the interactions destructive.

Dev: Done. Particles collide. Outcomes differ. Some configurations prevent others.

PM: Ship it.

Dev: No can do! To define a collision, I had to assume a background. The system now has time because I faked it.

Classical physics creates relationships inside spacetime, but it assumes spacetime already exists.

PM: What if order emerged from the data?

Dev: Like a side effect?

PM: Like a side effect!

Dev: Wat?!… It's weird, it sounds impossible, and I hate that this just might work.

Build 2 — Make Relations Fundamental

Dev: New approach. Instead of particles in space, I defined relations directly.

PM: But why does ordering go one direction?

Dev: Because "undo" isn't forbidden — it's just insanely rare. So the direction we call "future" is the direction in which information about the past gets dispersed into details we don't track.

Space and time aren't inputs; they're bookkeeping forced by constraints and their updates.

PM: What happens without relations at all?

Dev: You get isolated facts with no mutual constraints. Nothing prevents contradictions. Nothing orders possibilities.

Without relations, there is no structure. Without structure, there is no ordering. Without ordering, there is no time.

Where Time Stops Being Magic

PM: Build 1 had time. What's different now?

Dev: It had time because we put it there as an ingredient. Now time emerges from relations. We're not assuming a clock — the universe generates its own.

PM: So time was always there once we had change. But now we know why it's there.

Dev: Exactly. Before, time was magic. Now it's accounting. Structure creates relations, relations create ordering, ordering is time.

PM: Release!

What "Consequences" Secretly Required

We kept failing until we had all the requirements:

Distinction gives multiple descriptions

Relations create constraints

Change produces sequences

Consistency makes sequences composable

Accumulation lets patterns matter

Irreversibility given low entropy, makes ordering flow one direction

These aren't preferences. They're failure modes.

A universe doesn't begin with time.

Time begins when the universe stops being meaningless.


Author here—happy to discuss where this framework breaks down or what other "obvious" dependencies turn out to be emergent!

Top comments (0)