# How Shuriken started: a tool we built for ourselves

> We build software for clients and ourselves. No harness fit how heavily we use AI, so we built our own. Then a programmer asked: why don't we sell this?

Source: https://shuriken.sh/blog/how-shuriken-started

We build software for clients and ourselves. No harness fit how heavily we use AI, so we built our own. Then a programmer asked: why don't we sell this?

Story By Shuriken Updated 27 October 2026 4 min read

**Contents**

Shuriken began as a harness our company built for itself, because none of the ones we tried fit how heavily we use AI. People ask who's behind it, and they should: you're trusting this tool with your accounts and your code.

## We make software for a living #

For years our company has built software and websites for clients. Next to the client work we've always made products of our own. That's our day job, and it still is.

We're not a lab and we're not a startup that set out to build an AI tool. We're a team that ships software every week, for other people and for ourselves. That matters for what follows, because Shuriken was shaped by that kind of work: long days, several projects at once, deadlines that don't move.

## AI crept into every day #

We started using AI in our daily work about two years ago, on small things at first: a function, a test, a second opinion on a tricky bug. It grew from there, and today coding agents are part of how almost everything here gets built.

And the more we used them, the more the tools around them got in the way.

## No harness fit how we worked #

A harness is the software around a coding agent: where its chats live, which account it runs on, how you start it, follow it and answer it. (We wrote a longer explanation in [What is an agent harness?](https://shuriken.sh/guides/what-is-an-agent-harness))

The harness is the outer layer: your accounts, devices, tools and you, around the agent.

We tried a lot of them, more than we'd like to count. Some were good at one thing. None fit the way we worked, and the way we worked was heavy:

- switching accounts: we had several, and a chat that ran out on one had to move to another by hand (log out, log in, paste the context back);
- hitting limits, always in the middle of something and never at a convenient moment;
- running many agents in parallel, a handful at a time across different projects rather than one chat;
- working from anywhere: at the desk, on another computer, or away from the desk checking on an agent from a phone.

Every tool we tried handled one or two of these. None handled all of them together, and it was the combination that ate our time. The long rant about the account part is in [We were tired of logging in and out of Claude](https://shuriken.sh/blog/why-we-built-shuriken).

## So we built our own #

About seven months before our first build, we stopped looking and started building. Just for us: an internal harness that did what we needed, the way we needed it.

That wasn't a weekend hack. We put real time into it, next to our main projects, and kept putting time in, because a tool you use every day is never finished. When a provider changed something, we fixed it. When something annoyed us twice, we changed it. The people building it were the people using it, so nothing annoying survived for long.

The parts you'd recognise today started there. Chats moving by themselves to an account with room left, which became [automatic source switching](https://shuriken.sh/features/source-switching). Running many agents at once without them tripping over each other, which became [parallel agents](https://shuriken.sh/features/parallel-agents). Following everything from wherever we were.

Shuriken today: several chats in one project, each working on its own branch.

In Shuriken a chat can work on its own branch in its own worktree, and Finish merges it after your checks.

[Try Shuriken](https://shuriken.sh/)

## "Why don't we sell this?" #

About four months into building it, one of our programmers asked a simple question: why don't we sell this?

It clicked right away. We hadn't built this because we wanted a product. We'd built it because nothing out there fit, and we'd looked hard. If we had that problem, other people who use coding agents as much as we do had it too. There was a gap, and we had been quietly filling it for ourselves for months.

## Rebuilding it for other people #

An internal tool can assume a lot. It can assume you know where every setting lives, because you put it there. It can assume your accounts, your computers and your habits. Strangers have none of that.

For about the next three months we reworked it heavily, asking one question of every screen: would someone who has never seen this understand it? Setup had to work without one of us sitting next to you. A name we'd picked among ourselves had to make sense to someone who wasn't there when we picked it. And what we'd learned the hard way, like keeping your accounts yours and your code on your own machines, had to be built in instead of remembered.

What came out of that is Shuriken.

## Where we are now #

Shuriken isn't something we do next to our main work any more. A dedicated part of the company now works only on Shuriken: building it, fixing it, and using it every day on our own projects, the same way it started.

The first builds went out on 29 September 2026, to a small group first, because we'd rather find what breaks with a few people than with everyone. We're still working the way we started: use it hard every day, fix what annoys us, ship small changes often.

If you run more than one coding agent, or more than one account, we built this for people like you, because we're people like you.

Shuriken is open to everyone now. What happened next is in [Shuriken is officially launched, in beta](https://shuriken.sh/blog/shuriken-is-now-in-beta), and you can [try it](https://shuriken.sh/) today.

Share

[X](https://x.com/intent/post?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fhow-shuriken-started&text=How%20Shuriken%20started%3A%20a%20tool%20we%20built%20for%20ourselves)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fhow-shuriken-started)[Hacker News](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fshuriken.sh%2Fblog%2Fhow-shuriken-started&t=How%20Shuriken%20started%3A%20a%20tool%20we%20built%20for%20ourselves)[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fshuriken.sh%2Fblog%2Fhow-shuriken-started&title=How%20Shuriken%20started%3A%20a%20tool%20we%20built%20for%20ourselves)[E-mail](mailto:?subject=How%20Shuriken%20started%3A%20a%20tool%20we%20built%20for%20ourselves&body=https%3A%2F%2Fshuriken.sh%2Fblog%2Fhow-shuriken-started)

## Frequently asked questions

**Who makes Shuriken?**

A software company that has built client software, websites and its own products for years. Shuriken started as its internal harness, and a dedicated part of the company now works only on Shuriken.

**Why was Shuriken built?**

No harness we tried fit heavy daily use: several accounts, limits in the middle of a task, many agents in parallel and working from anywhere. So we built our own, then rebuilt it for other people.

**Is Shuriken a side project?**

Not any more. It began as an internal tool we built next to our main projects. Today a dedicated part of the company works only on Shuriken.

Parallel agents

Agents side by side, each on its own branch if you want.

A new chat gets its own branch and worktree unless you pick the project folder, so agents don't step on each other. Finish runs your checks and merges each one back.

[Try Shuriken](https://shuriken.sh/)

[How it works](https://shuriken.sh/features/parallel-agents)

## Keep reading

- [A git workflow for Claude Code that keeps main clean: Story 27 Oct 2026 4 min read The Claude Code git workflow we'd give anyone running several agents: a branch per task, small commits, read the diff, checks before merge, then squash.](https://shuriken.sh/blog/claude-code-git-workflow)
- [How to review AI-generated code without reading every line: Story 27 Oct 2026 5 min read We review agent diffs tests first: would each test fail without the change? Then deletions, the diff's edges, secrets, and a run. Our real misses.](https://shuriken.sh/blog/review-ai-generated-code)
- [Why every chat gets its own git worktree: Story 27 Oct 2026 3 min read Two coding agents in one folder break each other's builds. In Shuriken every chat but Main gets a git worktree: its own checkout and branch.](https://shuriken.sh/blog/worktree-per-chat)
- [Fork a chat from any reply, then merge it back: Update 27 Oct 2026 3 min read Try another approach without losing the first: fork a Shuriken chat from any reply, keep the fork under its parent, then merge its work back in.](https://shuriken.sh/blog/fork-and-merge-into)
- [Run a chat on another computer and keep going: Update 27 Oct 2026 4 min read Move a coding agent chat to another of your computers or a server. It stays the same chat, with its history and uncommitted work, and runs there.](https://shuriken.sh/blog/run-chat-on-another-computer)

## Free tools

- [Claude limit reset tracker](https://shuriken.sh/tools/limit-resets/claude)
- [Codex limit reset tracker](https://shuriken.sh/tools/limit-resets/codex)
