Plynn — Job Application Tracker (SaaS)

Tracking applications gets messy fast: spreadsheets lack structure, and CRMs are overkill for students and job seekers. I first noticed it when a friend showed me their Excel sheet with 100+ rows of applications, and it was hard and time-consuming to keep track of statuses, deadlines, and notes.

That's when I thought about creating a clean, professional tool that combines the speed of spreadsheets with the structure and features of a product. Users need speed (quick edits), clarity (filters/tags), and feedback (analytics + reminders).

On the Chrome extension side, I realized that a lot of time is spent manually copying and pasting job details from postings into trackers. An extension that can auto-capture fields would save a ton of time and reduce errors.

I designed and built Plynn as a job-application tracker that keeps the familiarity of Excel while fixing everything spreadsheets do poorly: structure, speed, consistency, and follow-through. The core idea was to preserve the table-first workflow, because that’s how people naturally track applications, while turning it into a real product with guardrails, automation, and insights. That meant building a dashboard where adding, editing, filtering, and scanning rows feels instantaneous like a spreadsheet, yet the data stays clean, queryable, and usable for analytics.

To achieve that Excel-speed feeling, I treated table UX as a first-class feature rather than a UI detail. I built fast inline cell editing, keyboard-friendly interactions, smooth scrolling, and lightweight rendering so the dashboard stays responsive even as entries grow. I added tag-based organization (e.g., remote, urgent, needs follow-up) to match how people mentally group applications, then layered in filters and search so users can slice their pipeline instantly without breaking flow. Instead of forcing users into rigid forms, the experience stays flexible: quick to input, quick to read, and easy to adjust as priorities change.

Once the tracking layer was solid, I turned the dashboard into something a spreadsheet can’t do: generate feedback and momentum. I built analytics that surface real signals, conversion rates across stages, trends over time, and where the pipeline is leaking, so users can understand what’s working, what’s not, and what to change next. The goal wasn’t pretty charts; it was decision support that helps users refine their strategy, stay consistent week-to-week, and increase interview outcomes as they iterate.

To reduce friction at the moment that matters most while browsing job postings, I built a Chrome extension that extracts structured fields from listings and pre-fills entries in Plynn. Instead of manual copy/paste for company names, roles, links, and notes, users can capture a posting in seconds, improving consistency and making tracking feel seamless across the browsing, applying, following-up loop. Finally, I built reminders and notification logic to solve the biggest real-world failure mode: people forget to follow up. The product supports deadlines, follow-up reminders, and next-action nudges so the tracker stays alive even when users get busy, resulting in a system that feels like a spreadsheet but behaves like a purpose-built product.

I built Plynn as a full-stack SaaS with a table-first dashboard, designed to feel like Excel while still being a real product with structure, permissions, and analytics. The frontend is Vue 3 + Quasar + TypeScript, organized around reusable, component-driven UI (table cells, status chips, tag pills, filters, dialogs, and consistent empty/loading states) so the dashboard stays clean and scalable as features grow. The UI is optimized for high-frequency interactions: fast edits, quick scanning, and predictable layouts so users can manage a large pipeline without friction.

The backend is Node.js/Express providing APIs around a Supabase core (Postgres) that handles authentication, structured storage, and secure data access. Supabase is the source of truth for application rows, tags, reminders, and analytics events, with access protected using role-based rules and server-side validation so users only ever see their own data. I designed the data to be queryable (not spreadsheet-chaotic) so filtering, aggregations, and exports (PDF/CSV/Excel) can be built reliably on top without brittle logic.

The Chrome extension is a first-class capture layer: it extracts job posting fields from common job boards (e.g., LinkedIn, Indeed, Workday), converts the page into a structured payload (company, role, location, link, notes, etc.), then sends it to the app/backend for one-click creation. This removes copy/paste work, standardizes entries, and keeps the workflow seamless from browsing → saving → tracking. The extension includes background authentication/identity linking so a saved job lands in the correct user account automatically.

For premium infrastructure, I integrated Stripe subscriptions with webhook-driven plan syncing so billing status is always reflected in the database and enforced in the product (feature gates, limits, and access rules). This is implemented as an event-driven flow (webhook → server verification → database update), which prevents UI-only gating and keeps the system consistent even if the user changes plans, renews, or payment states update outside the app.

I optimized table UX and perceived performance because a dashboard only works if it feels instant. That included tightening loading states and skeletons, keeping interactions snappy (filters, tag toggles, stage changes), and making sure the “scan → edit → continue” loop never feels heavy. The goal was spreadsheet-like responsiveness: users should be able to move quickly through their pipeline without waiting on UI re-renders or clunky transitions.

I focused heavily on product polish and consistency so the app reads like a real tool, not a side project. I standardized spacing, typography, and component behavior across the dashboard (buttons, cards, chips, modals), added clear empty states and helpful microcopy, and iterated UX details based on real usage patterns so flows feel obvious. This includes reducing friction for common actions (adding entries, tagging, filtering, saving from the extension, and returning later) so the product stays intuitive even as it becomes more powerful.

I also optimized the architecture for reliability and scale as features expanded—analytics, reminders/notifications, exports, and subscription gating. That meant keeping data structured and analytics-ready, designing endpoints with predictable payloads, and ensuring plan state and permissions are enforced server-side. The result is a system that supports advanced features (dashboard analytics, reminders, exports, subscription plans) without turning into fragile, one-off UI logic.

Finally, I prioritized reducing manual work because that’s the biggest reason trackers fail. The Chrome extension + structured capture flow reduces manual input dramatically, improves data completeness, and makes the habit of tracking feel effortless. Combined with reminders and analytics, Plynn becomes an active workflow tool that keeps users moving (follow-ups, deadlines, next steps) rather than a passive spreadsheet that gets abandoned.

Shipped a complete end-to-end product that covers the full job-search loop: capture a posting while browsing, store it as structured data, track stage changes and notes over time, and stay on top of follow-ups with reminders. The main outcome is that Plynn is not a prototype UI—it’s a coherent workflow that removes the biggest pain points of spreadsheets (messy data, inconsistent inputs, and no action system) while keeping the same table-first speed people actually want.

Reduced the friction of logging opportunities by introducing a Chrome extension capture flow. Instead of copy/pasting company names, titles, links, locations, and notes into a spreadsheet, users can create an entry from a posting in seconds with consistent fields. This increases data completeness (fewer missing links/fields), improves consistency (standardized structure per row), and makes the tracking habit realistic because adding entries no longer feels like extra work.

Made the dashboard feel spreadsheet-fast by prioritizing perceived performance and table UX. The result is a tracker that stays snappy during the actions that happen dozens of times per session—scanning rows, editing statuses, adding tags, filtering/searching, and moving between stages—so users can manage a large pipeline without the UI becoming a bottleneck.

Turned raw tracking into feedback with analytics that summarize pipeline health: stage breakdowns, conversion-rate signals, and time-based trends that help users spot what’s working and where they’re leaking interviews. Instead of being a passive log, the product becomes a decision tool that guides where to focus effort and what actions to take next.

Implemented production-grade subscription plumbing (Stripe checkout + webhook verification + database plan syncing) so premium access is enforced reliably and consistently. This ensures plan state is accurate even when changes happen outside the app (renewals, upgrades, cancellations), and it prevents feature gating from being a front-end-only toggle.

Scale the capture/automation workflow so Plynn becomes the fastest possible way to go from ‘I found a posting’ to ‘it’s tracked with a next action.’ Concretely: improve the Chrome extension’s extraction coverage across more job boards, add smarter field inference (role level, team/discipline, location normalization), and let users configure default tags/stages so new entries instantly match their personal workflow.

Build a stronger action system around reminders so the product consistently drives follow-through. I’d add a lightweight “Next action” field (follow up, apply, reach out, schedule, prep) with optional templates (e.g., follow-up email prompts), plus a weekly review mode that surfaces overdue items and suggests the highest-leverage actions based on stage and time since last touch.

Evolve analytics into strategy guidance rather than just reporting. I’d add breakdowns by source (LinkedIn vs referrals), role type, location, and tag groups, and introduce time-to-stage metrics (how long from applied → interview, interview → offer). The goal is to help users answer: what kinds of applications convert best for me, and where should I spend my time this week?

Improve collaboration and shareability for users who job search with friends/mentors. I’d add shareable views (read-only links), optional feedback requests on specific rows (CV review, interview prep), identifies patterns like recurring rejection stages, and exportable summaries for career advisors—without leaking private personal notes by default.

Harden the product for broader release: tighten edge cases, add better onboarding, refine empty states and first-run experience, and expand accessibility/keyboard navigation so the table-first UX works for power users. I’d also invest in observability (basic event tracking + error monitoring) to measure retention, feature usage, and the impact of reminders and capture on user outcomes.