Offboard
Job seekers lose most of their time to work that has nothing to do with the job: rebuilding the same context across a dozen tools that do not talk to each other.
- Role
- Founder & Product Designer
Product direction, UX, interface design, full-stack implementation, and iteration
Working product
Built end to end. The next product question is whether the first step meets the seeker where they are, not simply whether a packet can be generated.
On this page
Context and ownership
Researching a company, tailoring a resume, preparing outreach, and tracking progress often means rebuilding the same context in separate tools. I founded, designed, and built Offboard to connect that work.
My scope spans product direction, interaction design, implementation, and operation. Job Packets is the focused workflow in this story: turning a role into research and editable application materials, while preserving the person's decision about whether to pursue it.
Product model
Treating a job as a row in a tracker leaves its supporting work scattered elsewhere. I made the opportunity the organizing unit for the role, company, people, research, materials, preparation, tasks, and history.
LUMO, the AI layer, works across that stored context. A Job Packet is one coordinated workflow inside the broader product. It is not a separate story about a separate application.
Decision 01
Automating more documents is not helpful if the opportunity deserves a second look. The packet workflow assesses the role before generating tailored materials. A risk gate can pause progress so the person can decide whether to continue.
This is a warning and a choice, not proof that a listing is fraudulent or a guarantee that a role is good. The product needs to make the assessment useful without pretending to know an employer's intent.
The risk gate
- Role submitted
- Role intelligence
- Risk assessment
- Flagged?
If YesPause for the user's choice
- Continue to tailored materials
Decision 02
The person should be able to inspect and edit the result before using it. Packet outputs remain drafts. Nothing sends itself to an employer. If a resume is missing, the workflow can skip resume-dependent writing and return a partial packet instead of inventing the person's experience.
That does not mean every internal action needs approval. Filing results into the tracker can happen automatically. The meaningful boundary is between organizing work inside the product and representing the person outside it.
Draft, review, decide
- Prepare research and drafts
- File results in the workspace
- Person reviews and edits
- Person decides what to use
Decision 03
Parsing the role once and sharing research across downstream tasks avoids asking each step to rediscover the company and requirements. The same context can inform resume work, outreach, and interview preparation.
The design tradeoff is consistency versus stale information. Reuse is useful only while the underlying context remains relevant. This case study describes the coordination model; it does not claim a measured cost or latency reduction.
What changed
Job Packets initially carried too much of the burden of introducing Offboard. It assumes someone already has a role worth pursuing. A person facing a fresh career transition may first need direction and a manageable next step.
I moved the product story toward a plan-first journey, with packets later in the sequence. That changes the design question from “Can we generate a complete packet?” to “Can this person take their first useful action?”
This is a product-direction correction. I do not yet present a measured activation or conversion lift for the change.
How it is built
I designed and built the product with AI development tools as part of the workflow. The client uses Vite, React, TypeScript, Tailwind, and shadcn/ui. Supabase provides Postgres with per-user row-level security, and Deno edge functions coordinate server-side work.
The architecture supports persistent context, AI workflows, document generation, authentication, credits, employer workspaces, and paid plans. Those are product capabilities, not evidence of adoption or revenue.
How data and actions move
- Client applicationVite · React · TypeScript · Tailwind · shadcn/ui
- Authentication and access controlRow-level security per user
- Opportunity data modelSupabase · Postgres · RLS
- Server-side functionsDeno edge functions
- Model APIs
- External research
- Document generation
- Results written back to the workspace
Product
The product screenshot at the top of this page shows a completed Job Packet marked ready for review. The role, match assessment, research sections, and prepared materials stay together, with the pipeline visible alongside them.
The workflow completing is not the same as an application being sent. The packet gives the person a place to inspect the result and decide what to use next.
Outcome
Offboard moved from product concepts into live beta workflows through my design and implementation work. The evidence here establishes a built product and the reasoning behind its workflow.
It does not establish adoption, repeat usage, revenue, or a conversion improvement. The next evaluation needs to connect a person's starting situation to their first completed plan action and subsequent use of a packet.
Reflection
A polished workflow can ask for the wrong commitment at the wrong time. The correction was to give the person's readiness as much attention as the packet's completeness.
I would test the initial journey with people at different stages of a transition, observe where they hesitate, and check whether the next action is useful before measuring how much the system generates.