Should I vibe code
Keyboard-first issue tracker and project planner for product teams
The board is a weekend. Being the reason nobody can file a bug on Monday is the rest of your year.
?
Their verdict, the Basic 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
An issue tracker is the most tempting CRUD app in existence — a table, a status column, a board view, and an agent will have it running before lunch. But Linear's product was never the table. It is that a keypress never waits for a network round trip, that the same issue is the same issue across three devices and a flaky train wifi, and that four years of decisions are still findable after two schema migrations. Your version will demo beautifully. What gets you is the next part: a team starts trusting it, and an issue tracker a team trusts has quietly become infrastructure with an on-call rota of one.
What actually breaks
not "if". the specific failures.
- Search, about six weeks in. LIKE '%term%' across four thousand issues is fine right up until somebody genuinely needs the ticket where a decision was made
- Notifications, which are email deliverability wearing a product hat — a mention that never arrives is worse than no mentions at all
- Permissions. Every tracker eventually holds an embargoed security report, a performance concern about a named person and an unannounced launch date, and your version shows all three to anyone with a login
- The optimistic UI. Linear feels instant because it lies convincingly and reconciles later; the naive copy shows a ticket as moved, drops the request, and keeps showing it moved until someone refreshes
- Issue identifiers, the first time you migrate. ENG-412 is in a commit message, a changelog, a customer email and a Slack thread, and renumbering breaks every one of them
- Credentials and customer records pasted into ticket bodies by teammates who assume your tracker is as safe as the SaaS one it replaced
Is that you?
the verdict is a default, not a law
- It is your own personal backlog and nobody else files into it
- You want a thin, opinionated view over an API you already pay for rather than a replacement for it
- The team is you, and the cost of a day's downtime is that you go back to a text file
- Anyone outside your immediate team can create issues — that is a public write endpoint with a filing cabinet behind it
- Sprint planning, incident timelines or anything a manager reports upward depends on it
- You have taken backups but never restored one
- Issue IDs are already appearing in commit messages, because you have just made your data model permanent
If you build it anyway
the checklist, then the prompt that enforces it
- Export before anything else: one JSON dump per issue, comments included, running from cron on day one. That file is your entire escape route.
- Use Postgres full-text search from the first commit. Retrofitting search onto a tracker people have already filled is a rewrite disguised as a feature.
- Issue identifiers are permanent and never reused. Pick the scheme before the first issue exists, because it leaks into commits within a week.
- Decide up front whether private issues exist. Adding visibility rules after a thousand issues means auditing every query you have already written.
- Keep an append-only log of state changes rather than mutating a status column. 'When did this become urgent' is the question you will actually be asked.
- Do not build offline sync. It is the most expensive feature in this category and the one people least tolerate being subtly wrong.
I am building an issue tracker for a small team. Treat it as something people
will come to depend on rather than a demo, and apply these before any
feature work.
1. Build the export first: a scheduled dump of every issue, comment,
attachment reference and status transition as JSON, plus a documented
import script. Prove the round trip before writing any UI.
2. Issue identifiers are immutable and never reused, including after deletion.
Settle the scheme now — it ends up in commit messages within a week.
3. Model status changes as an append-only event log, not a mutable column.
Boards and reports are derived from that log.
4. Use Postgres full-text search from the first commit. Do not ship LIKE
queries with a plan to fix them later.
5. Decide the visibility model before the first issue: which issues are
private, and to whom. If I say 'everyone sees everything for now', tell me
what changing that later will cost and make me confirm.
6. Authentication goes through an existing provider — OIDC or a hosted
identity service. Do not hand-roll sessions, password reset or invites.
7. Attachments are size- and type-checked, stored outside the web root and
served through an authorised handler. Never a public bucket URL.
8. Put a warning in the README that people paste API keys and customer data
into tickets, and add a coarse secret-pattern check on issue creation.
9. Do not implement optimistic mutation without a reconcile path. If a write
fails, the UI reverts visibly instead of continuing to pretend.
10. Every notification must be idempotent and rate-limited. A retry loop that
emails the team forty times will end this project faster than an outage.
11. Out of scope, and say so rather than approximating: multiplayer cursors,
cycle analytics, roadmaps and SLA reporting.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
The moment a second person files an issue expecting it to still be there in a year. Ten dollars a seat buys somebody else's backups, somebody else's search index and somebody else's 2am when a disk fills up. If self-hosting is the real goal rather than building, Plane gives you most of Linear's shape without you owning the migration scripts.
$10/mo is cheaper than your weekend.
The issues are the asset and they are mercifully portable: title, description, state, assignee, timestamps and comments, one JSON object each. Dump them nightly and you can be on Linear, Plane or GitHub Issues within an afternoon. The two things that do not transfer are the identifiers already sitting in your commit history and your own muscle memory, so keep the ID scheme boring and predictable from the start.
Open-source project and issue tracker with cycles, modules and boards; the closest self-hosted Linear analogue.
Open-source all-in-one platform whose tracker module is an explicit Linear alternative.
Questions
Why demo-only rather than ship-it? Nothing here is dangerous.
Nothing here is dangerous, and that is precisely the demo-only case: the failure is a product gap, not a breach. You will have a lovely board by Sunday night and still be missing search, notifications, permissions and offline behaviour a year later — while a team that started filing into it needs all four.
What actually makes Linear feel fast?
A local cache the UI reads from, writes applied optimistically, and a sync engine reconciling in the background. It is the hardest thing in the product and the least visible. Copy the look and you get the look; the feel comes from the part nobody screenshots.
Is a personal backlog a different answer?
Completely. One person, one machine, no notifications, no permissions — that version is close to ship-it and takes an evening. Everything on this page begins when the second person files an issue and expects a reply.
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.
Natural-language date parsing is the only hard bit, and it is a solved library.
You will build twenty percent of Notion in a weekend and the other eighty for the rest of your life.
Writing the scheduler is a weekend. Believing it at 8am on a Monday six months later is the whole product.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice