Product brief
I defined JobJournal as one workspace for tracking applications, planning interviews, managing tasks, tailoring resumes, and deciding what to do next.
Back to AI & DesignOpen live product
Experiment 03
JobJournal AI Build Documentation
This page documents how I moved JobJournal from a product brief and Figma direction into a working product build with AI support. AI helped with speed, code, and debugging, but the product decisions, visual review, and recovery from messy build issues stayed with me.
Live product
Jump into the working JobJournal build and explore the dashboard, tracker, AI analysis, resume suggestions, and task flow.
OpenCode
Build workflow and repo-level implementation support
Claude Code
Primary model for coding, debugging, and iteration
Figma
Research-led UX direction, visual system, and screen design
Product Brief
Single source of truth for scope, flows, stack, and constraints
Approach
From product thinking to a usable build.
I did not treat AI as a magic handoff from Figma to code. I first clarified what JobJournal needed to be: a calm workspace for job seekers who are managing many applications, deadlines, resume versions, and next actions across disconnected tools.
Once the product direction was clear, I used AI to help move through the build: creating the app shell, converting visual rules into reusable components, building each product page, linking frontend actions to backend data, and debugging the places where the generated output did not match the intended user experience.
Build Layers
What had to become real
Design system
I converted visual choices into rules for the app: primary color, page surfaces, type hierarchy, sidebar states, table rhythm, forms, badges, and empty states.
UI shell
I built the product frame around a protected app layout, consistent navigation, shared page headers, top-bar actions, and predictable page structure.
Reusable components
I standardized buttons, tabs, tables, dialogs, checkboxes, empty states, row actions, badges, and card surfaces so pages stopped drifting visually.
Product pages
I connected the main workflows into one journey: Dashboard, Tracker, Tasks, Calendar, Job Search, Profile, Resume, Settings, Job Analysis, Resume Tweak, and Subscription.
Backend link
I wired frontend actions to API routes, database tables, AI analysis records, resume suggestions, task suggestions, and usage-limit logic.
Recovery Moments
Where the build got stuck, and how I corrected it
The first scope was too wide
What went wrong: JobJournal had many useful ideas: tracking, calendar, resume builder, job search, saved jobs, AI analysis, profile, settings, and subscriptions.
How I recovered: I treated the brief as a map, then built the core loop first: understand a job, track it, create next actions, and return to the dashboard with a clearer setup state.
The UI started drifting page by page
What went wrong: Some screens had their own headers, cards, tables, tabs, and empty states. The product began to feel like separate screens instead of one app.
How I recovered: I moved the work back into shared rules and reusable components, then used those patterns across Tracker, Tasks, Job Analysis, Settings, and other high-traffic surfaces.
The tracker language needed to match behavior
What went wrong: The application area started with labels and status states that were not clear enough for the real job-search workflow.
How I recovered: I renamed the visible section to Tracker, simplified the header, aligned status values, added an empty state, and made the tab language match what users actually need to scan.
The backend path was not obvious
What went wrong: There were multiple server surfaces during the build, so linking frontend actions to the right API path was not a simple one-step task.
How I recovered: I diagnosed which server was active, checked the API base, verified health and route behavior, and treated backend connection as part of the product workflow instead of a hidden technical detail.
Live Product
Explore JobJournal as a working product.
This documentation focuses on the build process. The product itself is where the decisions come together: dashboard overview, tracker flow, AI analysis, resume suggestions, tasks, and backend-backed records all working as one experience.
What I learned
AI helped me move faster, but I owned the product judgment.
Used AI for
Product planningCode generationDebuggingDesign critiqueImplementation review
Learned
AI helped me move from design direction to a working build faster, but the product only improved when I gave it clear context, checked the output, and made the final UX decisions myself.
A strong brief made the AI output more useful.
Shared components fixed visual drift faster than page-by-page polish.
Working code still needed UX review before it felt like a product.