ApplyIQ

Applying for senior product roles is not a writing problem - it is a decision-making problem.

Every application requires a candidate to interpret an ambiguous job description, understand what the company is really hiring for, choose the right career evidence, adapt their positioning, select the most relevant CV and portfolio material, and keep track of what has already been submitted.

Most available tools treat this as a document-generation task. Paste in a job description. Generate a cover letter. Rewrite a CV.

That approach can make applications faster, but it does not necessarily make them better. It often produces generic language, weakens the candidate’s own judgement, and obscures the strategic decisions behind a strong application.

I designed and built ApplyIQ to explore a different model.

ApplyIQ is an AI-assisted application orchestration system that helps candidates analyse roles, define positioning, select evidence, manage application assets, and move from opportunity to submission without surrendering control to an opaque generator.

The product brings together product strategy, UX, front-end implementation, data modelling, AI orchestration, analytics, and design systems in one working application.

Role Product Designer & Full Stack Engineer

Capability AI-assisted workflows, Secure authentication, Cloud database architecture, Full-stack development

System AI system, Multi-tier architecture

The product opportunity emerged from a workflow I was already managing manually.

For each role, I needed to answer a sequence of connected questions:

• Is this role genuinely aligned with my experience?
• What is the company actually asking for beneath the wording of the advert?
• Which part of my background should lead?
• Which case studies provide the strongest proof?
• Which CV and portfolio variant should I use?
• What still feels unsupported or unconvincing?
• What did I submit, and what happened afterwards?

These decisions were spread across job boards, documents, notes, portfolio pages, email threads, AI conversations, and memory.

The problem was not a lack of information - it was a lack of structure.

Discovery & framing

The first product decision was to resist building another AI writing tool.

There are already many products that generate CVs and cover letters. Their underlying interaction model is usually the same: provide source material, ask the AI to write something, and accept or edit the result.

That model is efficient, but it places too much emphasis on prose and too little on reasoning.

A strong application depends on a chain of decisions made before the writing begins:

• interpreting the role
• identifying the strongest narrative
• selecting relevant evidence
• recognising gaps
• choosing the right application assets
• maintaining consistency across the submission

ApplyIQ therefore needed to support the thinking around an application, not simply generate its final documents.

The candidate needed to remain the decision-maker

This became the central product principle.

AI could analyse, compare, recommend, and identify patterns, but it should not silently decide how a person represents their career.

That meant every important recommendation needed to remain:

• visible
• explainable
• reviewable
• editable
• connected to supporting evidence

The product was framed as an orchestration layer between the candidate, their career history, the role, and the assets used to apply.

It was not designed to replace judgement - rather it was designed to make judgement more systematic.

The system needed durable memory

A chat interface is useful for exploring a role, but it is poor at maintaining an evolving application system.

Important decisions disappear into conversation history. CV versions become difficult to trace. Portfolio choices are repeated. Similar roles are analysed from scratch. There is no reliable record of why one narrative was selected over another.

ApplyIQ needed persistent structure.

The underlying product model therefore included:

• applications
• narrative angles
• CV variants
• portfolio variants
• recruiters
• role analyses
• case-study relevance
• application status
• submission readiness
• analytics and response signals

This shifted the product from a collection of AI prompts into a durable working system.

Designing the application workflow

The core workflow follows the way a strong application develops.

A role enters the system as an opportunity, not as an immediate writing request. The user then works through a sequence of decisions that progressively increases submission confidence.

The workflow connects:

1. role analysis
2. strategic positioning
3. evidence selection
4. CV choice
5. portfolio choice
6. submission preparation
7. outcome tracking

Each step informs the next.

Applications as the operational centre

The Applications view became the central workspace.

It needed to support both quick scanning and detailed decision-making across multiple active roles. Each application carries its own status, narrative angle, CV variant, portfolio route, strategic alignment, supporting rationale, and next action.

The challenge was to make a large amount of information useful without turning the screen into a dense project-management interface.

I resolved this through a layered information hierarchy:

• company, role, and status establish immediate context
• selected strategy and assets show the current application direction
• strategic alignment provides a quick confidence signal
• rationale explains why the system recommended that direction
• actions remain available without dominating the card

This gave each application enough depth to support real decisions while keeping the overall list scannable.

Narrative angles as reusable product strategy

One of the strongest product ideas in ApplyIQ is the narrative angle.

A candidate does not have one universal professional story. Different roles may require different emphasis while still drawing from the same underlying career history.

For example, the same person may be positioned through:

• AI-native product strategy
• design systems leadership
• complex enterprise UX
• data visualisation and decision support
• product design engineering
• organisational design maturity

Rather than recreating these narratives for every application, ApplyIQ treats them as reusable strategic assets.

Each narrative includes:

• a positioning statement
• relevant capabilities
• associated applications
• supporting CV and portfolio variants
• evidence coverage
• recommended proof
• known gaps and improvements

This transformed positioning from a paragraph written for one application into a structured, evolving model of professional evidence.

Evidence coverage made gaps visible

AI recommendations often sound convincing even when the underlying evidence is weak.

That creates a trust problem.

ApplyIQ addresses this by separating the recommendation from the proof supporting it. Narrative angles expose evidence coverage across areas such as technical capability, domain experience, outcomes, and leadership.

The product does not only say:

This is your strongest angle.

It also helps answer:

What supports it, and where is it still weak?

This makes the system more useful because it can challenge the candidate’s assumptions rather than merely reinforce them.

Designing AI as a transparent collaborator

The most difficult design decision was determining how much work the AI should perform. Too little, and the system becomes another manual tracker. Too much, and the candidate loses ownership of their own professional narrative. The solution was to use AI at defined decision points rather than allowing it to control the entire workflow.

Structured analysis instead of open-ended generation

Role analysis produces structured outputs rather than a long conversational response.

The system extracts and evaluates areas such as:

• core role signals
• expected seniority
• likely hiring priorities
• relevant career evidence
• narrative fit
• portfolio relevance
• risks and gaps
• suggested positioning

This structure makes outputs easier to inspect, compare, store, and reuse. It also prevents important reasoning from being buried inside persuasive but unstructured AI prose.

AI recommendations remain subordinate to user confirmation

The system distinguishes between recommendations made by AI and decisions confirmed by the user. That distinction matters.

A recommendation may identify a suitable narrative angle or portfolio route, but it should not silently become the application strategy. The user can review the rationale, override it, or confirm it. This creates a visible boundary between machine inference and human intent.

Explainability needed to exist inside the workflow

Explainability is often treated as an additional screen or technical detail.

In ApplyIQ, it is part of the interaction model.

Recommendations are accompanied by reasoning, evidence, and confidence signals so users can understand:

• why a narrative was selected
• which experience supports it
• what remains underdeveloped
• why a particular CV or portfolio route is relevant

The aim is not to expose every internal model operation. It is to provide enough context for the user to make an informed decision.

The product principle

AI can recommend the next move, but the user remains responsible for deciding how their experience is represented.

Building the product end-to-end

ApplyIQ was not created as a static Figma concept.

I designed and built the working application independently, including the product architecture, interface, front-end implementation, persistence model, authentication, AI workflows, and deployment.

The application uses:

• Astro and React
• Tailwind CSS
• Supabase authentication, database, storage, and row-level security
• OpenAI structured outputs
• GitHub-based development workflows
• Vercel deployment
• first-party and external analytics

Working without a dedicated development team meant the boundaries of the design role expanded quickly.

To ship the product, I needed to work through:

• database relationships
• data persistence
• authentication states
• server and client boundaries
• schema evolution
• API contracts
• prompt versioning
• model outputs
• failure states
• deployment behaviour
• design-system architecture

That implementation work changed the design itself.

Product decisions could not rely on idealised screens. They had to account for latency, missing data, permissions, model uncertainty, state transitions, and the realities of production software.

Creating a scalable design system

As ApplyIQ grew, interface consistency became a system problem rather than a styling problem.

The application includes dashboards, workflow cards, status controls, forms, analytics, data tables, AI outputs, application records, and public portfolio surfaces. Without clear component ownership, small visual inconsistencies began to spread across the product.

I developed a token and component architecture to create clearer boundaries between:

• primitives
• themes
• semantic tokens
• component tokens
• product-specific styles

This included formalising ownership for components such as buttons, panels, cards, and application surfaces. The goal was not merely visual consistency. It was to make the product easier to evolve without introducing hidden dependencies or repeatedly rewriting styles.

From Figma intent to production rules

The design system was treated as both a visual language and an implementation contract.

That meant defining:

• component responsibilities
• token dependencies
• theme behaviour
• reusable interaction patterns
• migration rules
• documented exceptions
• validation standards

This was particularly important because the product spans both a public portfolio and a private application environment, each with different visual needs but shared foundations.

Analytics as product feedback

ApplyIQ also needed to answer whether the application strategy was producing meaningful outcomes. The Analytics view combines application movement, readiness, narrative usage, portfolio interactions, and response signals.

The intent was not to create vanity metrics. The useful questions were more practical:

• How many applications are active?
• Which have reached submission readiness?
• Which narrative angles are being used?
• Which portfolio routes receive attention?
• What response signal is emerging?
• Where does the workflow repeatedly stall?
• Are recruiters or hiring managers engaging with the evidence provided?

This creates the foundation for a more reflective application process.

Instead of treating every outcome as isolated, the user can begin to see patterns across role selection, positioning, evidence, and response.

The hardest design decision

The hardest decision was how to use AI without turning ApplyIQ into an opaque application generator. The product needed to provide enough intelligence to materially improve the process while preserving the candidate’s authorship and judgement. I resolved this by designing AI as one layer inside a structured orchestration system.

The model can analyse a role, recommend a narrative, identify evidence, and expose gaps. But those outputs remain connected to durable records, visible rationale, and explicit user decisions. That distinction shaped the entire product. It influenced the interface, database model, workflow, prompt architecture, and design system.

Outcomes & reflection

ApplyIQ is now a working AI-native SaaS product supporting the full application lifecycle. It demonstrates how a fragmented, repetitive process can become a coherent decision-support system when AI, product architecture, and interface design are developed together.

What the product now enables

• centralised management of active and historical applications
• structured AI analysis of job descriptions
• reusable narrative strategies across different role types
• evidence-based CV and portfolio selection
• visible gaps in professional positioning
• persistent application decisions and status history
• submission-readiness tracking
• analytics across application behaviour and response signals
• a scalable design system shared across public and private product surfaces

Why this matters

Most job-application products focus on generating more content. ApplyIQ focuses on making better decisions.

That difference matters because senior applications are rarely improved by producing more generic material. They improve when the candidate understands the role, selects the right evidence, communicates a coherent point of view, and can explain why they are a credible fit.

ApplyIQ turns those decisions into a visible, reusable workflow.

Reflection

Building ApplyIQ changed how I think about the relationship between product design and implementation. The interface could not be designed separately from the AI architecture, database, state model, or evidence system. Each part influenced the others. It also reinforced that frameworks are tools rather than fixed professional boundaries.

I began with the product problem and learned the front-end, backend, AI, and deployment capabilities required to bring the system into production. The most valuable skill was not prior fluency in every technology. It was the ability to move between product strategy, interaction design, systems thinking, and implementation without losing sight of the user.

ApplyIQ is the clearest expression of that way of working.

Not a design handed over for someone else to build, but a product designed, implemented, tested, and evolved as one connected system.