You can take it a step further and strip out the frontend. Honestly. Nobody needs it and if you need any UI stuff it in the MCP.
This is what I did with this project https://github.com/crmkit/crmkit/ and to be honest the approach grows on me and fits well if you are a backend person.
People who like Jira (or rather want; I doubt one ever “needs” this thing), and make decisions on its implementation and payment, and force it on others, are not the people who are shopping for alternatives. So who these alternatives are really for?
I’m co-developing lots of projects with AI. Right now I have a hand-rolled backlog system that lives in each project’s git repo with a standard prompt on how to create, triage, and review backlog items.
This looks great for me. Better than what I have, smaller/cheaper/more AI focused than Jira.
i always quite liked the flexibility of jira and the ability to logically connect tickets etc. I can see how it's perceived as this clumsy corporate tool, but i often whish gh issues had more of the features jira has.
As I use claude more and more I've started using git worktrees, one branch per worktree per PR, with possibly multiple agents working in each worktree at the same time on different aspects. And I manually instruct those agents. Like Emdash/Cursor/Zed. Sometimes I review code locally, sometimes agents push and I review in GitHub, no clear system yet. (jj seems promising, but Zed doesn't seem to support jj as well as git, so have delayed looking at it.)
But Paca is hinting in another direction where the agents are more in control of the branches/worktrees to use and are created by the agent? What tooling is used to support such flows? Would people use GitHub with Paca or is GitHub redundant as well.
This is pretty much my flow as well. Haven't gone beyond managing three work trees in parallel. It's nice being able to test locally against multiple work trees -- one is at 3000, then 3001, etc.
I've been trying keeping an eye on open source issue trackers/project managament tools I can self-host -- with good cli/mcp capabilities. So quite happy to see this as I feel there isn't a lot! (currently also using gh issues) will check it out!
Awesome to see this. Like a few others here, I hand-rolled (well, Codex-rolled) something similar that works great for me. I keep going back and forth on open-sourcing it, but my hunch is people won't really adopt these kinds of things anyway.
Everyone ends up with a workflow shaped really tightly around how they work, and it's gotten so cheap to just build and evolve your own as the models and harnesses change that picking up someone else's stops making much sense.
I think we can consider this among the positive consequences of LLMs. Building software is cheaper, you don’t have anymore to adapt your company processes to the tools available in the market. If you don’t find what you’re looking for, you can build it and actually see if there’s a market interest for it.
Aren't we losing something there too though. I always respected a company with a product that had "things figured out" and pushed their product in conjunction with a way of working that was well researched and proven to be optimized.
I'm not convinced companies always need software tailored to their workflows, and could benefit from adopting worn-path workflows instead.
> I'm not convinced companies always need software tailored to their workflows, and could benefit from adopting worn-path workflows instead.
I’m dubious, because for an established company the question is whether the software adapts to the org, or if the org adapts to the software. It’s a lot harder to change the workflow of a whole company than to buy software that enables your current workflow. There’s months of retraining and figuring out where compliance goes in the new workflow, and things that get done wrong along the way because it’s new, and etc.
You need a pretty big efficiency win to offset the dead weight of time spent just changing workflows.
That makes sense when things are mostly stable and it makes little sense for most teams to work outside the norm.
Currently though we are in a world where things change every week, model capabilities, harnesses, pricing etc. Forcing a norm wont work, because there is no such norm.
I am fully convinced companies actually loose money because they have bunch of employees who waste time “bending reality” thinking they need custom workflow because “they are so specialized”.
I'm using GitHub issues and GitHub Projects with `gh` cli and I find it works well, though what I really like about this is your project level chat. I find myself having to come back to a project level session often. May give this a try, just hesitant to put it on something that's in-flight with already lots of stuff, will have to be a net new project.
Thanks! Glad you like the project-level chat. Starting with a fresh project is definitely the safest bet to see if the workflow fits you. If you ever do try it out, I'd love to get your feedback!
Thanks for open-sourcing this! I built something similar for myself, but after few months it's so personalised that it's in no shape to be open-sourced.
That is exactly how this started! It's so easy for internal tools to become a mess of hyper-specific features.
I spent a lot of time trying to keep the core lean and moving the custom logic into the WASM plugin architecture precisely to avoid that trap. If you have any specific features from your internal tool that you found indispensable, I’d love to hear about them!
Thanks! That's exactly why I built Paca. Traditional Jira feels way too slow when vibecoding—with this, we can just use the project chat to co-plan and assign tasks with AI in real-time.
You can take it a step further and strip out the frontend. Honestly. Nobody needs it and if you need any UI stuff it in the MCP.
This is what I did with this project https://github.com/crmkit/crmkit/ and to be honest the approach grows on me and fits well if you are a backend person.
I can't believe you guys give this for free. I was considering buying "Linear", now I just saved 10$/month with this. Thank you so much
People who like Jira (or rather want; I doubt one ever “needs” this thing), and make decisions on its implementation and payment, and force it on others, are not the people who are shopping for alternatives. So who these alternatives are really for?
I’m co-developing lots of projects with AI. Right now I have a hand-rolled backlog system that lives in each project’s git repo with a standard prompt on how to create, triage, and review backlog items.
This looks great for me. Better than what I have, smaller/cheaper/more AI focused than Jira.
i always quite liked the flexibility of jira and the ability to logically connect tickets etc. I can see how it's perceived as this clumsy corporate tool, but i often whish gh issues had more of the features jira has.
There's an entirely new class of people doing development with AI.
Presumably some of them?
The people it's being forced on, maybe?
PM says "we're going to start using Jira", engineer says "how about we use this thing that looks similar but is not as terrible as Jira?"
What are people's workflows these days?
As I use claude more and more I've started using git worktrees, one branch per worktree per PR, with possibly multiple agents working in each worktree at the same time on different aspects. And I manually instruct those agents. Like Emdash/Cursor/Zed. Sometimes I review code locally, sometimes agents push and I review in GitHub, no clear system yet. (jj seems promising, but Zed doesn't seem to support jj as well as git, so have delayed looking at it.)
But Paca is hinting in another direction where the agents are more in control of the branches/worktrees to use and are created by the agent? What tooling is used to support such flows? Would people use GitHub with Paca or is GitHub redundant as well.
This is pretty much my flow as well. Haven't gone beyond managing three work trees in parallel. It's nice being able to test locally against multiple work trees -- one is at 3000, then 3001, etc.
I've been trying keeping an eye on open source issue trackers/project managament tools I can self-host -- with good cli/mcp capabilities. So quite happy to see this as I feel there isn't a lot! (currently also using gh issues) will check it out!
Backlog.md the project: tasks live in your repo, atomic and race free
Awesome to see this. Like a few others here, I hand-rolled (well, Codex-rolled) something similar that works great for me. I keep going back and forth on open-sourcing it, but my hunch is people won't really adopt these kinds of things anyway.
Everyone ends up with a workflow shaped really tightly around how they work, and it's gotten so cheap to just build and evolve your own as the models and harnesses change that picking up someone else's stops making much sense.
I think we can consider this among the positive consequences of LLMs. Building software is cheaper, you don’t have anymore to adapt your company processes to the tools available in the market. If you don’t find what you’re looking for, you can build it and actually see if there’s a market interest for it.
Aren't we losing something there too though. I always respected a company with a product that had "things figured out" and pushed their product in conjunction with a way of working that was well researched and proven to be optimized.
I'm not convinced companies always need software tailored to their workflows, and could benefit from adopting worn-path workflows instead.
> I'm not convinced companies always need software tailored to their workflows, and could benefit from adopting worn-path workflows instead.
I’m dubious, because for an established company the question is whether the software adapts to the org, or if the org adapts to the software. It’s a lot harder to change the workflow of a whole company than to buy software that enables your current workflow. There’s months of retraining and figuring out where compliance goes in the new workflow, and things that get done wrong along the way because it’s new, and etc.
You need a pretty big efficiency win to offset the dead weight of time spent just changing workflows.
That makes sense when things are mostly stable and it makes little sense for most teams to work outside the norm.
Currently though we are in a world where things change every week, model capabilities, harnesses, pricing etc. Forcing a norm wont work, because there is no such norm.
I am fully convinced companies actually loose money because they have bunch of employees who waste time “bending reality” thinking they need custom workflow because “they are so specialized”.
Specifically on the AI side, how does it compare to beads?
I'm using GitHub issues and GitHub Projects with `gh` cli and I find it works well, though what I really like about this is your project level chat. I find myself having to come back to a project level session often. May give this a try, just hesitant to put it on something that's in-flight with already lots of stuff, will have to be a net new project.
Thanks! Glad you like the project-level chat. Starting with a fresh project is definitely the safest bet to see if the workflow fits you. If you ever do try it out, I'd love to get your feedback!
Was thinking about building something similar, thanks for sharing.
Glad to I'm not the only one thinking about moving away from Jira
This couldn’t have come at a better time!! This is exactly what I was going to build next now that my agent swarm is done.
Thanks for open-sourcing this! I built something similar for myself, but after few months it's so personalised that it's in no shape to be open-sourced.
That is exactly how this started! It's so easy for internal tools to become a mess of hyper-specific features.
I spent a lot of time trying to keep the core lean and moving the custom logic into the WASM plugin architecture precisely to avoid that trap. If you have any specific features from your internal tool that you found indispensable, I’d love to hear about them!
In my mind Jira is gone, glad to see others are thinking in the same direction.
Where does Jira really sit in a world eaten up by vibecoding?
Thanks! That's exactly why I built Paca. Traditional Jira feels way too slow when vibecoding—with this, we can just use the project chat to co-plan and assign tasks with AI in real-time.