myTrajectoryA job-search platform built to preserve effort, context, and trust

1. The Problem

The longer a job search goes on, the more gets lost. CVs live in one folder, applications in a spreadsheet, interview notes in another app, and AI tools sit off to the side with no memory of the person using them. Most software makes this worse, not better.

The result is a fragmented experience where:

• People lose track of what they have applied for and when
• Interview stories are rehearsed once and forgotten by the time they matter
• Career advisors ask “how’s it going?” because they genuinely cannot see
• AI tools exist in isolation, with a CV review here and a cover letter generator there, each operating without any context about the person using them

The core problem is not just writing applications. It is losing useful work every time you do. I wanted to build something different: a workspace where the parts of a job search actually connect, where AI works from real context, and where useful effort carries forward instead of being thrown away after one use.

2. Three Audiences, One Ecosystem

If the primary user is already under pressure, the product should not introduce another kind of pressure just to exist. I wanted this to work as a social good if possible, which meant finding a model that did not rely on charging job seekers for support they may need most when money is tight.

That led to the three-audience structure. It was not business-model thinking first. It was a product constraint: if the candidate experience is the core value, other parties need to fund or sustain the system only where they receive genuine value themselves.

Job seekers

The primary user. Everything else in the platform only matters if it improves their ability to think clearly, prepare properly, and avoid restarting from zero for every role.

Charities & employment support organisations

Many job seekers are supported by charities and employment programmes. These organisations need a way to support people using real context rather than repeated recap. myTrajectory gives advisors a consent-gated workspace showing activity, applications, and goals. In return, the organisation can cover running costs so their clients do not have to.

Recruiters

As candidates prepare for roles by refining CVs, writing STAR stories, and tracking applications, some of that work can also support a recruiter-facing layer. Candidates who choose to be discoverable can appear in recruiter search, and only those who have explicitly opted in are visible.

This is an emerging product surface with substantial groundwork in place. Recruiters can paste a job description and search against experience records using meaning-based matching rather than keyword overlap. Candidate views can include an orientation summary, a requirement-by-requirement role fit analysis, and an AI interface for investigating the record further (“Has this candidate managed a P&L?”). The intended workflow is deliberate: research, evaluate, question, then contact.

Its value still depends on enough candidates opting in, and it still needs user testing and validation with recruiting professionals.

Ecosystem thinking: Each audience makes the platform viable for the next. Charities adopt the platform to support clients they already work with, and cover the running costs for their clients. The preparation those clients do naturally builds rich experience records. With consent, those records become discoverable by recruiters. The candidate experience is the product, not the cost centre.

3. A Connected System

The central design principle is that useful work should carry forward. Most job-search tools treat each task as separate: a CV edit, an application, an interview story, a support conversation. myTrajectory is designed so that each of those actions leaves behind context the rest of the product can reuse.

That is the real system idea. Features are not meant to sit beside each other. They are meant to strengthen each other.

When someone uploads a CV, three things happen without them lifting a finger. The text is extracted, AI analyses it in three passes (summary, strengths, improvements), and the Experience Record, a structured model of the candidate’s professional identity, is automatically populated with reusable experience data. The user sees a CV review. The rest of the product gains context it can use later.

When that same person records a STAR interview story, it can be linked to an experience in the Record, connecting the narrative detail of an interview answer to the structured claims from their CV. Meanwhile, as they upload multiple CV versions tailored for different roles, the system captures how they have described the same experience in different ways. Over time, the Record holds not just what they did, but the different framings they have used across contexts.

When they save a job application and add materials like a cover letter, the same extraction runs again. When AI later needs to draft a cover letter for a different role, it can draw from the full record, not just the latest CV, but the broader range of ways that person has already described their work.

Meanwhile, all of this activity feeds the Activity Intelligence engine, which detects patterns across a 14-day window. Are they applying but never practising interview stories? Are they active but scattered across too many things? Has momentum dropped? The system surfaces these insights as actionable signals, and if an advisor is connected, they see those same signals on their dashboard.

Systems thinking: The product is built so that effort is reused rather than discarded. CVs feed the Experience Record. STAR stories feed it too. Applications draw from it. AI uses it. Activity creates signals from it. Advisors, where permitted, can support from the same shared context.

What the workspace includes

The core workspace brings together the parts of a job search that are usually fragmented: CVs, applications, interview stories, priorities, focused work sessions, networking, and supporting automation such as job capture and email-linked updates. The point is not breadth for its own sake. The point is that progress in one area should improve the next decision somewhere else.

4. The Experience Record

The Experience Record is the core product idea because it changes the shape of the whole system. It is not a bigger CV. It is the mechanism that stops job-search effort being lost. More specifically, it is a structured record of a person’s professional identity that preserves how they have described their real experience across time, roles, and contexts.

People rarely have one fixed way of talking about what they have done. They tailor CVs for different roles. They answer application questions in a different tone. They explain the same achievement one way in a cover letter and another way in an interview story. Some experiences appear in one version and disappear in the next. Normally, that work is disposable: each adaptation serves one application, then gets lost.

The Experience Record is designed to stop that loss. It keeps the underlying experience, the richer story behind it, and the different ways the person has already articulated it. Instead of starting from a blank page each time, the system can draw from a growing body of real, previously used material.

Take a single achievement, “improved API response times.” The Experience Record might hold three variations:

• From the CV: “Reduced API response times by 40% through query optimisation”
• From a STAR story: “Identified the slow queries using profiling tools and rewrote the critical path, cutting average response from 800ms to 200ms”
• From a cover letter: “Led a performance initiative that halved backend latency for 50,000 daily users”

Each variation is preserved with its source, its status (new, pending, verified), and the context in which it was created. The aim is not to let AI invent a better version of the candidate. It is to help the system recognise which truthful version of a real experience is most relevant to a given role and bring that forward.

Over time, this becomes more valuable than any single CV because it turns short-term application effort into a longer-term career asset. When AI generates role-specific content, such as tailoring a profile for a DevOps role rather than a backend engineering role, it can assemble the strongest framing from the person’s own history rather than flattening everything into one generic version.

The graph is maintained automatically. Cloud Functions fire on CV upload, STAR answer completion, and application material submission, extracting experience claims and adding them as new nodes, items, or variations. The user never needs to manually synchronise anything. They also have a chat interface where they can explore their own Experience Record conversationally, asking questions like “what have I said about leadership?”

Product thinking: The Experience Record closes the gap between having experience and being able to express it well. By preserving meaningful versions of how someone has described their work, the platform turns one-off application effort into something they can reuse later.

5. The Voice Agent

Interview preparation has a fundamental tension: the best way to prepare is often to talk through stories out loud, but the deliverable you need is a written, structured answer. Typing forces you into writing mode too early. Speaking is more natural, but without help it produces unstructured rambling.

The Story Companion resolves this. It is a conversational AI agent that guides users through STAR story capture via natural speech, and it builds and revises the structured story during the conversation as the session unfolds. The point is not novelty for its own sake. It is to make one of the hardest parts of interview preparation easier to capture without losing quality.

The user talks. The agent listens, asks follow-up questions (“What was the specific outcome?”, “How did you measure success?”), and progressively structures what it hears into the four STAR sections: Situation, Task, Action, Result. As new details emerge, the agent revises earlier sections. The user can see the written story taking shape as they speak.

The result is that someone can talk through an interview story in their own words and come away with a structured, reusable STAR answer without typing a paragraph. It lowers the effort of capture while improving what gets saved.

Why this needed deeper engineering

Making that feel natural required solving problems that simpler AI features can usually ignore:

• Real-time streaming: a WebSocket-based relay streams transcripts between the voice input and the AI, with connection state management and automatic reconnection if the connection drops
• Context window management: long conversations accumulate more context than a model can handle in a single call. A rolling window utility maintains the most relevant recent messages while truncating older content, preserving conversational coherence without overflowing token limits
• Session persistence: copilot sessions are saved locally with a two-hour expiry window, so users can pause and resume without losing their progress

Once the story is complete, it goes through the same review and refinement flow as a typed answer. The important product choice is consistency: speaking is just a more natural way to get good material into the system, not a separate second-class workflow.

6. AI as Infrastructure

AI in myTrajectory is used to support thinking, structure, and reflection. It does not invent achievements, overwrite the user’s voice, or fabricate confidence. The user stays in control of what is true, what to keep, and how they present themselves. Their words stay theirs.

That matters because the product depends on preserving how people describe their own experience over time. If AI starts inventing things or flattening that detail, the whole system loses its value. The key decision was therefore to treat AI as infrastructure: grounded in preserved evidence, useful across workflows, and deliberately constrained rather than theatrically autonomous.

Why multi-provider?

I did not want to be tied to a single provider, and I wanted charities to be able to bring their own API key to cover AI costs directly, with transparency in mind. That meant the provider had to be configurable.

In practice, that gives flexibility without having to rewrite the product around a vendor. Organisations can fund usage through the provider they are comfortable with, and model choices can change as cost, quality, and availability change. That keeps the platform adaptable instead of locking core behaviour to one provider relationship.

In simple terms, that means the AI layer can improve over time without forcing the whole application to be redesigned around each model change.

Why validate every response?

If AI is going to sit inside core workflows, it cannot be allowed to behave like a toy. Responses need to be checked before they are trusted so the product stays reliable even when model behaviour varies. That is the difference between a nice demo and something people can build real habits around.

Why track every token?

AI is expensive at scale, and the cost must be distributed fairly, especially when charities are funding usage on behalf of job seekers. Usage therefore has to be measurable, transparent, and controllable. Otherwise the sustainability model breaks down as soon as the product becomes genuinely useful.

This level of cost tracking is unusual in AI-powered applications, but it is essential for a platform where one party pays for another party’s usage.

Public profiles as an AI interface

Candidates can share their profile publicly in a way that is more useful than a static page. The aim is not just to present a summary, but to let someone explore the person’s experience through grounded questions, role-fit investigation, and richer evidence. The candidate decides whether that visibility exists and how open it should be. That future-facing layer only works if the underlying record is trustworthy first.

7. Trust & Collaboration

Advisor access is a trust problem before it is a feature problem. An advisor needs enough visibility to be helpful, but the candidate must still feel that the workspace belongs to them. Get this wrong and trust collapses.

Consent as product design

The solution is three granular consent scopes. Each one can be granted or revoked independently:

That trust only works if the boundaries are real. Consent cannot be symbolic or buried in settings. It has to be specific, revocable, and dependable enough that users believe the platform means what it says when it claims they are in control.

That matters ethically as well as operationally. Once organisations are involved, trust is not a nice-to-have. It is part of the product itself.

What advisors see

The advisor view is designed to reduce recap and increase useful intervention. Advisors can see where support may be needed, understand what a client has actually been doing, and add resources or recommendations directly into the same shared environment.

The relationship becomes more practical: less chasing for updates, more targeted help at the right moment. That is important because support is most useful when it is grounded in real context rather than memory, confidence, or guesswork.

Closing the loop with notifications

Visibility inside the workspace is not enough if neither party knows to look. When something meaningful happens (an advisor is assigned, consent is granted or revoked, a resource is recommended, or a message is sent) the platform sends a transactional email so the right person finds out without having to check. Users control which notifications they receive through granular preferences, and every email includes one-click unsubscribe.

This matters because the advisor relationship depends on timely awareness. A resource recommendation that sits unseen for a week is barely a recommendation at all. The notification layer turns the collaboration model from something that works when both parties happen to be logged in into something that works regardless.

8. Activity Intelligence

Job seekers often struggle with a question that is simple to ask and difficult to answer: “Am I doing the right things?” They might be busy but scattered, or focused but neglecting interview preparation, or applying to roles that do not match their stated priorities.

The Activity Intelligence engine exists to answer that question with evidence rather than mood. It analyses behaviour patterns across a recent rolling window and surfaces actionable signals. It looks for momentum, gaps, misalignment, and re-engagement, not as abstract analytics, but as prompts that help someone decide what to do next.

Examples: a momentum spike fires when activity is significantly above the rolling average. An application gap fires when the user is active in other areas but has not applied to anything recently. Priority misalignment fires when applications do not match stated goals. No STAR practice fires when applications are in progress but no interview stories have been recorded.

Signals are prioritised so the most important issues rise first, and users can dismiss them if they are not helpful. The aim is useful guidance, not constant prompting.

Why pure functions matter here

Because these signals affect how the product guides people, they need to be dependable. The detection logic is therefore designed to be predictable and testable rather than buried inside opaque application code. That matters because trust in guidance depends on consistent behaviour.

9. Technical Foundation

The architecture follows directly from the product constraints. The platform needed to support a connected workspace, background processing, AI-assisted workflows, and organisation-aware collaboration without turning the experience into a collection of slow, fragile pages. The full stack is documented separately.

What mattered most was not choosing fashionable tools. It was choosing an architecture that could preserve shared context, support background processing, and keep the product reliable as it grew.

Patterns worth noting

Consistency matters when a product spans many workflows. Repeating the same defensive patterns across the stack makes behaviour more predictable, makes failures easier to reason about, and reduces the chance that one part of the workspace feels trustworthy while another feels brittle.

Resilience was a product choice as much as a technical one. This is a tool people may rely on during a stressful search. Reliability, safe rollout, and traceability are not invisible engineering luxuries; they are part of what makes the workspace usable in real life.

Cloud Functions

Some of the most important work in the platform happens after the user has moved on: CV processing, Experience Record updates, synchronisation, reminders, and other background tasks. Handling that asynchronously is what lets the workspace feel responsive while still doing meaningful work behind the scenes.

Testing

Testing matters here because the product makes judgments, suggestions, and structural transformations that users may come to rely on. The philosophy is to separate complex logic from side effects wherever possible so behaviour can be checked deterministically. The technical reference covers the implementation detail.

UX philosophy

The platform follows a principle of “teach only at moments of action.” There are no tutorials, no onboarding guides, and no documentation pages. Instead, one-time dismissible teaching moments appear at the point where guidance is useful, such as the first time a user sets a reminder or sees a networking suggestion. The user learns by doing.

An onboarding intake captures the user’s job search stage and goals, and the workspace hub shows contextual cards based on role, assignment status, and feature state. Advisors see client cards, candidates see activity and resources, and pinned recommendations appear for users with assigned advisors.

10. What Makes It Different

Most job-search tools store information, but they do not do much with the connection between one piece of work and the next. myTrajectory is built on a different premise: a job-search platform should preserve effort, connect context, and help people make better decisions over time.

myTrajectory is built around a simple idea: job-search effort should not disappear. It should leave behind context the user can reuse, guidance they can trust, and support grounded in what they have actually done.

The platform is currently in live pilot with two charity partners. A built-in feedback mechanism captures the user’s recent actions alongside their comment, so issues and suggestions arrive with real context rather than vague descriptions.

Technical reference → for implementation detail on the architecture, data model, AI layer, background processing, security patterns, and design system.