No open roles.
Here's the work.
Troctor is one person. There is no team to join and nothing to apply for. But the problems are real and a few of them are genuinely unsolved, so they are written out below rather than hidden behind a page that says "check back soon".
Troctor briefs you on the documents you attach to a meeting, answers what you ask during it from that meeting's own material, and cites the line every answer came from. Separately it imports the transcripts you already have, writes them into a folder you choose as plain Markdown, and indexes them on your Mac so one search reads all of them.
Which means the interesting work is not the interface. It is whether the right passage comes back out of a forty page deck in the four seconds somebody has, and what the app does on the questions where it does not. A fluent wrong answer about your own material is worse than no answer, because you repeat it out loud to the person who wrote it.
What follows is a real list. Every item on it has cost days, and several are still open.
Six problems, honestly stated
None of these are hypothetical. They are what the last few months have been.
Retrieval quality, and knowing whether you have it
Chunking is by speaker turn rather than token count, because a transcript already carries structure and a fixed-size window destroys the attribution that makes "what did Priya say about staging" answerable at all. Vector search and keyword search run side by side and get fused with reciprocal rank fusion. Every one of those is a choice, and choices need measurement.
The hard part: the corpora that matter are private, so there is no shared benchmark and no way to publish one. Building an evaluation harness that works on a corpus you are not allowed to see is probably the single most valuable thing anyone could do here.
Whether a confidence floor can be brought back
Retrieval used to be scored before the model was called, and below a hand-picked threshold no model was called at all. That gate was removed in v0.1: set high it made the tool feel useless on questions it should have handled, and on a vault of a few dozen meetings it was effectively always high. What replaced it is a prompt rule and visible citations, which is weaker, and we would rather have the floor back than pretend it was never worth having.
The hard part: the right threshold probably differs per corpus and per question type, and calibrating it without a labelled set of "should have answered" and "should have refused" is an open problem. That is the same problem as the row above, which is why the two are really one job.
A local embedding model that is fast on old hardware
Embeddings run on your machine, on a small open model that downloads once at about 33 MB. On an M-series Mac that is comfortable. On a five-year-old Intel MacBook, indexing a few hundred meetings is a very different afternoon, and those are exactly the machines people still have transcripts sitting on.
The hard part: "use a smaller model" is not obviously the answer, because retrieval quality is the product. Quantisation, batching, threading and the question of what can be deferred to idle time are all still on the table.
Native modules under the Hardened Runtime
better-sqlite3 and sqlite-vec have to be compiled against Electron's ABI, unpacked out of the asar or dlopen fails outright, and the sqlite-vec dylib is refused by the Hardened Runtime unless library validation is explicitly disabled in the entitlements. None of that is intellectually difficult. All of it fails quietly.
The hard part: "works on my Mac" and "works signed, notarised, on a machine that has never seen Xcode" are separate problems, and only one of them has a fast feedback loop.
The sharp edges in sqlite-vec
A vec0 primary key has to be bound as a BigInt. Pass a plain JavaScript number and better-sqlite3 binds it as a REAL, and you get back "Only integers are allows for primary key values", typo included. That is documented nowhere. Chunk budgets have to be measured on the formatted string rather than the raw text, or speaker prefixes silently blow past the target. The bge embedding models want a query prefix and no document prefix, and skipping it degrades retrieval without raising anything.
The hard part: there is a whole category of these and each one is found by losing an evening to it. Anyone who enjoys mapping that territory rather than resenting it would be useful.
Making something you would trust about your own history
Insights, contradictions between meetings, commitments that were made and never followed up, come from SQL and pattern matching and never from a model, because one fabricated "you said two different things" on first run is unrecoverable. Retrieved text is fenced and declared as data rather than instructions, because everything said on a call reaches a prompt eventually. Citations point at a meeting, a date and a timestamp you can open.
The hard part: this is as much a design problem as an engineering one. Trust in a memory tool is built out of how it behaves when it is uncertain, and there is not much prior art to copy.
What would matter
There is no offer to make, so there is no salary or equity to describe, and inventing one now would be a number to walk back later. What is worth saying is what the first person would need to be.
Evidence before taste
Nearly every open question above gets settled by measurement rather than argument. Someone whose instinct is to build the test set first would change how this gets made.
Has shipped a Mac app
Signing, notarisation, entitlements, native modules, the whole quiet list. Not clever work, just work that goes much faster if you have already done it once.
Opinions about being wrong
The most important behaviour in this product is what it does when it does not know. If you have thought about refusal, calibration or whether a citation actually supports the sentence it is attached to, that is the conversation.
Comfortable this early
About twenty people use it. There is no traffic to analyse, no process to follow and no plan that runs past a few months. Some people find that clarifying. Most do not, and that is a reasonable reaction.
What to send, if you want to
No form, no CV, no process, because there is nothing for a process to lead to yet.
The useful email says which of the six problems you would take on and what you would try first. "Your chunking is wrong and here is why" is a better opening than a list of previous employers. So is a pointer to something you built that had to be right rather than just finished.
Speculative approaches are genuinely welcome, including from people who would want to work on this in some shape other than a job. Everything gets read. Anything specific gets a reply, though not always quickly, because there is one person doing the reading.
Things people ask
Are you hiring?
No. Troctor is one person, and the beta is about twenty people. There is no headcount, no budget and no role to apply for. When that changes it will be on this page before it is anywhere else.
Then why does this page exist?
Because people ask, and because the real list of open problems is more useful than a job advert for a job that does not exist. Everything above is being worked on now, which also makes it a fair description of what using the product is like at this stage.
Is it worth writing if there is no role?
It is if you have something specific to say about one of the problems listed. There is one person reading, so replies are not fast, but anything specific gets one.
Do I need to have worked on macOS before?
For the packaging and native module side, yes, or at least you would want to. That work is a long list of things that fail silently, and experience is worth weeks of it. For retrieval and evaluation, macOS is beside the point.
What about the ethics of this product?
Worth asking, and the honest answer got harder recently. Most of Troctor is about transcripts that already exist, where the question is who was entitled to make them. But there is now a live mode that captures a meeting and has it transcribed by a vendor, which puts us in the same territory as the tools we used to say we were not like. It is unproven rather than finished, it is off by default, and the audio goes from the user's Mac to the vendor rather than through us, and none of that answers the question of what somebody owes the other people in the room. The position is on the Responsible Use page and the mechanics are on the security page. If you disagree with where the line is drawn, say so. That is a conversation, not a disqualification.
Tell me which one you'd take on.
A few paragraphs about the problem and how you'd attack it is plenty.