Meeting Pulse — Making Meeting Impact Visible.
Your calendar tracks time. Meeting Pulse tracks the energy, clarity, and decision quality behind it — so recurring meeting friction becomes visible enough to change.
Why I built it
Meetings consume time. Their real cost is harder to see.
A calendar can show that a meeting lasted 45 minutes. It can't show whether it created clarity, moved a decision forward, drained the room, or ended without an owner.
Those effects are felt immediately but usually disappear before they become usable evidence. Meeting Pulse began with a deliberately small question: could a person capture the after-effect of a meeting quickly enough to build a useful pattern over time — without turning private reflections into another workplace surveillance system?
The product needed to feel faster than writing a note, more trustworthy than a black-box score, and private enough for honest reflection.
thesis
A short private reflection can become a better signal for changing meeting behavior than another calendar analytics dashboard.The product thesis that framed the MVP.
The strategy
The constraint was the strategy.
I chose a local-first MVP rather than beginning with accounts, integrations, team dashboards, or an AI assistant. The first version stays focused on one behavior: reflect immediately, understand the score, and see the weekly pattern.
- No account or authentication before the core habit proved useful.
- No server storing meeting names, notes, or emotional reflections.
- No opaque AI score that a user could not inspect.
- No calendar integration in v1; the product had to earn the right to automate.
Fast enough for the moment
A focused two-step flow designed around a roughly 30-second reflection.
Signal, not judgment
Scores describe impact; they don't label the person or the meeting as good or bad.
Explanation before sophistication
Mood, duration, and selected reasons visibly contribute to the result.
Patterns over isolated reactions
The weekly view matters more than any single score.
The system
A small loop with enough structure to become useful.
The core loop moves from immediate reflection to longitudinal learning. The app stores the meeting, calculates an explainable impact score, updates the day and week, and returns one useful pattern — not a dashboard full of undifferentiated metrics.
Log the moment
Capture the meeting, mood, duration, and the reasons that shaped the outcome.
See the signal
See the impact score and the concrete signals that produced it.
Change the pattern
Use weekly patterns to protect useful formats and change recurring friction.
The product is built around a compact object model — meeting, reflection, mood, reason, impact score, day, week, and insight. Their relationships keep the experience coherent across Today, Insights, History, results, detail views, reports, and settings.
principle
The system may summarize what the user reported. It may not invent intent, diagnose a team, or disguise an opinion as intelligence.Scoring was a design-governance problem before it was an algorithm.
Governing the score
Set the boundary before the model.
Once an app converts a private reflection into a number, it creates an authority relationship — the system appears to know what the meeting was worth. I rejected an AI-generated assessment in v1 and made trust, explainability, and change control into product requirements.
Three non-negotiables: every input must be chosen by the user; every weight must be explicit and revisable; and the same inputs must always produce the same result. The model separates three kinds of evidence, then translates the number into plain-language impact labels so the score supports reflection rather than pretending to be an objective grade.
deterministic
It creates a stable contract between product intent, interface explanation, and executable code. The user can challenge the model because the model can be seen.Encoded as one centralized, typed domain function with boundary tests.
Privacy as architecture
Privacy expressed in the product's technical shape.
Meeting Pulse uses local SQLite persistence and requires no backend or cloud profile. In v1, meeting names, notes, moods, and scores stay on the device.
Privacy is therefore not only a policy statement — it is visible in the architecture. Removing the server also removed infrastructure that did not serve the first user outcome, which kept the MVP focused on the reflective behavior itself.
Key decisions
The work is visible in the choices, not the feature count.
Five decisions carried the product from an ambiguous problem to a governed, shippable v1.
Build the behavior before the ecosystem
I cut login, calendar sync, team analytics, and collaboration from v1. The reflection loop had to prove itself independently.
Govern the score as a product decision
I defined what the system was allowed to infer, made every weight inspectable, exposed the calculation in the experience, and implemented the model as centralized, tested domain logic.
Make local-first a trust promise
SQLite persistence made the privacy position concrete and reduced infrastructure that did not serve the first user outcome.
Design for the after-meeting moment
The logging flow prioritizes recognition and quick selection over a long form or retrospective journaling experience.
Ship the whole product surface
The work included the app, report sharing, support content, privacy policy, public website, release assets, TestFlight, and the App Store release.
What shipped
A complete product surface, not a prototype.
I closed the loop around the product rather than stopping at a working screen.
Every surface in the loop was designed, built, and wired to real local data — including the archive, where past reflections stay inspectable without reliving each meeting. The ledger below is the full v1 surface behind those screens.
Outcome & reflection
What this project proves — and what it doesn't yet.
Meeting Pulse is intentionally smaller than the enterprise systems elsewhere in my portfolio. Its value is different: recency, range, and follow-through.
What it demonstrates today. A focused product proposition, a coherent end-to-end experience, a legible decision model, a trust position expressed through the architecture, and a deliberately constrained MVP that protects the reflective behavior before adding automation.
What I can't claim yet.I don't have enough real-user evidence to say Meeting Pulse improves meeting culture or changes weekly behavior. Those are hypotheses, not outcomes.
What I would test next:
- Activation — can a new user log the first meeting without explanation?
- Comprehension — can users explain why a score changed?
- Habit strength — does the 30-second promise hold after novelty fades?
- Insight usefulness — does a weekly pattern lead to one observable change?
- Privacy understanding — do users notice and value local-first?
signal
I didn't stop at a prototype. I closed the loop around the product: working app, persistence, tests, release build, store workflow, support, privacy, and public documentation.The next iteration should prove which part of the behavior deserves to survive.