March is the month Bugspot became a tracker you can actually sign into and file work in: entries with a rich-text editor, fully configurable priorities, statuses, and workflows, GitHub sign-in, and a bugspot CLI all landed. It’s the first of these monthly roundups — foundation more than polish — but the shape everything else builds on is already here.
The shape of an entry
Everything in Bugspot is an entry — a bug, a task, a story, an epic, all the same underlying shape. This month the entry got its full lifecycle: a create panel with a proper rich-text editor for the description, and a detail side panel where you edit fields inline and changes save on their own as you go. No modal gymnastics, no separate edit mode — you open an entry, you change it, it’s saved.
Configurable from day one
The thing that makes a tracker fit your team is whether its building blocks bend to your process — without burying you in custom fields. So the first real feature surface was making all of them editable: priorities, severities, resolutions, entry types, and statuses are all yours to add, rename, and remove — with drag-to-reorder so the order reflects how you actually think about them.
Statuses live inside workflows with real transitions — you define which states can follow which, and Bugspot respects that instead of letting anything jump to anything.
Keys that aren’t chained to projects
Every entry gets a short, memorable key like DS-142. The part most trackers get wrong is what that prefix is tied to. In Bugspot the prefix comes from a keyspace, and a keyspace is its own thing — one can span several projects, and each project points at whichever keyspace fits. So a prefix can stand for whatever your company actually organizes around: a team (DS for Data Science), a broader initiative, a product line — not just one repository. Numbers are handed out from the keyspace, so keys stay unique across your entire company and DS-142 always means exactly one entry.
That’s a deliberate break from tools like Jira, where the key is the project — which is why teams there so often end up bending “projects” into stand-ins for teams just to get the prefix they want. Keeping the key and the project as separate axes is one of the more distinctive things about Bugspot, and it probably deserves a post of its own.
Sign in with GitHub
You sign in with GitHub, on the web and — notably — in the terminal too. There’s already a bugspot CLI that logs in the same way and can list your projects. It’s small this month, but the foundation is solid, and it grows fast from here.
Finding your work
When you filter the entries list, the filters live in the link itself — so a filtered view is something you can bookmark or share, and it survives a refresh. It’s a small thing that pays off every day once you have more than a screen’s worth of entries.
Companies, projects, and workspaces
Bugspot is built around companies from the ground up. You sign in, pick or create a company, and everything you see belongs to it. Projects organize your entries, and workspaces let a team narrow the app down to just the projects and people they work with. A company settings area is where you configure those projects, workflows, and entry attributes.
That’s month one — the skeleton. It’s not much to look at yet, but it’s the right skeleton. Next month is where it starts to feel like a tool a team can share.
Bugspot is in public beta — take it for a spin and file your first entry.