Applytide

The tracking is the job

Anyone running a serious job search is operating a pipeline: sourcing, qualification, application, follow-up, interview, decision. It has stages, conversion rates, and a cycle time. It is a process, and people run it in a spreadsheet or in their head.

The friction is not finding jobs. It is the accounting around them — which version of the CV went where, what you said in the cover letter, when you promised to follow up, and which applications are actually still alive. That work is boring, high-frequency, and exactly what software is for.

What I got wrong initially: I assumed the painful step was writing applications. It was not. The painful step was capture — getting a posting out of a browser tab and into a structured record before the tab closed. Everything downstream depends on that one moment being frictionless.

Constraints that actually bound the design

Two real constraints shaped almost every decision. The first was cost: any feature calling a language model has an unbounded bill attached to it, and a personal project cannot absorb that. The second was trust: this system holds a user's CV, their employment history, and a list of every company they are quietly talking to. That is a small dataset with a very high blast radius.

So security and cost control were not features to add later — they were framing constraints. That is why the build contains things a side project usually skips: HttpOnly cookie sessions rather than tokens in localStorage, TOTP two-factor, revocable session tracking, per-endpoint rate limits, and a hard daily spending cap on AI calls enforced in Redis.

Explicitly out of scope: automated applying. I excluded it because mass-applying optimises application volume while making the surrounding search process noisier.

Capture first, because everything hangs off it

Since capture was the load-bearing step, the browser extension was built early rather than as an add-on. Getting a posting into the system in one click is the difference between a tool someone uses and a tool someone means to use.

The rest sequenced along the pipeline itself: capture, then the Kanban stages that model the process, then documents, then the reminder and analytics layers that only become meaningful once there is history to reason about. Analytics last is deliberate — a dashboard over three records is decoration.

The architecture was planned as separate services from the start where the boundaries were genuinely different: HTML email rendering is a Node concern, background scheduling is not an API concern, and the reverse proxy is where rate limiting belongs.

Eight Compose entries, counted by definition

At the audited public commit, Docker Compose contains eight service entries, including development-only MailDev. The runtime topology also includes Nginx, a React SPA, a FastAPI backend, a Node email service, PostgreSQL, Redis and a scheduler process.

The backend is layered rather than flat — 15 include_router registrations at the API boundary, a domain layer holding business logic, 19 SQLAlchemy model class declarations under Alembic migrations, and infrastructure for email, LLM access, security and workers. Those are snapshot counts with recorded definitions, not product outcomes.

The hardest problem was extraction: turning an arbitrary job page into structured fields. The naive answer is to send the page to a model. That answer is wrong for reasons covered in the decision log below.

The second hardest was internationalisation. Full Hebrew support means real RTL — not a mirrored stylesheet, but a layout that is correct in both directions, including inputs, charts, and drag-and-drop. Retrofitting that is expensive, which is why it was designed in rather than bolted on.

Budgets, health checks, and the things you cannot unit-test

Some of this was conventional: Pydantic schemas validating every endpoint boundary, parameterised queries throughout, a health endpoint checking both Postgres and Redis.

The source logs LLM usage per call with token counts and account attribution against a configurable daily budget. That is a spend-bounding mechanism; without operating evidence, it is not a production-reliability claim.

Session management is testable in the same spirit: a user can list their active sessions and revoke them. The question that validates it is not “does the endpoint return 200”, it is “can a user who lost a laptop actually recover”.

What the archive does — and does not — prove

The public Applytide repository is archived. There is no live deployment or external-usage result presented here.

I stopped when continuing would have meant operating infrastructure, funding model usage and maintaining a security surface — a different commitment from proving the product and engineering decisions.

What the source independently demonstrates is an implemented multi-service architecture, session and budget controls, bilingual UI and a documented set of design decisions. It does not by itself prove production security, reliability or adoption.