Building Pulse: From Idea to Product

Reputation in software does not reflect the work. It reflects who is loudest, who has the most followers, and who happened to be in the room when something shipped. And the moment you change companies, most of it evaporates — the systems you kept alive, the incidents you resolved, the things you actually built are locked inside someone else's tools. Pulse started as a stubborn belief that this is fixable.

Starting from the truth, not the feed

Most social products start with a feed and bolt data onto it. We started at the opposite end: with the question of what is actually true, and how you would prove it. If reputation is going to mean anything, it has to be built on events that really happened and can be verified — a deployment, a release, a resolved incident — rather than on a profile someone typed out about themselves.

That single commitment shaped the entire architecture. It pushed us toward an append-only log of events as the source of truth, with everything a user sees — profiles, feeds, leaderboards, reputation scores — treated as a derived read of that log, never as the truth itself.

Canonical events (append-only, never edited)
        │
        ▼
Projections (derived, disposable, rebuildable)
   ├─ profile
   ├─ feed
   ├─ leaderboard
   └─ reputation score

This is event sourcing applied to a human problem. The events are the record; the reputation is a reading of that record, one we can explain, version, and recompute. If we change how reputation is calculated, we do not migrate anyone's history — we just replay the same true events through a new lens.

Why the record has to be owned by the engineer

A record that disappears when you leave a job is not a reputation — it is a rental. So a foundational rule of Pulse is that a developer's identity and history belong to the developer, and survive every employer, project, and organisation they ever pass through. Companies and projects are containers that work flows through; they never own the person's record.

The Pulse CLI: meeting engineers where they work

A platform about real work cannot depend on people remembering to log it. Real work happens in the terminal, in the deploy pipeline, in the release. So the Pulse CLI is how activity is captured at the source — automatically, as part of the work rather than as an extra chore on top of it.

• Deployments and releases flow in as they happen, not as something you fill in later.
• Verified activity is captured close to the source, where it is hardest to fake.
• The engineer stays in the tool they already live in — no context switch to a web form.

The CLI is not a side utility; it is the front door for the most trustworthy data Pulse has. Capturing work at the source is what makes the eventual record credible. It is the same architecture I described in How We Structure Modern Full-Stack Applications — a clean seam between where data is produced and where it is read.

Building it in the open

Pulse is a long build, and we are doing it deliberately — locking the model before writing the code, because an append-only system punishes you hard for getting the events wrong. You can follow the product as it takes shape at the Pulse home, and this journal will keep documenting the decisions as we make them.