Jarvis

About

Jarvis is a desktop app that sits above every project I run rather than inside any one of them. It briefs the day, gives me one project’s status and what is next, and dispatches work that comes back as a branch to review. It has exactly one user.

Why I built this

Running several products alone, the expensive part stopped being the building. It became the switching: remembering where each project stood, which ticket was next, what was half-finished, and what a decision three weeks ago had committed me to.

Every project already had a backlog and a repo. What was missing was something that knew about all of them at once and could start work without me first reconstructing context. So the goal was never a chatbot. It was a way to go from “what should I do today” to a reviewable branch without the tab-switching in between.

The constraint that shaped it

One rule drove most of the design: it must never become load-bearing.

Every project stays fully drivable by hand. Nothing about Jarvis lives inside the product repos: no SDK, no config, no dependency. It only points at a project. Removing it changes nothing in the code. If a feature would make a project require Jarvis to build or ship, it is out of scope.

The second rule: nothing publishes, merges, spends or posts on its own. Work returns as a branch, an adversarial review runs against the diff, and a person approves. Convenience, never autonomy.

What it does

• A morning brief across every project, pulling from live tickets and the day’s calendar
• Per-project status and what is genuinely next
• Dispatches a scoped piece of work and hands back a branch, never a merge
• An adversarial review pass over the resulting diff before it reaches me
• A review inbox for finished runs, with a send-back loop for corrections
• Usage and cost gauges, with per-day ceilings
• Push-to-talk, because the fastest way to start work is often to say it

What I actually learned

Most of the interesting problems were not AI problems. They were the ordinary ones that show up whenever software is allowed to act: how work is scoped so the result is reviewable, what happens when a run fails halfway, how state is reconciled after a crash, and how you make a safety promise structural rather than a line in a prompt.

The design work was mostly deciding what the system is not allowed to do, and making those limits real in code rather than convention. That turns out to be the same job as designing any platform where people can cause damage, just with a smaller and more forgiving audience.

Where it stands

Running daily. Deliberately not a product: it is shaped around one person’s workflow, and generalising it would mean giving up most of the constraints that make it safe to use.