Time MachineBlog5 min read
Building Time Machine in the open: the plan, and why we will raise
Where Time Machine is today, what comes next, and what money would change. No amounts and no names. Just the plan.
The Time Machine team
Time Machine is early. This post is a plain account of where it stands on 15 October 2026, how we decide what to build next, and why we plan to raise money. There are no amounts and no investor names in it, because neither is the point. The plan is.
Where we are
The engine and the tm command line tool are built and tested. Today you can:
- save your project as a save point, with
tm checkpoint, including uncommitted changes and files not in Git yet - check any save point in a separate Git worktree with
tm verify, with the network off when a sandbox can enforce it, and BLOCKED when it cannot - find the newest save point that works with
tm find-good - bring it back on a new branch with
tm recover, without touching your folder, and without pushing, merging or deploying - install Claude Code hooks that save before each prompt and before risky shell commands, and check at the end of each turn
- connect any agent that speaks MCP to seven tools on the same engine
There are 54 engine and CLI tests. They pass on macOS and Linux in CI. Save points live in ~/.timemachine with a Git bundle. Secret values from config files like .env are never stored, only key names and a fingerprint.
We also ran it on a real open source project, sindresorhus/slugify. That found something the synthetic tests did not: behind a network proxy, npm install failed inside the safe copy, because the clean environment dropped the proxy settings. The fix started with a failing test, like every fix here. Proxy, certificate and package manager settings now pass through.
Two independent reviews of the engine found 17 bugs in total. All 17 were fixed the same way: a test that shows the bug first, then the fix.
What is not done: the npm package timetm is not published yet, so you build from source. The web app, tm ui, runs from that same source install.
Gates, not dates
Dates are easy to promise and easy to miss. A gate is an outcome you can check. Each stage starts when the one before it passes its gate.
Gate 1, engine and CLI. Done when every acceptance test passes on macOS and Linux, the demo runs end to end, and your folder and current branch are byte for byte unchanged after every command. This gate is met. Publishing to npm is the last step.
Gate 2, the web app. Most people who build with agents do not live in a terminal. The web app puts the same loop behind plain buttons: a history of save points marked Works, Broken or Not checked yet, and one button to go back to the last version that works. It runs on the same engine as the CLI, so the two can never disagree, and it runs on your own computer, in your browser. Done when someone who never opens a terminal can do a verified recovery in the web app.
Gate 3, the action connector. Agents now act outside code. Through connectors in Claude and ChatGPT they can send email, post to Slack and edit documents. We have written a design for a connector that records those actions on one timeline, and reverses only what each app can really reverse. An email could be held and recalled inside a short window, but never "unsent" after delivery. A payment could be refunded, and it would be called a refund. This is Planned. It starts only when the code product is on npm, the design is signed off, and the legal and data questions are settled.
Why build in the open
A safety tool asks for trust. The fastest way to lose it is to claim more than you have built. So every consequential decision is written down as a short record with the choice, the alternatives and the cost. Every page that mentions something unbuilt labels it Planned. And posts like this one say what is done and what is not, on a specific date.
Why we will raise
The CLI works without money. Turning it into a product people can trust with their projects needs four things:
- Full time building. Focused time on the engine and the web app, instead of fitting it around other work.
- Shipping the web app. Publishing to npm, opening checkout, and support and updates for people who pay once.
- An outside security review. A tool that touches your code should be checked by someone other than the person who wrote it. Our security page lists what we know today, but it is our own account.
- Support for design partners. Time and help for the first builders who use Time Machine on real projects and tell us where it breaks.
What we will not do with it
Money changes incentives, so here are the lines we have already drawn. No streaks, countdowns or fake urgency. No alerts unless a real check failed. Restores are never behind a paywall, and the tm command line tool is open source (MIT) and stays that way. The web app is paid for once, $50, with no subscription. Checkout is not open yet, so nothing is for sale today.
How you can help
If you build with coding agents, try the demo from source and tell us where it confuses you or breaks. If you want to be a design partner, email preston@unvibe.site. And if you just want to hear when the CLI is on npm, join the waitlist below.