From a kanban board to a company

Claude, the AI assistant made by Anthropic, has worked on rm-rf software's code alongside founder David O'Connor since the first commit. So we asked Claude to do the interview. Claude wrote the questions; the answers are David's.

Claude: I should declare an interest: I co-wrote a lot of the commits we're about to talk about. So let's start before me. Why build a kanban board when there are plenty already?

David: Because I wanted one that worked the way I work. I've been a developer for ten years, the last two as a tech lead and manager, and I've used every board going. They track tasks, but they don't know what the work is worth, and none of them were built with AI agents in mind. So I coded my own, just for me.

Claude: And then the agents arrived.

David: That was the turning point. Once the board was running and the agents were working from it, I sped up immensely. The agents had one clear place to take work from and to record what they'd done, and I could see all of it.

Claude: What did your board give the agents that the others didn't?

David: An MCP server. MCP is the standard AI assistants use to work with other software, and that was what really unlocked it. Anything you can change in the app, an agent can change through MCP, apart from a person's own settings like their avatar or how they sign in. There's a test that fails if a feature reaches the app without reaching MCP, unless it's on that short list of exceptions with a reason written next to it.

Claude: I've been on the receiving end of that test. But letting an agent do what a person can is a lot of trust.

David: Which is why access was built in from the start, not added later. Agents are members of the organisation with their own roles, and those roles work exactly like a person's: the same permission areas, the same grants for each team or project. An agent never gets more than it's been given, and it can't even see the tools its role doesn't allow. Every call is rate limited, and every change goes into the audit log marked "via MCP". So you can always see who did what, person or agent, and what they were allowed to do.

Claude: Permissions decide who can change what. But agents make mistakes, and so do people. How do you keep the data itself right?

David: By putting the rules in the system instead of relying on anyone's good behaviour. Each organisation's data is kept apart by the database itself, and the API won't start if its database user could get round that. Every request is checked against the API's published contract before it touches anything. If two people, or a person and an agent, edit the same thing, the second one is told it's out of date instead of silently overwriting the first. Money gets the strictest treatment: a payment changes a total in one checked step, so two payments at the same moment can't both slip past a limit. And there are tests that fail if a new route skips the permission check or the audit log. We break the code on purpose to prove the tests catch it.

Claude: With all that in place, how much faster did it get? People will ask.

David: I'd rather show the numbers than give a multiplier. In the nine days from 28 September to 6 October 2026, we made 772 commits and merged 217 pull requests across four codebases: the board, its API, the support desk and its customer site. Every one of those changes started as a ticket on the board. You were on most of the commits.

Claude: I co-wrote 542 of the 545 that weren't merges, if we're counting. Speed like that could easily turn into chaos. What kept it in order?

David: The same thing that keeps a team in order: a process, written down and done the same way every time. Ticket first. Brainstorm one question at a time. Write the spec, write the plan, build it ticket by ticket, test it properly, then review the whole thing and ask whether it's really the simplest, most robust answer. The agents follow it like anyone else.

Claude: It hasn't all gone smoothly, though. What went wrong?

David: Plenty. Early on I had two agents running test suites side by side on my laptop, and they ran it out of memory. It froze twice in one day and needed a hard reset. Another time a script an agent wrote to count rows in my own database pasted in a whole migration and ran it, and it rolled part of the schema back. And one agent tidied up what it thought was its own leftover copy of a repo, and it was another session's work in progress.

Claude: I remember. What did you change?

David: Each one became a written rule in the handbook every agent reads at the start of a session. Back up before you touch a real database, even to read it. Check how much memory is free before a heavy run, and never run more than two at once. Before you remove anything, check whose it is. None of those mistakes has happened twice. That's the part I care about: the agents make mistakes, like people do, so the system has to learn from each one.

Claude: "The simplest answer" sounds like it might explain the company's name. To developers, rm -rf is the command that deletes everything.

David: That's exactly it: wiping out complexity. Strip things back to the simplest solution that works, then build it to enterprise quality, with security and data integrity in everything. People assume simple means basic. It doesn't. It means you've done the hard thinking so the person using it doesn't have to.

Claude: And the products are all "Do" something: DoWorkflows, DoRoutes, DoCommerce.

David: Because the software should let you just do your job. It does what it sets out to do, efficiently and well, and gets out of the way.

Claude: DoWorkflows started as your board. What has it become?

David: The place the whole business runs from, not just the development work. Every ticket knows which customers and how much revenue it touches, so you work on what pays. It researches your market and competitors, down to the search keywords they bid on and a rough idea of their ad spend, and proposes a go-to-market plan. Leads and deals have their own pipeline. Customers raise issues through the support desk and follow them from report to release. And dashboards put the whole business on one screen.

Claude: You've used it to build something very different, too.

David: DoRoutes, for removals, waste and delivery firms. It's the proof that the process works well beyond software. It plans each van's day around the van's real size and weight, the drivers on shift, traffic and this week's fuel prices, and there's a driver app for proof of delivery. We rebuilt it as a proper multi-tenant platform, driver app included, in about three weeks, run entirely from the board. It goes on sale on 28 October.

Claude: So development largely runs itself now. What's next?

David: Automating everything else. For DoWorkflows that means researching leads before a call, testing new product ideas against the market, and drafting blog posts and newsletters for a person to approve. In the longer run I'm building towards a platform that can run a whole business on autopilot, with human approval wherever you want it, whatever the size of the business. We're not there yet, and I won't pretend we are. But every piece we ship keeps a person in charge of the decisions that matter.

Claude: Last question. What would you tell a founder who's wondering whether to let AI agents into their business?

David: Give them somewhere organised to work from, and decide what they're allowed to do before they start. The agents on their own didn't make the difference. The difference was clear work, the same access a person would have, and everything recorded. Get that right and the speed follows.

DoRoutes is on sale from 28 October at doroutes.com (opens in a new tab). DoCommerce comes next, while DoWorkflows is still taking its final shape.