Should I vibe code
Manage software stories, epics, iterations, roadmaps, and engineering workflows
Every commit message will contain a link to your tracker. Those links have to still resolve in five years.
?
Their verdict, the Team price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Stories, epics and an iteration board are CRUD with a drag handle, and an agent will hand you something convincing in an evening. The reason this stays a demo is not danger, it is gravity. An issue tracker becomes load-bearing the moment the team adopts it: every commit message and branch name carries a story ID, every pull request links to one, every postmortem and design doc cites a ticket number, and those references have to keep resolving for as long as the git history exists. That is the obligation you take on, and it comes with the parts nobody prototypes — search that works on four thousand stories, permissions when the contractor joins, notifications people trust enough to stop checking manually, and a migration path when the team outgrows it. You will get the board. What you will not get is anyone reaching for it instead of Slack.
What actually breaks
not "if". the specific failures.
- Search, which is fine on the demo's forty stories and useless at four thousand without real indexing — and search being bad is the reason people quietly stop using a tracker
- Notifications, which are either so noisy everyone mutes them or so quiet that a mention is missed, and there is no third state you reach by accident
- Story IDs, once they are embedded in commit messages, branch names and changelogs and have to resolve for the life of the repository
- Permissions, on the day a contractor or a customer needs to see one project and nothing else, and your model was "logged in"
- Iteration and velocity maths, which is easy to compute and easy to compute wrong: reopened stories, points changed mid-sprint, and work moved between iterations
- The integrations everyone expects — branch and pull request linking, Slack notifications, deploy annotations — which is where the real week goes
- History, when someone edits a story and there is no audit trail, so the question "who changed the acceptance criteria after we estimated this" has no answer
- Uptime, because a tracker that is down during standup wastes eight people's morning, and you are the on-call rota
Is that you?
the verdict is a default, not a law
- The team is you, or you and one other person who genuinely prefers it
- It reads from an existing system of record — GitHub Issues, Linear — and adds a view rather than owning the data
- The whole dataset exports to JSON with one command and you have run it
- Nothing outside the tool references its IDs, so abandoning it costs nothing but the URL
- More than a handful of engineers would depend on it during working hours
- Story IDs are already appearing in commit messages, because you have just signed up to keep those URLs alive
- Anyone outside the team — a client, a contractor, an auditor — needs scoped access
- It is your delivery record for a compliance process, where an un-audited edit history is a finding rather than an inconvenience
- You have not decided who fixes it at 09:00 on a Monday when the board will not load
If you build it anyway
the checklist, then the prompt that enforces it
- Write the export before the board. A one-command dump of stories, comments, attachments and relationships is the difference between an experiment and a hostage situation.
- Use stable, human-readable IDs from the first story and never renumber. Those strings are going into git history, where you cannot edit them.
- Use your identity provider for authentication rather than building logins, and design for at least three roles — member, restricted collaborator, read-only — before anyone asks.
- Put search on a real index early, and test it against a few thousand realistic stories rather than the twenty you seeded. Bad search is how a tracker dies.
- Give every story an append-only activity log: who changed what, when. It costs a table and answers every argument that comes up later.
- Make notifications configurable per project and per type from day one, and default them to conservative. Nobody returns to a tool that mailed them forty times.
- Back it up like a production database, with a restore you have actually performed. This is your team's memory of why decisions were made.
- Decide up front what happens if you stop maintaining it — an export, a migration script to a hosted tracker, and a redirect plan for the old URLs.
I am building an issue tracker for a software team: stories, epics, iterations
and a board. It will become the record everyone works from, so build the parts
that make it survivable before the parts that make it look good.
1. Export first. Before any UI, give me one command that dumps every story,
comment, attachment reference and relationship to JSON, and one that imports
it back. Prove the round trip.
2. Story identifiers are stable, human-readable and permanent from the first
record. Tell me why renumbering later is impossible once IDs are in commit
messages.
3. Authentication comes from our existing identity provider. Do not write a
login, session or password reset system for this.
4. Design the permission model now, not later: member, restricted collaborator
scoped to named projects, and read-only. Assume a contractor joins next
month.
5. Append-only activity log on every story — field, old value, new value, actor,
timestamp. Build it with the data model, not after.
6. Search against a real index, and seed the development database with several
thousand realistic stories so I can feel it. If search is slow at that size,
fix it before adding views.
7. Notifications default to quiet, are configurable per project and per event,
and always link back to a permalink that will still resolve after a rename.
8. Backups on a schedule with a restore I have run once, in front of you,
before this holds anything real.
9. Keep the API and webhooks small but honest: stable IDs, pagination, and no
endpoint that returns another team's data because a filter was omitted.
10. Out of scope for v1: time tracking, roadmap gantts, customer-facing portals
and AI summaries. They are the fun part and none of them are why people
stay.
11. Finally, tell me what it would take to get eight engineers to move off the
tracker they already know, and whether $10 a seat beats that conversation.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as a second engineer depends on it during working hours. $10 per seat per month buys search that works, notifications people have tuned, GitHub and Slack integrations kept alive by someone else, and an on-call rota that is not you at 09:00 on a Monday — and Shortcut's free tier already covers teams of up to ten, which is most of the people tempted to build this. The homemade version makes sense as a personal tracker or as a read-only view over data that lives somewhere else.
$10/mo is cheaper than your weekend.
The exit is the feature, so build it first: stories, comments and relationships in a documented JSON export, plus an importer for whichever hosted tracker you would fall back to. The thing that does not export is the URL. Story IDs live in commit messages, changelogs and old pull requests forever, so if you migrate, keep the old paths resolving with redirects to the new IDs — even as a static map — because a dead link in a five-year-old commit is how you lose the reason a piece of code exists.
Open-source issue tracking and project planning with cycles, modules and a self-hostable deployment.
Self-hostable task and project manager with kanban, filters and an API, for teams that want something smaller.
Questions
How is this different from the Asana entry?
Asana's entry is about adoption — tasks with owners and dates are a weekend, and getting a team to move is not. That is true here too, but an engineering tracker adds something Asana's does not: its identifiers leak into artefacts you cannot edit. A story ID in a commit message is permanent, and every one of them is a small promise that your tracker will still be answering requests years after you got bored of maintaining it.
What is the version of this that is actually worth building?
A read-only layer over a tracker you already have. Pull GitHub Issues or Linear through their API and render the view your team keeps asking for — an iteration board grouped your way, a roadmap that matches how you plan, a dashboard for standup. You get the bit you wanted, the data stays where its owners maintain it, and if you abandon your version nobody's workflow breaks.
Is maintenance tax really the highest number on this page?
Yes, and it is the honest one. Nothing here touches money, strangers or personal data worth stealing, so the danger scores stay low. What is high is the open-ended commitment: search, notifications, permissions, integrations and uptime, for as long as your team uses it, all owed to colleagues who did not choose your code and will tell you about it in person.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Project management tools are easy to build and impossible to get a team to adopt.
Configurable boards for one team is achievable. Configurable boards for any team is a platform.
Tasks, docs, goals, dashboards and automations. That is five products and you want all five.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice