I Built ArtemisFlow: A Local-First Job Tracker for Tech Candidates

Modern hiring processes often involve multiple companies, stages, and timelines happening in parallel. At some point, keeping track of everything becomes harder than it should be.

Like many developers, I initially used spreadsheets. They worked well enough in the beginning.

But over time, they became harder to maintain. I kept adding columns, moving things around, and writing notes in places that didn’t really belong anywhere.

Some companies replied after weeks. Others never replied at all. And sometimes, I had to stop and think just to remember where a specific process stood.

The tool itself wasn’t the problem. The model was.

I didn’t need something more complex. I needed something that reflected how hiring pipelines actually work.

So, I built ArtemisFlow.

ArtemisFlow is a local-first job tracker designed specifically for tech candidates. There is no login, no external database, and no onboarding process. You open the app, add an opportunity, and it becomes part of your pipeline immediately. Everything is stored directly in your browser.

The goal wasn’t to build something feature-heavy. It was to build something that stays out of the way.

Why Local-First

One thing that always bothered me about most tools is how quickly they ask for your data. Before you even know if the tool is useful, you're already creating an account, confirming your email, and trusting another service with information that is, in many ways, personal.

A job search reflects your direction, your priorities, and sometimes uncertainty.

ArtemisFlow keeps everything local by default. No accounts, no servers, no background synchronization. Just your data, stored where it belongs.

This also makes the experience instant. There’s no loading, no waiting, and no dependency on external systems.

Modeling the Real Hiring Flow

Hiring pipelines are not static. Each stage carries a different meaning and a different context.

An application is different from an interview. An offer is different from a rejection. And sometimes, there is no response at all.

ArtemisFlow models this explicitly:

This structure mirrors reality more closely than a generic list or spreadsheet.

Technical Decisions

ArtemisFlow was built using Next.js 14, React 18, TypeScript, and Tailwind CSS.

Even though Next.js supports full backend integration, I intentionally kept the application client-side and local-first.

Persistence uses localStorage. It’s simple, reliable, and removes the need for infrastructure or accounts.

There are clear tradeoffs. If browser data is cleared, records are lost. I chose to accept this in exchange for speed, simplicity, and privacy, and made that behavior explicit inside the application.

The architecture itself is intentionally straightforward. One focused codebase, easy to reason about and evolve over time.

In many cases, simple systems are easier to maintain and improve.

Small UX Decisions That Made a Difference

Some of the most meaningful improvements came from small decisions.

Keeping cards compact made it easier to scan multiple opportunities quickly.

Distinct phases made progression easier to understand at a glance.

Inline editing reduced unnecessary navigation and context switching.

None of these changes were complex. But together, they made the experience feel smoother and more natural.

Why This Project Matters to Me

ArtemisFlow reflects how I think about software.

I’m interested in building tools that are fast, simple, and respectful of the user. Tools that don’t require unnecessary infrastructure or complexity to be useful.

Not every problem needs a backend. Not every tool needs an account.

Sometimes, the best software is the one that does its job quietly and stays out of the way.

ArtemisFlow started as a practical solution to a real problem. It also became an opportunity to explore local-first architecture and more deliberate product design.