Case study

Pathfinder Pro

Building a production AI recommendation system in six weeks

I took Pathfinder Pro from a founder’s concept and study-program dataset to a live, fully automated product, owning product definition, UX, AI architecture, implementation, evaluation, and launch.

The system combines structured psychological assessments, qualitative self-report, educational background, and professional interests to recommend three current Swiss university programs and generate a personalized report explaining the fit, associated career paths, and practical next steps.

The founder brought the concept, assessment approach, market-research expertise, and study-program data. I designed and built the product and production system around them.

Cover of a Pathfinder Pro personalized university recommendation report.

Role

AI Product Architect & Developer

Timeline

6 weeks · April–May 2025

Scope

Product · UX · AI architecture · Implementation · Evaluation · Launch

Outcome

100+ paid reports · Fully automated · Still in production

WEBSITE

Visit Pathfinder Pro ↗

The problem

Pathfinder started with a deceptively simple idea: understand a student well enough to recommend the three Swiss university programs most likely to support a satisfying study and career trajectory.

Each student profile combines qualitative self-report—self-description, values, and deep interests—with Big Five personality dimensions, RIASEC vocational interests, Schein Career Anchors, educational background, fields of interest, and self-identified professional orientations.

The result had to be more useful than a ranked list. The report needed to help the student understand themselves, see why particular programs fit, connect those programs to plausible career directions, and take practical next steps.

Which three real programs best fit this person across several different dimensions—and how do we explain that judgment in a way the student can actually use?

Constraints

Six weeks

Concept to paid production product, which needed to be live for the 2025 highschool graduation class – the core target group.

~100 information-rich programs

The source material was detailed and carefully prepared; losing that detail would weaken the recommendation.

Limited budget

There was no economic case for custom model training or heavy ML infrastructure.

No ML team

The product had to be buildable and operable without dedicated MLOps capacity.

Nontechnical founder

The system needed to remain configurable and understandable after handover.

Decision quality mattered

The output needed to support a student's education and career choice – a very consequential life decision.

Core architecture

The first architecture did not survive contact with the real data.

We initially prototyped a direct path from the student profile and complete study-program corpus to the final three recommendations. Once the full program content was included, the context became impractical and hit token limits.

The obvious workaround was to shorten the program descriptions.

I argued against that. The content was valuable product data, not implementation overhead. Removing useful information to accommodate the architecture would have solved the technical problem by weakening the product.

Instead, I redesigned the system around the decision itself.'

The structured and qualitative inputs are assembled into a rich student profile. A textual representation of that profile is used for embedding retrieval, reducing roughly 100 programs to the 10 most relevant candidates.

The reranker then receives the richer student profile together with those 10 candidate program records and makes the actual multidimensional Top-3 decision. Career-path reasoning and report generation happen downstream from that decision.

Retrieval reduces the search space. The LLM makes the multidimensional judgment.

Three decisions that shaped the product

ARCHITECTURE · DECISION 01

Preserve information quality by changing the architecture

The failed prototype revealed that the program corpus was too rich for the original full-context approach.

Truncating the program descriptions would have been fast, but it would also have removed distinctions that mattered to recommendation quality. Embedding similarity alone was not sufficient either: it could find plausible programs, but the final decision had to balance personality, vocational interests, motivation, educational background, explicit interests, and qualitative self-report.

I therefore split the task:

Retrieval reduces the search space. The LLM makes the multidimensional judgment.

This preserved the source information while making the reasoning problem tractable.

AI BEHAVIOR · DECISION 02

Tune the decision, not just the writing

The reranker could sometimes produce convincing explanations while overweighting particular assessment dimensions.

That exposed an important failure mode: fluent reasoning did not guarantee a good selection.

I tuned the recommendation logic against profiles we knew well, examining the resulting Top 3 programs and career paths and adding explicit constraints where the model’s judgment became unbalanced.

The objective was not better prose. It was better decisions.

OPERATIONS · DECISION 03

Design for operator independence

The founder needed to be able to evolve the product without depending on me.

The operator works with understandable product concepts; the technical machinery stays behind the interface.

I exposed the things likely to change—program data, models, recommendation logic, report content and design, and customer communications—through founder-accessible tools rather than burying them in code.

A concrete example: when the founder edits a study program, the downstream record is synchronized automatically and its embedding regenerated.

What AI did – and what stayed deterministic

Deterministic

assessment scoring
data transformation
explicit validation
order and payment state
exact system synchronization

AI

profile synthesis
candidate reranking
multidimensional fit reasoning
career-path reasoning
personalized report writing

Human-controlled

study-program source data
prompts and selection logic
model configuration
report content and tone
customer communications
recovery and resend actions

Use deterministic logic where exactness is available. Use AI where interpretation and synthesis create value. Preserve human control where the system needs to remain editable or recoverable.

Building the production system around the AI

Pathfinder became a small but highly interconnected production system. The normal customer journey runs end to end without manual report production, while the founder retains control over the data, configuration, and exceptional cases that require intervention.

Diagram showing Pathfinder Pro’s automated production flow from assessment and checkout through recommendation generation, PDF assembly, delivery, and operational controls.

Core workflow 01

Assessment → checkout

A submitted assessment is processed into a customer and order, checkout is created automatically, and payment state determines whether the order proceeds to generation.

Core workflow 02

Recommendation → report → delivery

Once payment is confirmed, the system builds the student profile, runs the recommendation pipeline, generates personalized report content and charts, assembles the PDF, and delivers the completed report automatically.

Founder-facing Airtable OMS/CMS for managing Pathfinder Pro customers, orders, payments, study programs, configuration, and errors.

Built for operator independence

I built the founder-facing OMS/CMS around the objects he actually needed to manage: customers, orders, payments, products and pricing, study programs, and errors.

The founder can update program data and key system configuration without touching the underlying workflows. Exceptional cases remain recoverable: orders can be created manually, and reports can be regenerated and resent when needed.

Test

Assessment flow

Orchestration

Data & retrieval

AI & report generation

Operational controls

PROD

Assessment flow

Orchestration

Data & retrieval

AI & report generation

Operational controls

Built to change safely

As the system became more interconnected, changes to one component could affect several others. I created parallel TEST and PROD environments across the major parts of the product so changes could be exercised before affecting live orders.

This allowed changes to workflows, prompts, models, data, retrieval behavior, and integrations to be tested as part of the actual end-to-end system before being promoted to production.

Automatic recovery

Retries

validation

Escalation

Structured log

Notification

Operator Recovery

Regenerate

Resend

Manual

Intervention

Built to recover

I designed common transient and formatting failures to recover automatically where possible. API calls could retry, structured outputs were validated, and malformed outputs could pass through repair steps—including AI-assisted repair—before the workflow was treated as failed.

If automatic recovery was not enough, the failure was captured in a structured error log and surfaced through notifications. The affected order could then be regenerated, resent, or handled manually rather than disappearing inside workflow execution.

Evaluation focused on the decision, not the demo

For a recommendation product, polished output is not enough. The central question is whether the system is actually making useful decisions.

We repeatedly tested Pathfinder using ourselves and people we knew well enough to judge the results meaningfully.

Profile Fidelity

Does the profile represent the person?

Retrieval Sanity

Are the 10 candidates plausible?

Recommendation Quality

Are the final 3 genuinely right?

Consistency & usefulness

Are reruns stable, grounded and useful?

Most tuning effort went into recommendation quality.

I repeatedly regenerated fixed profiles after changes and compared the results. Prompts, selection constraints, and model temperature were tuned against recommendation quality and reproducibility rather than simply writing style.

Grounding and factual correctness of program information worked well early. The harder problem was selecting and explaining the right three programs consistently across a multidimensional profile.

Outcome

Pathfinder went from concept to a live, paid product in six weeks. The resulting system runs end to end without manual report production and can be operated by the founder without a technical team.

6 weeks

Concept to production.

100+

Paid reports generated.

Fully automated

Assessment through report delivery.

Still live

The product remains in production.

View sample report ↗

What I’d keep – and improve

Keep

Retrieve → rerank architecture

The split still matches the actual recommendation problem.

Pragmatic infrastructure

The system is appropriately engineered for its current scale.

Operator independence

The founder can run and evolve the product without a technical team.

Improve

Automated evaluation

A more systematic eval layer would make changes faster, safer, and more measurable.

Real user outcome feedback

Longitudinal evidence about students’ eventual choices would become the strongest input for improving recommendations.

Infrastructure at greater scale

With materially higher volume or more frequent changes, I would move the core workflows into a coded implementation and introduce deeper observability.

The architecture followed the product problem: preserve the information needed for nuanced recommendations, use AI where judgment mattered, keep predictable steps deterministic, and design the live system around how it would actually be operated, changed, and recovered.