Decisions & Tradeoffs.
A short log of the meaningful product and engineering calls behind Pipeline: what was chosen, why, and what was traded away.
01
Product Decisions
Product
Email as the notification channel
- Decision
- Notifications are email with a per-user opt-out - no SMS, no push.
- Why
- Email is universal and low-friction; other channels add cost or setup hurdles this audience doesn't need.
Product
Outbound calendar sync only
- Decision
- The app publishes a calendar feed you subscribe to - it never reaches into your Google or Outlook account.
- Why
- One direction delivers the core value with a fraction of the complexity and far less access to your account.
Product
Actionable, not informational
- Decision
- Every headline number on the dashboard points at something that needs a decision, not a passive total.
- Why
- Plain counts are easy to ignore; each tile answers "what needs my attention now?"
Product
Deliberate scope cuts
- Decision
- Plausible features were dropped or deferred to keep the product focused.
- Why
- A personal tool that does the core loop well beats a broad one that does many things adequately.
02
Architecture & Data Decisions
Architecture
A managed database, isolation at the source
- Decision
- Data lives in a managed database with per-user isolation enforced at the database itself.
- Why
- There's no server to run or secure, and privacy isn't left to the client to get right.
- Tradeoff
- It leans on a platform - a worthwhile trade for the security and simplicity it buys.
Architecture
Plan vs. record
- Decision
- A future chat is a plan - it only becomes part of your history once you confirm it happened.
- Why
- A booked-but-unheld meeting that counts as "contacted" is wrong the moment it's cancelled.
Architecture
Get the time right, everywhere
- Decision
- Chat times are stored so they stay unambiguous across every calendar app.
- Why
- Events should land at the right time on every device - with less that can go wrong.
Architecture
Follow-up auto-advance that respects intent
- Decision
- Logging an interaction nudges a stale follow-up forward, but never overrides one you set deliberately.
- Why
- Automation should remove busywork without overriding intent.
Architecture
Stage dates auto-stamp on drag
- Decision
- Moving a firm into a stage records the date - only when blank, never erased by moving back.
- Why
- History gets recorded through the action you were already taking, and never quietly rewritten.
Architecture
Application outlook: sorted by open date
- Decision
- The season timeline is ordered by when firms open and colored by stage.
- Why
- An outlook is about what's coming; color answers status without a legend.
Architecture
Ask Pipeline: on-device, not an AI model
- Decision
- The "Ask Pipeline" assistant answers locally on your own device - nothing is sent to an outside AI model.
- Why
- The questions people ask a tracker are a small, knowable set - answerable instantly without latency, cost, or a new privacy surface.
- Tradeoff
- It sticks to the questions it was built for rather than improvising.
03
Process & Engineering Decisions
Process
Spec-first, phased implementation
- Decision
- Meaningful features started as a short written plan, then got built in small reviewable steps.
- Why
- Shaky assumptions get caught while they're cheap to fix.
Process
Faithful-port-first during the redesign
- Decision
- When restructuring, existing behavior was ported faithfully before adding capability.
- Why
- Separating "move it" from "improve it" keeps regressions visible.
Process
Verify by building and checking, feature by feature
- Decision
- Changes are verified with a clean build and a hands-on check, feature by feature.
- Why
- For a solo build this keeps iteration fast; automated tests come once users depend on it.
See how it all came together.
The full build journal - what Pipeline is, the problem it solves, how it's built, and the arc that got it there.