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, while other channels add cost or setup hurdles that aren't worth it for this audience.
- Reinforced by
- Calendar sync. Because chats and deadlines flow into the user's own calendar, the calendar they already use handles the time-sensitive "don't miss it" job - so email can focus on a simple daily digest.
Product
Outbound calendar sync only
- Decision
- The app publishes a calendar feed you subscribe to; it doesn't reach back into your Google or Outlook account.
- Why
- One-directional sync delivers the core value - seeing your recruiting timeline in your real calendar - with a fraction of the complexity and far less access to your account.
- Tradeoff
- Pulling events the other way was set aside as a maybe-later, not a launch need.
Product
Actionable, not informational
- Decision
- The dashboard's headline numbers each point to something that needs a decision - active firms, deadlines closing in, and follow-ups that have slipped - rather than passive totals.
- Why
- A plain count is redundant with the calendar and easy to ignore. Each tile answers "what needs my attention now?" and points somewhere different, turning the dashboard into a to-do surface.
Product
Deliberate scope cuts
- Decision
- Several plausible features were explicitly dropped or deferred to keep the product focused (e.g. inbound calendar OAuth, and various nice-to-haves).
- Why
- A focused personal tool that does the core loop well beats a broad one that does many things adequately. Scope discipline kept the build shippable.
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, rather than in a custom server.
- Why
- There's no server to run or secure, and privacy isn't left to the client to get right. Each account only ever sees its own data, and a new user starts with a genuinely blank slate.
- Tradeoff
- It leans on a platform and asks for discipline as the data model grows - a worthwhile trade for the security and simplicity it buys.
Architecture
Plan vs. record
- Decision
- A future coffee chat is kept as a plan, and only becomes part of your history (the record) once you confirm it actually happened.
- Why
- Treating a booked-but-unheld meeting as done would mark a contact "contacted," advance the follow-up clock, and be wrong the moment the chat is cancelled or no-shows.
- Consequence
- A gentle nudge to log the chat once its time has passed - confirm it, mark a no-show, or reschedule.
Architecture
Get the time right, everywhere
- Decision
- Chat times are stored and synced in a way that stays unambiguous across every calendar app.
- Why
- Events should land at the right time no matter which calendar or device you open. The chosen approach was a deliberate simplification of a more complex one - the same result, with less that can go wrong.
Architecture
Follow-up auto-advance that respects intent
- Decision
- Logging an interaction nudges a stale or missing follow-up to a sensible next date, but never overrides one you deliberately set further out.
- Why
- Automation should remove busywork without overriding intent - keeping follow-ups fresh while still honoring the plans you make on purpose.
Architecture
Stage dates auto-stamp on drag
- Decision
- Moving a firm into a new stage records that date automatically - but only when it's blank, and moving it back never erases a date you've already reached.
- Why
- You record history through the action you were already taking, with no extra entry, and the app never quietly rewrites something that already happened. Dates stay editable by hand.
Architecture
Application outlook: sorted by open date
- Decision
- The season timeline is ordered by when firms open and colored by stage, so it reads at a glance.
- Why
- An outlook is about what's coming, so ordering by open date reads as a cascade - while the board and calendar lean on deadlines for urgency. Coloring by stage tells you status without a legend.
Architecture
Ask Pipeline: on-device, not an AI model
- Decision
- The "Ask Pipeline" assistant answers your questions locally, on your own device, and deliberately doesn't send anything to an outside AI model.
- Why
- The questions people actually ask a recruiting tracker are a small, knowable set, so they can be answered precisely and instantly without a model in the loop. Sending a private pipeline to a third party would mean latency, added cost, a new privacy surface, and less predictable answers.
- Tradeoff
- It sticks to the questions it was built for rather than improvising - a deliberate choice for a bounded, reliable tool whose answers link you straight to the underlying records.
03
Process & Engineering Decisions
Process
Spec-first, phased implementation
- Decision
- Meaningful features started as a short written plan before any code, then got built in small, reviewable steps.
- Why
- Thinking it through up front catches shaky assumptions while they're cheap to fix, and small steps keep each change easy to check and reason about.
Process
Faithful-port-first during the redesign
- Decision
- When restructuring, existing behavior was ported faithfully before layering on new capability.
- Why
- Separating "move it" from "improve it" keeps regressions visible and reviews honest.
Process
Verify by building and checking, feature by feature
- Decision
- Changes are verified with a clean build and a hands-on check of each feature, rather than a full automated test suite.
- Why
- For a solo, pre-launch build this keeps iteration fast. It's a conscious tradeoff - automated tests around the core logic are on the roadmap for once real users depend on the app.
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.