Building and Shipping an AI-Powered Job Application Tracker & Document Generator

An AI-native UX case study built using vibe coding workflows and real-user validation.

Role: Product Design, UX Architecture, AI Workflow Design, UI, QA

Timeline: 2 evenings to MVP + 1 week of real-user iteration

Live: almosthired.de (Beta)

Context

In early 2026, my wife Keerthana and my friend Nithin were both job hunting, and I could see how broken the process had become for them. Keerthana was losing track of where she had applied and what stage each application was at. Nithin was burning hours rewriting resumes and cover letters for every role. I was in the same loop: version sprawl, constant edits, and formatting drift across tools.

Everything was scattered. Job descriptions disappeared with closed tabs. Versions piled up. Context got lost. It was not a skill problem. It was a system problem. Instead of just talking about it, I built something. For them, for myself, and ultimately for anyone running a serious job search.

The Real Problem

At surface level, job hunting feels stressful. At system level, it is operationally broken.

The deeper issue:

Job hunting is data-heavy but insight-poor.

Product Hypothesis

Almost Hired was designed as a lightweight job search operating system, not another auto-apply tool.

Constraints & Execution Strategy

This was intentionally built under strict constraints.

• Built in 2026 using Lovable
• Total cost: €70
• 0 to 1 in 2 evenings after office
• Followed by continuous real-world iteration with three daily users

I could not justify spending thousands of euros on a speculative side project.

That constraint shaped the product:

• No feature bloat
• No visual gimmicks
• Precise, refined prompting
• Focused, cost-aware iteration

Every prompt and revision was deliberate.

Solution Overview

Almost Hired was built and shipped as a working SaaS product using:

• React
• Tailwind CSS
• shadcn/ui
• Server-side Edge Functions
• Google Gemini
• PostgreSQL with Row-Level Security
• Native browser print-to-PDF (no heavy PDF dependencies)

The system integrates four layers:

Applications → Professional Profile → AI Documents → Secure Export

Core Product Architecture

1. Application Dashboard

Solution:

• Status pipeline: Applied, Interviewing, Offer, Rejected
• Card and table views, switchable per user preference
• Filter, search, sort, pagination
• Mobile-optimized layout
• Persistent Add Application button
• Onboarding checklist for new users

Replaces memory-based tracking with structured visibility.

2. Profile as Data Engine

A single canonical profile holds:

• Personal info, photo, headline, preferred job type
• Profile links (LinkedIn, portfolio, case studies, with optional passwords for stealth job searches)
• Experience, education, skills, projects, certifications, languages, custom sections

Auto-save throughout. Resume import from PDF, DOCX, or LinkedIn export.

This is the source of truth. Users no longer rewrite resumes. They maintain a clean, structured dataset.

A small touch I'm proud of: the password-protected profile links. Discovery conversations made it clear that quietly job-hunting users didn't want an unpassworded portfolio link landing in front of a hiring manager who might Google their current employer. Each profile link can carry a password the user shares only with people they're actually applying to.

3. AI Resume & Cover Letter Generation

A two-step server-side pipeline:

1. JD Analysis. Gemini extracts required vs. preferred keywords, acronyms, industry context.
2. Tailored Draft. Strict section order, no AI-tell phrases, no placeholder metrics, projects auto-included by relevance score, skills cross-referenced against the JD.

Every generation is followed by an audit block: keyword match rate, gaps, recommended actions. The user sees not just the document but why it should work. That visibility is what flipped trust in early testing. Showing the AI's reasoning reframed it from black box to co-pilot.

Outputs are versioned. Each regeneration is a new, switchable, independently editable version. No more Resume_FINAL_v3.docx.

Result:

Resume prep time dropped from about 45 minutes to under 5.

Users moved from writing to refining.

4. ATS-Friendly Rendering

• Single-column structure
• Semantic Markdown
• No tables, no decorative typography
• Native browser print-to-PDF

I deliberately avoided heavy PDF libraries to reduce:

• Security vulnerabilities
• Maintenance overhead
• Dependency complexity

Simplicity was strategic.

Trust & Compliance as Design Surface

Most products treat compliance as a footer link. I treated it as a feature.

• Every AI-generated document carries an "AI-generated" badge with a tooltip referencing EU AI Act Article 50
• Privacy Policy §7 lists AI sub-processors and classifies the system as limited risk with mandated human oversight
• The architecture enforces human-in-the-loop. No path through the app sends a generated document without the user reviewing or editing it.

In real-world use, this transparency made users more willing to send the output, not less. Visibility built trust.

Controlled Access & Growth Architecture

As the product matured, I intentionally chose not to make it publicly open.

An AI-powered SaaS without access control can quickly face:

• Unpredictable AI costs
• Rate limit abuse
• Concurrency pressure
• Storage growth issues

Instead of scaling prematurely, I designed a controlled access system.

1. Waitlist Entry

A public waitlist form with:

• Server-side validation
• Rate limiting (5 requests/hour/IP)
• Spam protection

No direct open registration.

2. Admin Approval

An internal /admin/waitlist dashboard (RBAC-protected) allows:

• Approving or rejecting requests
• Triggering invitation emails
• Controlled onboarding

3. Invite System & Enforcement

Approved users can generate up to 5 single-use invite codes (8 characters, 7-day expiry). Every login is server-side validated. Only users marked invited or joined gain access.

A 5-generations-per-month free tier reinforces the same principle on the AI side. Recruiters might wince at the cap. Isn't more usage better? Not for this product. Generating fewer, better applications is the whole promise; the limit puts gentle friction in the path of spray-and-pray. The cap is enforced atomically via a Postgres function with row-level locking, so no concurrency leaks.

UX Design Principles

5. Boring Beats Clever

No streaks, no gamification, no "you're 73% optimized!". Serious job seekers want a tool, not a game.

Real-World Testing

I also shared it with other friends.

Insight:

Only active job seekers feel urgency.

Adoption is context-driven.

⭐️ Today:

• Keerthana uses it daily
• Nithin uses it daily
• I use it daily

Adoption validates product-market timing.

Security & Engineering Decisions

Intentional Scaling Decision

I intentionally did not launch the product publicly.

An AI-powered SaaS fails at the infrastructure layer before it fails at the interface. Uncontrolled access would create immediate pressure on:

• AI generation costs
• API rate limits
• Concurrent processing
• Resume version storage growth
• Rendering performance

The current system is optimized for controlled, validated usage.

Because of this, I introduced an invite- and whitelist-based access model:

• Public waitlist entry
• Admin approval workflow
• Limited, time-bound invite codes
• Backend validation on every login

This ensures cost predictability, infrastructure stability, and abuse prevention.

Scaling responsibly would require queue-based AI generation, usage-tier controls, caching, storage lifecycle management, and background processing.

Restraint was a deliberate architectural decision, not hesitation.

Outcomes

• Resume preparation time dropped from about 45 minutes to under 5
• Application tracking centralized into one canonical view
• Keyword alignment became visible, not guessed
• Cognitive fatigue down across daily users
• Increased sense of strategic control

The biggest impact was psychological:

Users feel they are running a system, not reacting emotionally.

What This Project Demonstrates

• Real problem identification from lived experience
• Rapid 0 to 1 execution with vibe coding
• AI integration with cost and ethics awareness (Article 50, audit block, human-in-the-loop)
• Secure SaaS architecture (RLS, server-side orchestration, sanitization)
• Cross-device QA discipline
• Lean experimentation under strict budget constraints
• Strategic decision not to scale prematurely
• Design as trust: making AI provenance visible

Reflection

Almost Hired was built in:

• 2 evenings
• €70 total cost
• Continuous iteration with three real users

It now runs daily for real users solving a real operational problem.

It is not a UI experiment.

It is a shipped system built under constraint, validated through usage, and architected with foresight.

It represents my ability to:

• Identify systemic inefficiencies
• Design structured solutions
• Integrate AI responsibly
• Ship quickly
• Make disciplined product decisions

The product remains in active development, continuously evolving through real usage, feedback, and infrastructure-aware iteration.

And most importantly: turn chaos into clarity.