Case study

Tracker

Case studies
Thijssen Software
Year
2026
Stack
Laravel · Vue 3 · TypeScript · Inertia
View source on GitHub →
Tracker case study cover
Result It replaced the paid SaaS entirely and became the day-to-day tracker for every project I run, with ticket creation wired directly into my development workflow.

The challenge

I was running every project through Linear until it hit the free tier's cap on active issues. The choice was to start paying or to own the tool outright. I took it as a reason to build something I fully controlled: a tracker that fit the way I actually work, held all my projects under one roof, and could be driven from the command line instead of a browser tab.

The interesting part was never the list of tickets. It was the surrounding structure that keeps a tracker honest: stable per-project identifiers that never reshuffle, epics with sub-issues that can't be nested into a tangle, a status flow that means the same thing everywhere, and an API trustworthy enough to script against. Getting those rules right, and enforcing them consistently across a web UI and a public API, was the real work.

What I built

  • A multi-project tracker where each project carries its own key and independent numbering, so issues get durable identifiers like CMS-71 that stay put as everything else moves around them.
  • The full issue model: types, priorities, a shared status flow (backlog, in progress, in review, done), labels, and one-level epics with sub-issues, with validation that refuses illegal shapes such as an issue becoming its own epic or crossing projects.
  • A Kanban board, filtering, and per-project views, built with Inertia and Vue 3 in TypeScript on a Laravel backend, with Tailwind and shadcn-vue for the interface.
  • A token-authenticated JSON API (Laravel Sanctum) covering the issue lifecycle, and a command-line client that creates a ticket and hands back a ready-to-use git branch name, so opening a ticket and starting work are a single step.
  • GitHub integration via signed webhooks: pull-request events are matched to their issue and reflected back on the ticket, tying code and tracker together without manual bookkeeping.
  • Team plumbing around it: project membership and roles, email invitations, CSV import and export, a dashboard, and a scheduled job that archives finished issues to keep the active board clean.
  • Held to the same engineering bar as the rest of my work: Pest feature tests, static analysis with PHPStan, and a consistent code style enforced by Pint.
Interested in this kind of work?

Let's talk about your project.

Start a similar project →