Why I Started Building Oppli
Looking for a job is one of the strangest systems we have collectively accepted.
You find a position. You read a description filled with broad requirements. You edit your resume, answer the same questions again, submit everything, and wait.
Most of the time, nothing happens.
There is no explanation. No useful feedback. No indication of whether you were close, completely unqualified, filtered out by software, or simply one person among hundreds of applicants.
Then you repeat the process.
That frustration is why I started building Oppli.
The original idea
The first version of Oppli began with a straightforward question:
What if applying for jobs felt simpler, faster, and less exhausting?
The original concept was a mobile-first job-search application where users could discover opportunities, understand how well they matched, and move through jobs without dealing with dozens of tabs and repetitive forms.
Instead of treating the job search like a spreadsheet, Oppli would make it feel guided and manageable.
Users would create a profile, upload their resume, add their experience and preferences, and receive jobs that appeared relevant to them. They could quickly review opportunities, save the ones that looked promising, and move forward without rebuilding their entire application every time.
At the center of the early product was a matching system designed to compare a candidate's background with a job's requirements.
The goal was not simply to show more jobs.
The goal was to show better ones.
Why the job search feels broken
Most job platforms are optimized around listings.
They collect jobs, organize jobs, recommend jobs, and encourage people to submit more applications. But they rarely help users understand what is actually happening.
A person can apply to fifty positions and still not know:
The system measures activity, but it does not create clarity.
That distinction would become much more important later.
At the beginning, however, the mission was focused on reducing friction. I wanted to make job searching feel less repetitive and less discouraging.
Building more than a prototype
Oppli was never intended to be a simple interface placed on top of an AI model.
Even the original version required several connected systems:
Every feature depended on another feature.
A match score could not work without reliable resume data. Job recommendations could not work without understanding preferences. Helping someone move from an interesting role to a ready application meant dealing with messy, inconsistent hiring workflows.
The deeper I went, the clearer it became that building a job-search product was not only a design challenge.
It was an infrastructure challenge.
What I wanted Oppli to represent
From the beginning, I wanted Oppli to feel supportive rather than transactional.
The product should not treat someone as a collection of keywords. It should not pressure users to apply to everything. It should not make the experience feel like another corporate form.
It should help people move forward with more confidence.
The first version of that mission was about speed and simplicity.
Make applications easier. Reduce repetitive work. Surface better opportunities. Help users maintain momentum.
That was the starting point.
It would take more building, more failures, and more uncomfortable questions before I understood that the largest problem was not how slowly people applied.
The largest problem was that most people had no clear way to understand where they stood.
That realization would eventually change Oppli completely.