AI Product · Job Application Workspace · Independently built · In development

Ply.ai

Role

Creator & Product Designer

Type

AI product · Job application workspace

Stage

In development

Ply.ai MacBook mockup

What I actually Designed

Product vision·Product strategy·Information architecture·User flows·UX & UI design·Design system direction·AI workflow design·Browser automation UX·Frontend implementation direction·Product vision·Product strategy·Information architecture·User flows·UX & UI design·Design system direction·AI workflow design·Browser automation UX·Frontend implementation direction·

The Broken Ritual

“Job searching doesn't reward quality. It rewards endurance.”

Every application runs the same ritual: read the JD, revise the same CV, write a cover letter that sounds like the last one, fill fifteen form fields manually. Fifty applications. Fifty repetitions.

Existing tools try to fix this and fail. Keyword optimisers make you sound like the job description. AI cover letter generators produce plausible, generic output. Auto-apply bots fire without the candidate knowing what was submitted. The shared flaw: all treat applications as document problems. None treat the candidate as the source of truth.

The time cost

Careful tailoring takes 1 to 3 hours per application. Multiply that across a real job search.

The authenticity cost

By application 30, candidates aren't presenting themselves. They're performing a script.

The compounding problem

Quality and volume pull against each other. The more you apply, the less each one sounds like you.

AI should understand the candidate before optimising for the job.

A good recruiter doesn't open with your CV. They start with who you are, what you've built, where you're going, then help you present that self in context.

Ply.ai builds on that principle. Before any job is imported, the Candidate Profile exists: career history, skills, projects, goals, voice, Master CV. Every output draws from it. The candidate isn't reacting to the job. The job is evaluated against a complete picture of the person.

Knowledge structure

Candidate Brain

Career History

Roles

Companies

Scope

Progression

Projects

WUZO

WiiTH

Ply

Skills

Product Design

Interaction Design

React

AI Workflows

Goals

Product Designer

AI SaaS

London

Preferences

Tone

Working style

Role filters

Master CV

Experience

Education

Achievements

Job Description

Tailored application

The candidate remains the source of truth.

Every output is composed from the persistent record, not from a generic application pattern.

Product Architecture

Four layers, each with a single clear responsibility. Separating concerns meant each layer could be reasoned about, tested, and improved independently.

Five decisions

Workspace, not wizard

Applications span hours, days, sometimes weeks. A wizard asks candidates to finish everything in one sitting, then forgets the state between sessions. Ply.ai needed to behave like a workspace because an application is a lifecycle, not a form.

The product got structurally more complex so the candidate's experience could become simpler.

Tailoring through selection

AI surfaces items from the candidate's own record — nothing invented.

Human approval states

AI proposes.

Candidate reviews.

Candidate approves.

Each answer approved independently — Draft, Approved, or Submitted.

Outcome stages, not process steps

The earliest versions exposed too much. Six visible stages. Candidates were managing the system's process instead of their own decisions. The product got simpler as the thinking got clearer.

Earlier model

· Analyse

· Evaluate

· Tailor

· Review

· Export

· Apply

6 stages · Candidate manages the process

Current model

· Opportunity analysed

· Documents ready

· Apply with Ply

Candidate sees outcomes.

Supervised browser assistance

Stable fields detected and filled — candidate retains control throughout.

Ply.ai tailoring through selection interface
Ply.ai human approval states
Ply.ai supervised browser assistance
"The hardest part wasn't designing AI. It was deciding where AI should stop."

Autonomy vs. control

Every time the product got faster, I had to ask whether a decision had moved away from the candidate without their awareness. Speed isn't always the right optimisation.

Simplification vs. transparency

Hide complexity badly and candidates see something broken, not something simple.

Learning through implementation

Building across product, UX, and code meant constraints were real. Technical limits shaped design decisions.

Automation vs. judgment

Some steps belong to the system. Some belong to the candidate. The design work is deciding which is which.

What I'd revisit

The Candidate Profile onboarding. The system's quality ceiling is a design problem before a technical one — it deserved more attention in the earlier stages.

The visual weight of Draft → Approved → Submitted. The states exist. Their significance to the candidate's sense of progress could be communicated more clearly.

Where Ply.ai goes Next

These aren't features. They're extensions of one principle: help the candidate show up as themselves, more effectively, every time.

Long-term career memory

The Candidate Profile improves with every application, building a compounding record across multiple job searches, not just one.

Consistent self-presentation

The same person, presented coherently across every application, format, and channel.

Trustworthy automation

Progressively wider browser intelligence, earned only as the system demonstrates reliability.

Interview preparation

The same Candidate Profile that builds applications prepares candidates for the conversations that follow.

© 2026 Victor Chu. All rights reserved.