Build your own JARVIS

01 · Why they die

Almost every second brain dies the same three ways

Capture friction. No return path. Tool-first thinking. That is the whole list, and most people manage at least two.

Capture friction kills it in week two. If getting a thought into the system takes more than about five seconds, your brain quietly stops offering thoughts. It does not announce this. You just notice, a month later, that you have not added anything since the Tuesday you set it all up.

No return path kills it in month three. Everything goes in and nothing ever comes back out. You have built a landfill with excellent search. Search only helps when you already know what you are looking for, and the whole promise of a second brain is remembering the things you forgot you knew.

Tool-first thinking kills it before it starts. Someone reads about a vector database, wires up an agent, connects six services, and ends up with a genuinely impressive assistant that has nothing to be smart about. The AI layer is the last thing you build, not the first. It is a lens; you need something to point it at.

Design against those three and the rest is plumbing. Pleasant plumbing, mostly. The kind you can do on a Saturday with coffee and a text editor.

02 · The model

Three layers, not fifteen tools

Every product in this space wants to be your whole system. None of them are. Sort them into three layers instead, and the tool choices stop mattering nearly as much as people argue they do.

The whole architecture. Four doors into one inbox, two stores that each do what they are good at, and a surfacing layer whose only job is to put things back in front of you. The dashed return path is the part people skip, and it is the part that decides whether any of this survives.

Capture

One inbox. Not four. The single most important design decision in the whole system is that there is exactly one place a thought can go, and getting it there takes one gesture.

Several doors can open onto that one inbox. A messaging bot for your own thoughts, an email address for what other people send you, a voice note for the car, a bookmarklet for links. The next section wires each of them up.

What does not work is a system where you have to decide, at capture time, what kind of thing you are capturing. Sorting is a job for later, done by a machine.

Store

Two databases, on purpose. This is the part people fight, and they are wrong to.

Structured things go in rows: people, companies, tasks, interactions, receipts, anything you will want to count, sort, or filter. Prose goes in files: meeting notes, transcripts, journal entries, half-formed ideas, anything you will want to read. Postgres for the first, Markdown for the second. Or a spreadsheet and a folder of text files if you want to start today.

You almost certainly own both halves already. A spreadsheet you keep for something, a folder of notes, an Apple Notes export, a Drive full of documents. That is a working store. Point the system at what you have instead of designing a schema on a Saturday; the schema you would design today is the wrong one anyway, because you have not yet watched what actually accumulates.

The reason a person is a row and not a paragraph. Once contacts are structured, questions like who have I not seen on this side of town in six months become a query rather than an afternoon. Synthetic data, drawn to illustrate the shape.

The trap is trying to make one tool do both. Note databases full of long-form prose get slow and unqueryable. A Postgres table with a giant notes text column is a filing cabinet pretending to be a database. Let each format be what it is, and let them point at each other by name.

Surface

The layer everyone skips, and the only one that decides whether the system survives.

Surfacing is anything that puts information back in front of you without you asking. A morning digest email. A spaced-repetition queue that shows you a note you wrote eight months ago. A visual map that makes an orphaned cluster of ideas obvious at a glance. A nudge that says you have not spoken to someone in five months.

Build one surfacing mechanism before you build any AI. If nothing in your system reaches out and taps you on the shoulder, it is storage. Storage is not a brain.

03 · Channels

Wiring the inbox you will actually use

One inbox, several doors into it. Each door costs about an hour to build, and you do not need all of them. Build the first one, live with it, and add the next only when you catch yourself wishing it existed.

Telegram, for your own thoughts

Message @BotFather, type /newbot, answer two questions, copy the token. That is the whole setup and it genuinely takes four minutes. Every automation tool has a Telegram trigger built in, so the token is the last piece of configuration you will do.

What makes it the right first channel: it is already on your phone and your desktop, it takes text and voice and photos and links without asking which is which, and messaging yourself feels like nothing at all. Frictionless capture is the whole game, and this is the least friction I have found.

Email, for everything other people send you

This is the channel worth building second, and the one most guides skip. Telegram catches your own thoughts. Email catches the world; a contract someone sent, an introduction, a receipt, a thread you want the system to remember. BCC an address and the thing files itself.

Three routes, in ascending order of setup pain. Start at the top. Climb only when the row below the one you are on describes a problem you actually have.

Mailgun's free tier covers personal volume comfortably, and Postmark's inbound parsing works the same way if you prefer it. The payload arrives as JSON with sender, subject, body text, and attachments already separated, which saves you writing a MIME parser. Nobody should write a MIME parser.

Voice, for the car

Send a voice message to the same Telegram bot and transcribe it on arrival. Transcription runs a fraction of a cent per minute either way, so pick on two things other than price: length and proper nouns.

Length is the one that bites first. Some hosted transcription endpoints cap the upload at 25 MB, which sounds generous until a one-hour meeting hits it and the job hangs rather than failing cleanly. I moved to Deepgram’s nova-3, which takes the audio as a raw binary body with no size ceiling, and an eighty-minute recording stopped being a special case.

Proper nouns are the one that matters longer. Every model mangles names, and in a system whose whole job is matching names, a mangled one is a note that attaches to nobody. Whatever engine you pick, find its keyword-boosting parameter and feed it the words you say constantly: your own surname, your company, the five people you talk about most. Mine spelled my last name as a different word entirely until I did this. Budget for correcting the rest.

Diarization is worth the flag if your recordings have more than one person in them. It separates speakers, not identities; you get Speaker 0 and Speaker 1, and the model you summarize with can usually work out who is who from context.

Skip this one until the other two are habit. It is the channel people build first because it is the most fun, and use least because talking to your phone in public feels ridiculous.

The browser, for links

A bookmarklet or a small extension that posts the current URL and whatever you have selected to the same endpoint. Ten lines of JavaScript. The reason to build it is not saving links, because browsers already do that. It is that a link captured together with the sentence that made you care about it is worth about ten times a bare bookmark.

04 · Wiring

The automation layer, demystified

Strip away the marketing and all of these tools are the same program: wake up when something happens, run a few steps in order, call some APIs, stop. Once you see that, picking one gets a lot less fraught.

Zapier is the easiest to start with and the first to get expensive, because it bills per task and a task is any step. A capture flow that classifies and then files might burn three tasks per message, so a few hundred messages a month turns into a real bill.

Make costs meaningfully less per operation and asks more of you up front. The visual editor is powerful and genuinely confusing for about a week.

n8n is where I ended up. Self-hosted it costs whatever your server costs, runs unlimited executions, and lets you drop into real JavaScript when the visual steps run out of road. Telegram, Gmail, and generic HTTP are all built in, so every channel above is covered without hunting for plugins.

Three ways to pay for it

Whichever tool you land on, the pricing question has the same three answers, and most people never need to leave the first one.

You do not have to learn the tool

This is the part that would have saved me the most time, and it did not exist when I started.

These tools all store a workflow as JSON, and they all import it. So you do not have to learn the node types, the expression syntax, or where the setting you need is buried. Describe what you want to Claude in plain language, ask for the workflow JSON, and paste it in. A Telegram message arrives, classify it, write a row, reply with a confirmation. That is a sentence, and a sentence is enough.

It will not be perfect the first time. It will occasionally invent a parameter that does not exist, or wire two nodes in a way the current version stopped supporting. Run it, copy the error, paste the error back. Two rounds usually gets you a working flow, and that is still a fraction of the afternoon you would have spent in the documentation.

Read the JSON it hands you before you import it. Not to check the work; to learn the shape. After three or four of these you will know the tool well enough to fix things yourself, which is a much better way to learn it than starting at page one.

Whatever you pick, export your workflows to a file and put them in version control. These tools store your logic in a database whose shape you do not own, and a workflow you cannot diff is a workflow you will be afraid to change. Mine sit as JSON next to the rest of the project, and being able to see exactly what changed has saved me more times than any feature in any of these products.

05 · Decisions

Four decisions, and everything else is preference

1. Where does the line between rows and prose fall?

My rule: if I would ever want to answer how many or which ones, it is a row. If I would want to answer what did they say, it is a file. A person is a row. The conversation with that person is a file. The file mentions the person by name, and something in the middle resolves the two.

2. One inbox or many?

One. I know it feels lossy. It is not, because the automation layer can read a message and decide what it is far more reliably than you can decide at 11pm on your phone. Every extra capture destination is a decision, and decisions are the friction that kills capture.

3. Where does the AI actually sit?

Three plausible places, and the ordering matters more than the model you pick.

• At capture, classifying and routing what comes in. Start here. It is the highest return per line of code, and a mistake costs you a mis-filed note, not a wrong answer.
• At surface, summarizing and prioritizing what goes out. Build this second. A daily digest that says what actually matters is worth more than a chatbot.
• On demand, answering questions across the whole store. Build this last. It is the demo everyone wants and the least useful of the three, because you already know the questions you ask most often, and those should be buttons.

4. What forces you to look at it?

Answer this before you write a line of code. Mine is a 7am email; it is a habit I already had, so the system attached itself to an existing behavior instead of asking me to build a new one. Yours might be a browser new-tab page, a phone widget, a Sunday review. It has to be something you would encounter anyway.

06 · Rungs

Pick your rung. Same model, different cost.

The three-layer model does not care how you build it. Start on the low rung; it does about 80% of the job and you will learn what you actually want. Climb when a specific limit hurts, not before.

Sheets is not a joke. It holds tens of thousands of rows, every automation tool speaks it natively, and you can look at your data without writing a query. The reason to leave is relational depth: the moment you want every conversation with every person at this company, sorted by recency, you want Postgres and you will know it.

The one thing I would put on the higher rung from day one is where your prose lives. Plain Markdown files in a folder you own. Not a proprietary format, not a hosted-only product. Notes outlive tools by a decade or more, and the migration you do not have to do is worth more than any feature.

07 · Order

Build order matters more than tool choice

This is a real sequence, not a checklist. Each step is only useful once the one before it works, and skipping ahead is exactly how the tool-first failure happens.

1. Capture, and nothing else

   A bot that receives a message and appends it to one file or one row. No parsing, no tagging, no AI. Then use it for a week and do not build anything. You are testing whether you actually reach for it, and you will learn more in that week than in a month of planning.

   Ship in an hour

2. Classify on the way in

   Now add one AI step: read the incoming message, decide if it is a task, a note, a person, or a link, and route it accordingly. Keep the prompt short and the categories few. Four is plenty. This is where a language model earns its cost, because the alternative is you making that decision by hand every time.

   One prompt, four outputs

3. Build the return path

   A scheduled job that emails you a digest every morning: what came in, what is due, one thing you wrote a while ago and forgot. Ugly plain text is fine. This is the step that converts storage into a brain, and it is the one most people never build.

   The survival step

4. Connect the two stores

   Make people in your database resolvable from your notes. A name in a transcript should be able to find the row, and the row should be able to list every file that mentions it. Full names only; first names will match catastrophically and you will spend an afternoon finding out why every note mentions your brother.

   Where it starts feeling smart

5. Add spaced repetition

   Every note gets a review box and a due date. Keeping a note pushes it further out; archiving retires it. Now old material comes back on a schedule instead of dying in a folder. Faces work the same way, and if you are trying to learn a lot of names, this is the single highest-return thing in the whole system.

   Compounds slowly, then all at once

6. Then, and only then, ask it questions

   A chat endpoint with access to both stores. By now you have real data, real structure, and a clear sense of which questions you ask often. Half of them turn out not to need a model at all; what has gone stale and what is disconnected are database queries, and a query beats a model call on speed, cost, and honesty every time.

   Last, not first

08 · Scars

The failures that do not announce themselves

Loud failures are easy; something throws an error and you fix it. These are the other kind. Every one of them cost me real time, and every one returned a green checkmark while doing it.

09 · The loop

The surfacing loop is the whole product

Capture and store are solved problems with a dozen good tools each. Surfacing is where you are on your own, and it is where the value is.

Three mechanisms, in the order I would build them.

The digest

One email, one time a day, at an hour you are already reading email. Mine covers what came in yesterday, what is due, who I have not spoken to in a while, and one older note pulled from the review queue. Keep it short enough to read standing up. A digest you skim is worth ten dashboards you do not open.

Spaced repetition, applied to notes

Flashcard scheduling works on anything, not just vocabulary. Give each note a box number and a due date; when it resurfaces, you either keep it (push it further out), archive it, or delete it. Two things happen. Old ideas come back at the moment you have almost forgotten them, which is exactly when they are most useful. And your store gets pruned by use instead of by a cleanup you will never schedule.

The same machinery works on faces. If you need to learn a lot of names quickly, a photo plus a one-line mnemonic on a review schedule will do more in three weeks than a year of trying harder.

A visual map

The one that looks like a toy and is not. Draw every note as a point, group by folder, size by connections, color by age. Suddenly you can see the cluster you have abandoned, the note nothing links to, the region that has grown three times faster than the rest.

Every note as a point, every folder as an arm, brightness by how recently it was touched. The thin tail on an arm is a folder that has stopped growing; a point with no line running to it is an orphan. Synthetic data, but the shape is the real output of a few thousand notes.

That is information a list cannot give you. Human eyes find spatial patterns instantly and textual patterns slowly, and a thousand rows in a table is a wall while a thousand dots on a canvas is a picture. It is also, honestly, the thing that makes you want to open the system, and wanting to open it is the whole ballgame.

The same trick works on people rather than notes. Draw everyone you know as a node and every shared conversation as an edge, and the structure of your working life shows up whether you wanted to see it or not.

Clusters form on their own; you never label them. The interesting nodes are not the big ones, they are the bridges, the handful of people who are the only link between two groups. Lose one and two parts of your world stop talking. Synthetic data.

Building this yourself is less work than it looks. The figure above is about sixty lines of plain canvas with no library at all, and for a few hundred people that is genuinely enough. When you want dragging, zooming and real physics, vis-network is what I use; it is dual-licensed Apache 2.0 or MIT, runs entirely in the browser with no server to stand up, and asks only for a list of nodes and a list of edges. The layout and the clustering it works out on its own.

10 · Boundaries

Decide what leaves the machine, once, on purpose

This system will end up holding the most sensitive text you own. Not because you planned it that way, but because you built a frictionless inbox and then used it.

Two rules have held up for me.

Separate structure from content at every boundary. Labels, counts, dates, and connection graphs are safe to send almost anywhere; a public endpoint can happily answer how many notes mention this project. The text of those notes is a different category and needs a different door. Draw that line in code, not in your head, and put it at the point where data leaves your machine.

Anything reachable from the internet is reachable by everyone. An unguessable URL is not authentication; it is a password you have written on the outside of the envelope. If an endpoint can read your notes, put a shared secret on it. It takes ten minutes and it is the difference between a private tool and a public one you have not noticed yet.

11 · Start

The first ninety minutes

Do not read more. Build the smallest version that works and let it tell you what it needs.

• Minutes 0–15. Create a Telegram bot. Message @BotFather, pick a name, copy the token. This part is genuinely four minutes and it is the most satisfying four minutes of the project.
• Minutes 15–45. Wire the bot to a Google Sheet through Zapier, Make, or n8n. Every message becomes a row: timestamp, text, nothing else. Use a sheet you already have if you have one. Send it three things from your phone and watch them land.
• Minutes 45–70. Add one AI step between the two. Classify this message as task, note, person, or link. Return only the word. Write the answer into a second column.
• Minutes 70–90. Add a scheduled email that sends you yesterday's rows at 7am. Plain text. No formatting. This is your return path, and the system is now technically complete.

Use that for two weeks before you build anything else. You will find out which of the four categories you actually use, whether you reach for it when your hands are full, and what you keep wishing it would tell you. That list is your roadmap, and it will be better than any roadmap you could write today.

Everything after that is the same three layers, just deeper. Postgres instead of Sheets. A vault instead of a column. An email address and a bookmarklet alongside the bot. Spaced repetition instead of a list. A map instead of an email. The model never changes; you just keep filling it in.