The next chapter in building an open-source, AI-assisted international job-search platform.
This is the second article in the JobSearch series. In
[Part 1], I introduced the problem, the product direction, and the first foundations of the platform. This chapter is about what happened next: turning those foundations into a usable search journey and making local AI a first-class option.
Repository: github.com/subraatakumar/job-search
Imagine opening a job-search application after a long day.
You have a resume in one tab, a spreadsheet in another, saved searches scattered across several job boards, and a growing list of questions:
The first version of JobSearch was mostly about building the room: authentication, profiles, resume extraction, preferences, and a protected dashboard. This next version starts furnishing that room.
The product is becoming a workspace where a candidate can describe what they are looking for, search across public sources, inspect the results, and eventually move from discovery to preparation without losing the thread.
That last part matters. Job searching is not just retrieval. It is a sequence of decisions. The application should help people make better decisions, not make hundreds of noisy applications on their behalf.
The onboarding path now has a clearer shape:
Profile → Job search preferences → AI provider → Search jobs
The user can import a text-based PDF resume, review the extracted information, describe countries and roles of interest, choose an AI provider, and arrive at the dashboard search workspace.
The final step is intentionally a dashboard rather than an unrelated jobs page. It is the place where the user’s profile, preferences, search conversation, filters, and future application workflow can meet.
This is a small product decision with a large effect: the interface should follow the user’s mental model. After configuring the assistant, the next thing a person expects is to use it.
Resumes and job preferences are personal. They contain employment history, skills, locations, contact details, and sometimes sensitive career decisions.
Some users want the quality and convenience of a hosted model. Others want control over where their data goes. Some are experimenting, learning, or working with limited budgets. A single provider assumption would exclude too many of them.
That is why JobSearch uses an OpenAI-compatible provider abstraction. The application can speak the same general API shape while allowing the model to live in different places:
Hosted provider
or
Local Ollama model
or
Another compatible server
↓
JobSearch AI adapter
↓
Search, ranking, and preparation
The provider is explicit and configurable. API keys are stored server-side and encrypted with AES-256-GCM; they are never returned to the browser. Local Ollama users can leave the API key blank.
This is not a claim that local models are always better. They can be slower, require more memory, and vary in quality. The point is choice. Privacy, cost, performance, and model quality are trade-offs that should belong to the user.
Ollama makes it practical to run an AI model on your own machine. After installing it from ollama.com/download, start the service and download a model:
ollama serve
ollama pull llama3.2
ollama list
Then start JobSearch with Docker, open /settings
, and enter:
| Setting | Value |
|---|---|
| Provider | Ollama (local) |
| Model name | llama3.2 |
| API endpoint with Docker | http://host.docker.internal:11434/v1 |
| API endpoint without Docker | http://localhost:11434/v1 |
| API key | Leave blank |
The host.docker.internal
detail is important. When the web application runs inside Docker, localhost
means the container, not the host computer where Ollama is running. The host gateway lets the container reach the local Ollama service.
After saving the provider, JobSearch takes the user to the dashboard search workspace. The model is now available for the parts of the workflow that need AI assistance.
The current search direction combines several responsibilities:
That pipeline is deliberately server-side. The browser should be the place where users ask questions and review results, not the place where secrets, source orchestration, or provider credentials are exposed.
The search interface also shows progress while discovery, source checking, verification, and ranking happen. This is more honest than displaying a spinner and pretending that every result has the same level of confidence.
Open-source AI projects often focus on what the model can generate. JobSearch also needs to be clear about what it will not do.
The project is designed around public job information and user control. It does not collect passwords or cookies for gated platforms. It does not aim to bypass CAPTCHAs. It does not silently auto-apply to jobs. It should not fabricate qualifications, sponsorship evidence, or application claims.
The intended workflow is:
Find an opportunity
↓
Understand the evidence and fit
↓
Improve the application with assistance
↓
Review everything yourself
↓
Choose whether to apply
That human review step is not a temporary limitation. It is part of the product philosophy.
The repository currently includes:
This is still an early MVP. Some visible features are foundations rather than finished products. Search history, saved-job persistence, richer matching, and application preparation are active areas for improvement.
The next chapters will move from “find jobs” toward “understand and act.” The roadmap includes:
The order may change. Real user feedback should influence it.
JobSearch is intentionally open source because the job-search experience is different across countries, professions, industries, and career stages. One person may need sponsorship evidence. Another may need accessibility improvements. Someone else may know the best public career sources for a region that the project has not considered yet.
You do not need to arrive with a large pull request. Contributions can be:
Please start with the repository’s CONTRIBUTING.md, and open an issue for a substantial feature so the design can be discussed before implementation. Feature suggestions are especially welcome when they describe the user problem, not only the proposed button or endpoint.
The first article introduced the idea. This chapter gave the idea a local brain and a clearer destination: a search workspace that respects the person using it.
The next update will focus on making results more trustworthy and useful—better source handling, stronger matching explanations, and the first steps toward turning a job listing into a tailored preparation plan.
If you are searching internationally, building developer tools, interested in local AI, or simply curious about open-source product development, follow along. Try the project, tell me where the experience breaks, suggest what should be built next, and help shape the tool before the roadmap is set in stone.
The best version of JobSearch will not come from one person guessing what everyone needs. It will come from people bringing their own job-search stories to the project.
JobSearch is released under the MIT License. Please review the project’s security guidance before reporting sensitive issues or contributing integrations that handle personal data.