Building the First Version of Oppli

The first version of Oppli was built around one main experience: helping users move through job opportunities without feeling buried beneath them.

The interface was designed to be mobile-first and simple.

A user would complete onboarding, upload a resume, choose their preferred roles and locations, and receive job cards selected for their profile. They could review a job, see important details, evaluate their match, and decide whether to continue.

On the surface, it sounded straightforward.

Underneath, it was anything but straightforward.

Simplicity requires a lot of machinery

A clean job card might only show a title, company, location, salary, and match score.

But producing that card required several systems to agree with each other.

The application needed to understand:

What the user wanted.

What the user had actually done.

What skills appeared in their resume.

What the employer required.

Whether the job was still active.

Whether the location was acceptable.

Whether the opportunity had already been shown.

Whether the user had saved, declined, or applied to it.

Then it needed to present that information without overwhelming the person using it.

This is one of the recurring lessons in product development: when an interface feels simple, someone probably moved the complexity somewhere else.

Usually into the backend, where it waits patiently to ruin your evening.

The early matching system

One of the major parts of the original Oppli was the match score.

The idea was to compare a candidate's profile with a job description and produce a percentage showing how closely they aligned.

That comparison included factors such as:

Relevant skills.

Job title alignment.

Experience level.

Location preferences.

Education requirements.

Resume content.

Required and preferred qualifications.

The score was intended to give users a faster way to decide which jobs deserved their attention.

Instead of reading every listing from the beginning, they could use the score as an initial signal.

At the time, that felt like a major improvement.

Later, I would realize that a score alone was not enough. But building the scoring system forced me to think carefully about how candidates and opportunities were being compared.

That work would eventually become part of Oppli's newer career-intelligence system.

The application problem

The original vision also included helping users apply to jobs.

That introduced a different kind of difficulty.

Job applications are not standardized. Companies use different forms, questions, hiring platforms, and requirements. Even when two employers use the same system, their workflows can look completely different.

What looked simple from the outside was often fragile in practice: incomplete listings, inconsistent forms, and steps that suddenly needed a person's judgment.

The lesson was not that software could replace every step. It was that applying is messy enough that speed alone does not solve the user's real problem.

Learning through implementation

Despite the difficulty, the first version created valuable foundations.

We developed systems for:

Processing resumes.

Organizing user experience and skills.

Finding and storing jobs.

Comparing profiles against opportunities.

Tracking user decisions.

Building personalized onboarding.

Creating resume and cover-letter tools.

Not every feature would survive in its original form.

That did not make the work useless.

A product is not only the final collection of features that reaches the market. It is also the knowledge gained by building the versions that did not.

The early Oppli taught us how fragmented the hiring system is.

More importantly, it began revealing that application speed was only one part of a much larger problem.