Selected work

Case study 03 · Performance analytics

Engineering a clear view of performance after coaching.

I led the full stack delivery of Coaching Effectiveness, defining how filters, KPI calculations, aggregation rules, API responses, and chart behaviour worked as one analytical contract.

Role
Senior Full Stack Engineer
Ownership
Technical direction across backend, analytical contracts, and interface delivery
Decision
How did KPI performance move after coaching?
Stack
React, TypeScript, ApexCharts, Python, Django Ninja, PostgreSQL

01 · The decision behind the dashboard

Coaching effectiveness required a consistent comparison contract across calculations, APIs, filters, and charts.

The experience shows observed KPI movement in context; it does not treat correlation as proof that coaching caused the change. Time context, calculation rules, and incomplete evidence remain consistent across the API and interface.

  1. 01

    What moved?

    Compare KPI performance before and after the selected coaching context while keeping both values visible.

  2. 02

    By how much?

    Express movement without hiding the baseline or confusing points with percentages.

  3. 03

    Over which period?

    Keep the comparison legible as the view moves between daily, weekly, and monthly evidence.

02 · The comparison contract

One answer needed three values and several conditions.

I defined the metric contract before designing the chart so the summary cards, series, tooltips, and backend response could not disagree about what improvement meant.

01Baseline

Previous KPI

The reference value that gives the change meaning.

02Current

New KPI

The result for the selected comparison window.

03Improvement

Relative change

The percentage movement calculated from the same two values.

Improvement formula((New KPI − Previous KPI) ÷ Previous KPI) × 100

GuardrailWhen the baseline is missing or zero, the product must not manufacture a percentage. It should explain that the comparison cannot be calculated.

03 · One decision surface

The interface made context, comparison, and time grain visible together.

The reading order was deliberate: choose the coaching context, see the headline evidence, then inspect how the result changed over time.

  1. 01

    Path

    Choose the coaching journey or population being evaluated.

  2. 02

    KPI

    Choose the performance measure that defines success.

  3. 03

    Period

    Start with a useful default while keeping the comparison configurable.

Time grain and tooltip context

Daily

Keep individual dates visible

Useful for short windows where each day carries enough context to stand alone.

Tooltip14 Aug
Weekly

Show the range, not only a week number

The tooltip names the start and end dates so an aggregated point remains traceable.

Tooltip11 Aug to 17 Aug
Monthly

Reduce noise without losing direction

Longer windows group evidence into a stable trend while preserving the selected KPI meaning.

TooltipAugust 2026

04 · Full stack contract

The interface and service shared one decision contract.

I governed both sides of the boundary so filters, calculations, grouping, and incomplete states remained consistent from PostgreSQL to the rendered chart.

Product questionInterface responsibilityService responsibility
Which evidence is being compared?

Make Path, KPI, and period explicit, with stable defaults and clear selected state.

Validate the request and return one comparison contract for the selected context.

How should time be grouped?

Render daily, weekly, and monthly labels without changing the meaning of a point.

Aggregate at the requested grain and return the boundaries required by labels and tooltips.

How is improvement interpreted?

Show KPI value and percentage movement together, each with explicit units.

Apply the same baseline and current formula and return a clear unavailable state when the calculation is not valid.

What if evidence is incomplete?

Distinguish no result, insufficient comparison data, and a genuine zero.

Preserve missing values instead of converting absence into a misleading result.

05 · Interpretation boundaries

The dashboard remained useful because its claims stayed precise.

  1. 01

    Observed movement is not proof of causation

    The dashboard presents a before and after comparison. It does not claim that coaching alone produced the change.

  2. 02

    Percentage movement is not a point difference

    The two axes keep KPI values and relative percentage movement connected without presenting them as the same unit.

  3. 03

    No evidence is not zero performance

    An unavailable baseline, an empty result, and a failed service response remain distinct instead of collapsing into a misleading zero.

Verification focus

Testing the interpretation, not only the rendering.

  • Default Path, KPI, and period behaviour
  • Positive, negative, zero, and unavailable comparisons
  • Daily, weekly, and monthly grouping
  • Tooltip context plus loading, empty, and failed responses

06 · What the product made explicit

Leaders could inspect KPI movement without mistaking missing evidence for zero.

Explainable movement
the result, its baseline, and the calculation stayed visible together
Consistent meaning
summary cards, chart series, tooltips, and APIs followed one contract
Flexible time context
daily, weekly, and monthly views stayed interpretable
Honest attribution
the experience showed observed change without overstating what the data could prove
A chart is only as trustworthy as the comparison contract behind it.

Making units, time grain, missing evidence, and attribution explicit mattered more than choosing the visualization.

Selected workReturn to all engineering stories