Why I'm not buying Jira
I built a Kanban board from scratch recently. I used a ZazenCodes devtool repo as the skeleton, let Claude Code do most of the typing, and the whole thing came together in a morning before work: a web UI for dragging cards around, an API behind it, a CLI for when I don’t want to open a browser. It fits my head exactly, because I shaped every column to fit my head. And sitting there looking at it, I had the obvious thought. Why would anyone ever buy Jira or Trello?
I think I’m more right about that than Jira’s marketing would ever cop to. LLM-assisted coding moves the build-vs-buy line. A whole category of features that used to be obviously buy, because building them was slow and miserable, is now cheap enough to build that the math comes out different. For one person, the marginal value of Jira over a board that fits me is somewhere around zero, and probably negative once you count the bloat I’d be hauling around to run the 8% of the thing I’d ever actually touch.
But this is where I have to slow myself down, because the board was never what Atlassian was selling. I just proved the board is the easy part. The hard part is everything wrapped around it.
The biggest piece is the integration graph. In a real company the ticket is wired into everything else: the commit links back to it, CI flips its status, the deploy references it, chat pings on it, the incident tool spawns one, billing and time-tracking hang off it. And there are thousands of connectors for all of that, maintained by other people. I can build a connector to any one of those in a weekend. What I can’t do is build connectors to all of them and then keep every one alive as those external APIs quietly change underneath me, forever. That mesh is the moat, not the columns.
Then there’s the maintenance tail, which is the part the invent-it-when-I-need-it instinct never prices in. I can invent almost any single feature on demand, and that’s the right default; it’s how you avoid drowning in complexity you don’t need yet. What I can’t invent on demand is the ongoing ownership of everything I’ve already invented. Every feature I add is now mine to debug, mine to document, mine to migrate the next time something underneath it shifts. The build is a one-time spike. The upkeep is a tax I pay every month after, and it competes with the actual work I’d rather be doing. Buying is mostly paying somebody else to carry that tax, plus all the edge cases they’ve already hit that I haven’t gotten to yet.
Then multiplayer, which is its own cliff. The second I have to share the board with other humans I’m building a real-time collaborative permissioned database: sync, conflict resolution, who’s allowed to see what, who’s allowed to delete what, a log of who did. That’s a product. That’s where most homegrown tools quietly die.
A standard is also a shared language, and the value is the everyone, not the format. A new hire already knows how to read the thing. I can hire a consultant who’s used it. There’s a Stack Overflow answer waiting for me at 2am. My bespoke board has a bus factor of one, and that one is me. And a bus factor of one cuts the other way too: the board only remembers what I thought to tell it. Invent-it-when-I-need-it assumes I can reconstruct the past the moment I discover I want it, but if I realize I need an audit trail after the incident, or sprint history when I finally sit down to plan capacity, the data I never captured is just gone. The grown-up tools hoard data you don’t yet know you’ll want.
And the enterprise-support thing, the someone-to-blame thing, I used to be pretty cynical about. There’s some truth to the cynicism. But for a regulated shop the SOC 2 posture and the access reviews and the data-residency promises are what the lawyers require, and the vendor relationship is partly just risk moved off your own books.
So at what size does owning a growing pile of homemade tools cost more, in money and in bloat, than buying the maintained one? For me, one guy with one board, that crossover basically never shows up. Keep building. For a small team it’s a closer call, and a custom board can absolutely beat Jira. For a five-thousand-person regulated org, they were never buying a Kanban board at all. They’re buying the mesh, the permissions, the compliance posture, a skill they can hire for, and someone else’s maintenance burden. None of which was the part I found easy.
The instinct to invent it when I need it is still the right default. It just has a half-life, and the half-life is measured in team size, not in how good my board is.