Production win
A 1:1 Tool Can Become Surveillance Software
48h solo build · 3 independent AI jobs · 7 schema migrations
EMpath started as a 48-hour solo build for a familiar management problem. Notes are scattered, action items disappear, and by review time both the manager and engineer are reconstructing months of work from memory. AI can help connect those sessions. It can also make the product much worse if it erases the boundary between private preparation and shared feedback.
That boundary became the main architecture decision. A manager's raw notes stay manager-owned. The engineer has a separate self-profile rather than a second view over the manager's profile. When a 1:1 is completed, the engineer can receive a generated second-person summary and explicit action items, but not the private notes that produced them. This is not a cosmetic permission check. It shapes the tables, API routes, role guards, and the prompt context each job is allowed to read.
I considered a shared record because it looks transparent and is easier to explain. The problem is that it changes the behavior of the meeting. If every rough observation is automatically exposed, the private workspace becomes a surveillance feed and managers either stop recording useful context or write for the audience. Merging the manager's growth profile with the engineer's self-assessment creates a different problem: nobody can tell who owns a statement or who should be able to correct it.
The implemented path is narrower. Invitations and onboarding establish the role boundary. Manager notes and the manager-owned growth model sit behind that boundary. After the session, three independent AI jobs handle the derived work instead of one long request pretending that summary, actions, and growth processing have the same failure mode. Seven schema migrations during the build are not a vanity number. They show how much the data contract moved while those ownership rules became explicit.
There is more to do before I would call the privacy model mature. Retention and deletion need user-facing controls. Role changes need an audit trail. Background processing needs durable, idempotent delivery at higher volume. Generated summaries also need an editing and correction path without revealing the private source to the wrong person.
The useful outcome is not that AI writes nicer 1:1 notes. It is that the model works inside a boundary the product can explain: private input stays private, shared output is deliberately generated for sharing, and deterministic authorization owns the difference.
The decision
Keep manager notes and manager-owned growth context private. Give the engineer a separate self-profile, and share a generated second-person summary plus explicit action items rather than the raw notes that produced them.
Alternatives considered
- ·Share the notes or transcript with both people. Transparent in theory, but it changes what a manager can safely record and turns the product into a monitoring surface.
- ·Merge manager observations and engineer self-assessment into one profile. Simpler storage, but ownership and correction rights become ambiguous.
- ·Avoid AI entirely. Lower inference risk, but it gives up the useful work of finding recurring themes across sessions and turning discussion into follow-through.
Tech stack
The challenge
Use session history to help an engineering manager prepare better 1:1s without quietly changing private notes into an employee-visible record or letting one role cross into another role's data.
Architecture approach
- ·Separated the manager-owned growth profile from the engineer's self-profile in the data model and API boundary.
- ·Applied role guards to onboarding, invitations, team access, and session data rather than relying on different screens over the same endpoint.
- ·After a completed 1:1, launched three independent background jobs so summary, action-item, and growth processing could fail or retry without blocking one another.
- ·Made the engineer-facing output a second-person summary and a set of visible actions; raw manager notes remain manager-owned input.
Results
- A live role-aware product built solo in 48 hours
- Three independent AI jobs behind one completed-session event
- Seven schema migrations while the ownership model was made explicit
What I'd do differently at production scale
- ·Privacy needs product controls as well as database separation: clear visibility labels, retention rules, deletion behavior, and an audit trail for role changes.
- ·The background jobs need a durable queue and idempotency before higher volume; process-local dispatch is not a recovery strategy.
- ·AI summaries should remain editable and traceable to the session without exposing private source notes to the wrong role.