← All posts

Introducing Bugspot

A note on why I am building this, who it is for, and what to expect from the blog.

cover · hero-introducing-bugspot

Hi. I’m building Bugspot — a bug tracker and project-management tool for software teams of 5 to 50 people. This is the first post on the Bugspot blog, so it’s worth saying upfront what it is, who it’s for, and why I think the world needed another tracker.

Why this, why now

Every team I’ve worked with has had a love-hate relationship with their tracker. Jira is the one everyone ends up on, and it bends to fit any team — but the price for that flexibility is a tool with forty-seven custom fields, a workflow scheme nobody fully understands, and an admin surface area that takes a dedicated person to maintain. Linear went the other way: clean, opinionated, fast — but those opinions don’t bend, and plenty of teams hit the wall the moment their process doesn’t match the one Linear assumes.

Then there’s the long tail of teams who gave up on dedicated trackers entirely. They live in Trello, Asana, ClickUp, or Notion — none of which were built for software work — because Jira looks like a second job and GitHub Issues stopped being enough months ago. Those tools all hit the same ceiling eventually: they don’t model what a bug actually is, they don’t know about commits or pull requests, and the moment your process needs more than a sticky note on a column, you’re back where you started.

Bugspot is what I wished existed in the middle: an opinionated tracker that still leaves room to configure the parts that genuinely vary between teams.

What Bugspot stands for

We believe software should solve problems, not create them.

Our goal is not to build the biggest platform with the longest feature list. Our goal is to build software that is clear, reliable, and genuinely useful every day.

We value simplicity over complexity, clarity over buzzwords, and long-term customer trust over short-term growth metrics. We believe great products come from listening to customers, making thoughtful decisions, and focusing on what matters most instead of chasing every trend.

We’re building for the long run. That means sustainable growth, direct relationships with customers, fast support, and a commitment to continuously improving the product without turning it into an enterprise maze.

We believe the best software feels obvious, stays out of your way, and helps teams do great work.

What that looks like in practice — the specific features we ship and the ones we’ll never build, how the pricing works, where we draw the line between configurable and bloated — gets its own posts on this blog as we write them. This one is about the why.

If that’s the kind of tool you’d want, you’re probably the person Bugspot is for.

Who Bugspot is for, and who it isn’t

Bugspot is built for software teams in the 5–50 person range. That’s the band where Jira is overkill and you’ve outgrown GitHub Issues or Trello.

If your team is bigger than that, or if you need SSO tiers, audit logs that satisfy SOC 2, or approval chains that satisfy your legal team — Bugspot isn’t going to be a fit, and I’d rather tell you that now than after you’ve spent a week setting it up. Jira will probably serve you better there. Different tools for different problems.

The beta is the point

Right now Bugspot is in public beta. Free during the beta, paid once it goes 1.0.

What “beta” actually means for you: the product is stable enough to track real work — I run Bugspot’s own development inside Bugspot — but the surfaces are still moving, and the things you tell me you need are likely to land before the things on my own list. If you sign up, you aren’t just a user; you’re shaping which corners get sanded down before 1.0. I read every piece of feedback, and the small size of the beta is the reason that’s still possible.

What this blog is

I’ll write here about the design decisions behind Bugspot — the ones that turned out well, the ones I had to walk back, and the ones still up for debate. Two posts already up are good examples: why Bugspot has no custom fields and where I draw the line on configurable workflows. Expect more in that vein. Less changelog, more “here’s why the product looks the way it does.”

If any of this resonated, give it a try — and tell me what’s broken. That’s the most useful thing you can do during a beta.

— Vladimir

#introduction#beta#bugspot