PRODUCT ANALYTICS / ACCOUNT HEALTH
PULSEOPS
Turn raw product events into signals a small B2B team can understand, trust and act on.
- ROLE
- Product design
Full-stack implementation - SCOPE
- Product UI · ingestion API
Event model · aggregations · tests · deployment - AUDIENCE
- B2B founders
Product and success teams - PERIOD
- 2026 iterations
Deployed prototype - STACK
- Next.js 16TypeScriptSupabasePostgreSQLDrizzle ORM + Zod
- CONSTRAINT
- Traceable metrics
Retry-safe ingestion - CONTEXT / RESULT
- Portfolio product
Deployed prototype - CODE
- Private repository
Architecture documented
Activation, silent accounts, health and event volume share one operational surface.
From ingestion to a trustworthy signal.
Role and scope are stated above. This index isolates the system path, the hard failure mode, the decision and its proof.
- ARCHITECTURE
- API → PostgreSQL → aggregatesZod validates the contract before stored events feed decision surfaces.
- HARD PROBLEM
- Retries can corrupt metricsOne logical event may arrive twice after a client timeout.
- KEY DECISION
- Database-backed idempotenceunique(project_id, event_id) + onConflictDoNothing.
- PROOF
- Replay stays neutralstored → duplicate_ignored → 1 row → +1 metric.
01 / THE PRODUCT QUESTION
Events say what happened.
Teams need to know what to do next.
Small SaaS teams often collect product events without getting a useful answer to the questions behind them: who activated, where people dropped and which accounts are losing momentum.
I designed PulseOps as an operational reading layer. It preserves the event trail, turns behavior into transparent account signals and keeps every recommendation connected to evidence.
- 01ACTIVATION
Who reached the first moment of value, and where did the journey break?
- 02ACCOUNT HEALTH
Which accounts are slowing down before the team loses them?
- 03STREAM RELIABILITY
Was an event accepted, ignored or rejected, and why?
02 / THE TRUST CHAIN
Every number keeps a route back to reality.
The dashboard is the last layer of the product. Trust is built in every boundary that comes before it.
- 01Receive
POST /api/ingest/track
- 02Validate
Strict Zod contract
- 03Store
Raw PostgreSQL events
- 04Aggregate
Cron-ready calculations
- 05Explain
Visible score components
- 06Act
Prioritized account queue
TECHNICAL PROOF
One event. Two requests. One counted signal.
This deterministic walkthrough follows the persisted path implemented in PulseOps. It explains the behavior with fixed values; it is not live telemetry.
- 01 / ACCEPT
First request
- INPUT
POST evt_7A2E- RESULT
- 202 · stored
- 02 / REPLAY
Same event retried
- INPUT
same project + event_id- RESULT
- 202 · duplicate_ignored
- 03 / NEUTRALIZE
Database keeps one event
- INPUT
unique(project_id, event_id)- RESULT
- 1 stored row
- 04 / OBSERVE
Metrics stay honest
- INPUT
aggregates read stored events- RESULT
- +1 event, not +2
MECHANISMZod validation → unique(project_id, event_id) → onConflictDoNothing → ignored ingestion log. This is implementation evidence, not a dedicated ingestion test.
03 / THE PRODUCT IN USE
Three views. One continuous line of evidence.
Each surface answers a different question while preserving the same language for status, freshness and cause.
Accepted, ignored and rejected events remain inspectable instead of disappearing behind a chart.
Each account exposes health, activation position and the reason behind its current status.
A live tester connects developer documentation to the telemetry actually received by the product.
04 / EXPLAINABLE HEALTH
100 points.
No black box.
The score is deliberately fixed, bounded and documented. A team can challenge the formula, inspect every component and understand why an account changed state.
- 40Recent activity
- Time since the account’s last signal
- 25Usage frequency
- Event volume during the recent window
- 20Activation progress
- Share of required steps actually reached
- 15Key feature usage
- Presence of high-value product events
05 / ENGINEERING DECISION
A retry must not become a second event.
Idempotence is enforced where concurrent requests meet: in PostgreSQL, not in interface code.
- 01 / PROBLEM
Retries can corrupt the signal
After a timeout, a client may resend the same event and inflate volume, funnels and health metrics.
- 02 / CHOICE
Identity is scoped and constrained
Every payload requires event_id; PostgreSQL enforces uniqueness on project_id + event_id and ignores the conflicting insert.
- 03 / WHY
The database protects the invariant
Concurrent requests meet the same constraint, the API returns duplicate_ignored and aggregations read one stored event.
- 04 / TRADE-OFF
The producer owns stable identity
The same logical event must reuse its ID; a corrected payload with that ID is ignored and needs a new event.
06 / WHAT THIS PROJECT PROVES
One product.
Four layers of ownership.
PulseOps was designed as a complete product system. Each interface decision is connected to a data, architecture or reliability decision I also owned.
- 01PRODUCT JUDGMENT
Turn vague questions into operational metrics
Activation, account health and stream reliability each answer a decision instead of filling a vanity dashboard.
- 02DATA EXPERIENCE
Make complex signals readable without hiding their cause
Status, freshness and evidence remain visible from the control room down to one account or event.
- 03FULL-STACK ARCHITECTURE
Own the path from API contract to decision surface
A secure ingestion endpoint, relational model, scheduled aggregates and frontend work as one traceable chain.
- 04DELIVERY DISCIPLINE
Design failure modes before they become incidents
Idempotency, hashed keys, rate limiting and automated tests protect the metrics teams will act on.
07 / VERIFIED IN THE CODE
The failure paths
are part of the product.
The current suite exercises health scoring, payload validation, API-key handling, rate limiting, account summaries and environment readiness.
- 30
- automated tests
- 07
- test suites
- 0
- failures
Source: private PulseOps repository · npm test · verified 10 Oct 2026
08 / OUTCOME & LEARNING
A data product that can explain itself.
I connected a secure ingestion API, relational modeling, scheduled aggregations and a decision interface in one coherent product. The dashboard is not a visual endpoint: it is the readable surface of a traceable system.
PulseOps demonstrates how I work across product, frontend and backend boundaries while keeping one standard throughout: a metric only deserves trust when its source, freshness and limits remain visible.
09 / CALIBRATION QUEUE
The next signal
must come from real teams.
Next, I would run the health model against real account histories with a customer-success team, calibrate thresholds and measure whether the queue changes intervention quality.
- INPUT / REAL HISTORIES
Observe before tuning
Run the model against real account timelines instead of adjusting the score from intuition.
- CALIBRATE / WITH CS
Challenge the thresholds
Review healthy, watch, at-risk and silent states with a customer-success team.
- MEASURE / INTERVENTIONS
Prove the queue is useful
Compare action quality and response timing before expanding automation.