KairosAI

The conventional way to build a form-filling extension is a rule per site: a hand-written map of CSS selectors to fields for each employer's form. That's straightforward, and it's also why most autofill tools support a short list of sites and break constantly. Application forms are built by thousands of companies on dozens of ATS products, every one free to change its markup on any given day, and no small team keeps a selector table current against that.

So the extension carries no selectors. It reads the form as rendered, and the model matches the fields it finds against the structured resume — deciding that this input wants a phone number and that textarea wants the current job description — before injecting values. The consequence is that it generalises: it works on forms nobody wrote a rule for, including forms that didn't exist when it was built. That's also the clearest payoff from Pillar A, since matching a form field to a candidate is only tractable because the resume was turned into structured data at upload.

Each of the three obvious strategies fails alone. Pure keyword matching is brittle and misses every candidate who says "built REST services" where the posting says "API development". Pure embedding similarity captures that equivalence but happily rates a related-but-wrong role highly, because semantic closeness isn't the same as being a fit. An LLM asked to judge every listing is the most accurate and by far the most expensive, and doesn't scale across a full board of postings.

The system runs all three. Keeping keyword matching in the loop is the non-obvious part — it isn't there because it's a good similarity metric, it's there because it models the filter the candidate is actually up against. It's signal about whether the application will survive, not merely whether the candidate is suitable.

The naive design fetches listings when the user asks for recommendations. That makes the user wait on someone else's server, makes the request rate look exactly like the traffic pattern boards watch for, and re-fetches the same postings for every user who searches.

Collection instead runs as scheduled batch jobs writing into a normalised store, with matching done against that store. The user's request touches the database and nothing else, which is why recommendations are fast, and the collection rate is decoupled from how many people happen to be searching.

The project began with data split across Neon and Supabase. Both are PostgreSQL, which is what made the split look harmless — and what made it a genuine drag. Auth and resume file storage already lived in Supabase, so the split meant two connection stories, two sets of credentials, two places to look when something was wrong, and a boundary to reason about every time a query wanted to join across it. For a three-person team on a seven-month timeline that's a tax paid continuously for no benefit.

Neon was dropped and everything moved onto Supabase. The lesson worth recording is that the migration was cheap precisely because it was done early — the same decision deferred until the schema was fully grown would have been a project rather than a change.

Every AI call runs on GPT-4o mini. A larger model would have improved the judgement-heavy calls, particularly match scoring and interview feedback. On a project with no revenue and a seven-month clock, running one cheap model everywhere is what let all three pillars get built and demonstrated rather than two of them being built well. It's the right call for an MVP, and the first thing worth revisiting if the product went further.