Skip to main content
The CRM is the half of the product that outlives one job hunt. Applications close; what you learned about a company and who you know there does not.

​
Companies

A company record holds name, website and notes, four lists of tags — industry, size, location and a free tags — plus, whenever you open one, every application you have there and every contact who works there. Industry, size and location were single text boxes until they were tags. One company is plausibly both fintech and infrastructure, and hiring in two cities; a typo in a text box was a value of its own forever, where a tag is a row you rename once. Each of the four lists replaces only itself, so setting an industry never clears where the company is. You rarely create one on purpose. Applications create their company automatically, and capture_job_posting fills in the website too when the posting names it. create_company is for the other case: somewhere you are researching before there is an application. Names are unique per person, so creating one that already exists is an error rather than a silent merge.

​
The website field earns its keep

website is the company’s own domain — stripe.com, not a Greenhouse, Lever or Ashby link, which is the job board rather than the employer. Nothing depends on it except one thing, and that one thing is why an assistant is told to set it whenever it learns it: it is what puts the company’s logo on your pipeline. A board with logos reads at a glance; a board without them is a wall of text.
Logos are fetched by each person’s browser from twenty-icons.com, which means that service can see which companies are in a pipeline. An admin can turn the whole thing off instance-wide — everyone gets initials on a coloured tile instead, and nothing is stored or deleted either way. See configuration.

​
Research notes

The notes field is where the useful part accumulates. What is worth recording is whatever you will want the night before an interview:
  • What the company actually does, and how it makes money
  • The interview loop, if you know it
  • Who you know there
  • Why you do or do not want this — the honest version
update_company replaces the notes field rather than appending to it. Call get_company first, combine what is there with what is new, and write the whole thing back. Losing research by writing over it is the worst outcome available in this part of the product, which is why the research_company workflow spells the read-first step out.

​
The same employer, twice

An application creates its company automatically and a capture creates another, so “Stripe”, “Stripe, Inc.” and “stripe” end up as three rows each holding a slice of the pipeline. merge_companies folds one into another: applications and contacts move, blank fields on the survivor are filled from the duplicate, the duplicate’s notes are appended under a line saying where they came from, and the duplicate row is deleted.
Merging is irreversible and nothing records afterwards which applications came from which side. Call preview_company_merge first — it returns exactly what would move without writing anything — and let the person confirm. keep_id is the company whose name survives; merge_id is deleted.
Nothing is de-duplicated by a merge. Two identical role titles on the survivor is the correct result: the alternative is guessing which of two records to destroy. In the app the company page has a Merge button, and it pre-selects the other company when the two names reduce to the same key. Deleting a company no longer refuses while applications point at it, and no longer needs to: it and every application still pointing at it go into the archive together, and come back together. The people stay — somebody is a founder at one company and an advisor at another — and simply lose that one link.

​
Filters and sorting

The Filter button opens on the dimensions — Industry, Size, Location, Tags, Gaps — and you step into one to pick from its values, rather than scrolling one list of everything. Typing searches across all of them at once and says which dimension each match came from. Sorting is the column headings, or a Sort control beside the filter that lists every key including the ones whose column is hidden on a narrow screen. Dragging the divider between two headings sets their widths, which are saved to your profile rather than the URL, so the list looks the same on every device.

​
Filters

list_companies takes a search across name, website, notes and every tag name, four tag cuts — industryIds, sizeIds, locationIds and the kind-agnostic tagIds — a missing list for the gaps worth fixing in one sitting, a sort, and a filter: Every row also carries lastAppliedAt and openApplications, so “who have I applied to, and what is still live” is one call.

​
Contacts

Recruiters, hiring managers, referrals, the friend who works there. A contact holds name, title, email, phone, relationship, notes, tags, the companies they represent, optionally the application they belong to, and every way you can reach them. tags files a person the way industry files a company — “referral”, “warm intro”, “ex-colleague” — and comes out of the same catalogue everyone else’s labels do. It replaces the whole set, and list_contacts takes tagIds to cut to a label as well as finding one through search.

​
Everywhere they represent

companies is a list, because people are not one employer each: a founder who advises two of your targets is three links, and an ex-colleague who moves keeps the old company as history. Pass names and any that do not exist yet are created; pass companyIds when you already have them.
companies replaces the whole set, like every other array in the API. To add one, read the current list with get_contact, append, and write it all back. An empty list detaches them from every company.
applicationId is still one thread at a time: pass an id to attach, an empty string to detach. Removing someone from an application never deletes the person.

​
Where to find them

linkedin is the one everybody has, and the wrong assumption for everybody else — the founder who only answers on X, the designer whose portfolio is the point. So a contact carries linkedin, twitter, instagram, github and website as named fields, plus otherLinks for the tail that has no end: Bluesky, Mastodon, a Substack.
otherLinks is a list and replaces what is there, like every other array in the API. Read the current one with get_contact before writing it back.
The fields take a URL or a bare handle — @bywilliaml under twitter becomes https://x.com/bywilliaml. The column is twitter and the label in the app is X: renaming a column to follow a rebrand is a migration that buys nothing.

​
People have timelines too

log_activity takes either an applicationId or a contactId, never both. With a contact id it becomes that person’s history: their page shows it and their “last touched” date moves. So when you mention talking to someone — a coffee, a call, a reply — that is where it gets remembered, and “when did I last talk to them?” is answered from get_contact.

​
Pings

nextFollowUpAt on a contact is where “ping Sarah in two weeks” actually lives. Due pings surface in list_follow_ups alongside due applications, on the front page, and in the bell in the top bar. The ping-due filter on list_contacts is the same question asked directly. In the app it is scheduled from Today rather than from the person’s own page: a date box halfway down a record you opened to read is not where anyone plans a week. Two other filters: with-application and no-company — no-company means nowhere on file, not “no main employer”. companyId matches anyone linked to that company, whichever of their hats it is.

​
In the app

CRM splits into Companies and Contacts, each a filterable list, and both are named in the sidebar so neither needs finding. A company page holds its details, its research notes, everyone who represents it, and its roles as job listings — each one a click from the posting it came from. Industry, size, location and its own tags are pickers there: tick to attach, type to create, recolour from the swatch row, delete outright. A contact page holds their details, their tags, their links and their timeline. Wherever a company is named it is drawn as a chip carrying its own favicon, and clicking it opens that company. Under a contact’s name those chips are the control: each one has an × that unlinks it, and the button beside them adds another or creates a company that is not on file yet. There is no company text field, because typing into one renamed the company for everyone else attached to it and could only ever hold one. The contacts list shows the first company someone represents and a count of the rest, and each person’s tags beside their title. Every link a contact has carries its platform’s own mark, read off the URL rather than the field it is filed in — so a YouTube channel in the website slot still shows as YouTube. Contacts attach to applications straight from the CRM rather than being retyped.

​
The two workflows that live here

research_company

Gathers what is already on file, says what is missing, then writes it back combined — without flattening the notes that were already there.

prep_for_interview

Pulls the posting, the whole timeline, the company research, the people you are meeting and your own evidence into one prep sheet.
Both are in every client as ordinary tools as well as prompts — see the workflows.