← Back to Blogs

Building in PublicDeveloper Story

I Built a Job Matching Tool as a Solo Developer: What I Learned

Author: SWARA Editorial Team Published: Mar 2026 Updated: Apr 2026 Read time: 10 min read

I'm going to be honest about how SWARA started: frustration. I was going through the job search process, and I found myself doing the same tedious thing over and over. Open five job boards. Scroll. Read. Decide. Apply. Repeat. No structure, no feedback, no way to know if I was spending my time on the right things.

I'm a developer. When I keep doing something manually that feels like it should be automatable, it bothers me. So I started building.

This is the honest story of what that process looked like - the decisions that worked, the ones that didn't, and what shipping a real product from scratch taught me.

The Original Idea Was Different

The first version of SWARA wasn't a matching tool. It was an auto-application tool. The idea was to automate the entire process - the agent would find jobs, fill out applications, and submit them on your behalf. One credit, one application.

I actually built a working version of this. It used Playwright for browser automation and worked reasonably well on a few job boards that had straightforward HTML forms. The problem was scaling it. Job boards are adversarial environments for bots. LinkedIn detected and blocked automation almost immediately. Workable rendered everything in React components that were difficult to interact with reliably.

I was essentially in an arms race I couldn't win as a solo developer.

So I pivoted. Instead of automating the application, I focused on helping candidates prioritize better opportunities. This was a better problem to solve, and it was a direction that centered users rather than automation tricks.

Stack Decisions and Why

The frontend is Next.js 16 with Clerk for authentication and Supabase as the database. I chose this stack because it's what I knew, it's fast to build with, and Vercel makes deployment trivial.

The agent (the scraping and matching pipeline) is Python running on GitHub Actions. Python is the obvious choice for data processing tasks. A typical scan run takes 2-4 minutes.

The Hardest Part Wasn't the Code

Every developer who has shipped a product from scratch knows this: the technical problems are actually the easy part. They're well-defined. They have solutions. You can Google them, or increasingly, ask an AI. When you're stuck, you make progress.

The hard part was making product decisions with incomplete information. How many job boards should I integrate? What should be free vs. paid? How do I explain product value clearly? When is a feature good enough to ship?

A few things that helped:

What I'd Do Differently

I started with Workable as my first job board integration, then LinkedIn. Both were mistakes - Workable uses complex React components, LinkedIn has aggressive bot detection. I should have started with the boards that had clean, accessible APIs or plain HTML. Arbeitnow has a free JSON API that made integration trivial. Starting there would have saved me weeks.

I'd also have thought harder about the shared cache architecture from day one, rather than arriving at it after building a per-user scraping approach first. The performance difference is enormous and the architecture is simpler once you're thinking in terms of shared infrastructure.

What This Project Taught Me About Job Searching

Building this product gave me an unusual perspective on job searching. I spent months studying what makes candidates strong fits for specific roles and where people lose momentum in the process.

The clearest insight: most candidates have better fits available than they realize. When you approach job searching as keyword search - "software engineer remote" - you get a list sorted by recency. When you approach it as profile-first matching, you get a list sorted by fit. Those are very different lists, and the second one is usually full of opportunities the first one buried on page 17.

The second insight: your skill set is more valuable than you think in the right context. A candidate who looks mediocre against a generalist role might be an excellent fit for a specialized one. The job of a good matching system is to surface those specialized fits.

If you're in a job search right now, SWARA is free to try. You'll get a ranked list of your best matches in under four minutes. It won't solve everything, but it'll tell you where to focus.


SWARA Editorial Team writes practical, experience-based job search guides for developers.