Why I Built Hamstik (Because Apparently We Needed Another Project Management Tool)

I've been developing software for over 30 years. During that time, I've worked with just about every flavor of project management and application lifecycle management tool imaginable. Some were excellent. Some were terrible. Most were somewhere in between, usually with a rather impressive price tag attached.

And after all those years, I kept coming back to the same question:

Why does managing the work sometimes feel like more work than actually doing the work?

Don't get me wrong. Tools like Jira and Azure DevOps are powerful platforms. They serve a purpose, and for large organizations with complicated requirements, they can make perfect sense. But not every development team is a Fortune 500 company with 14 approval processes, seven layers of management, and a committee responsible for deciding what color the backlog should be.

Sometimes you just want to build software.

And that's really where Hamstik started.

The Problem Isn't a Lack of Features

If anything, we have the opposite problem.

Modern project management platforms have become enormously complicated. They can do just about anything, provided you have the time, budget, and potentially a small team of certified administrators to figure out how.

Want to create a project? Great!

Want to create a board? Sure!

Want to invite a few developers to collaborate? Absolutely! But first, let's discuss licensing, user tiers, permissions, project configurations, and whether you need to upgrade your subscription.

Good grief. I just wanted to track a bug.

Over the years, I've watched tools evolve from relatively straightforward ways to organize development work into massive platforms that try to be everything to everyone. There's nothing inherently wrong with that approach. But somewhere along the way, I think we lost sight of the basic objective.

The tool is supposed to help us deliver software, not become another project we have to manage.

Simple Doesn't Have to Mean Useless

One thing I want to make clear: I didn't set out to build a stripped-down toy.

I like powerful software. I like automation, APIs, integrations, reporting, roadmaps, and all the things that help teams do their jobs effectively. What I don't particularly like is complexity for the sake of complexity.

There's a difference between a product being powerful and a product being complicated. With Hamstik, my goal is to provide the capabilities development teams actually need without requiring everyone to become an expert in the tool itself. Projects, work items, Kanban boards, sprints, roadmaps, and the ability to understand what's happening across your development efforts.

The important stuff.

And as Hamstik grows, I want to maintain that philosophy. Advanced capabilities should be available when you need them, not constantly getting in your way when you don't. It's surprisingly difficult to make software simple. Making it complicated is much easier. I've got 30 years of experience proving that particular point.

Let's Talk About Pricing

Here's another thing that has bothered me for years.

Why does adding another person to a project management tool have to be a financial decision?

Per-user licensing has become so common that we barely question it anymore.

You've got five developers? Here's your price.

Now you've got twenty developers? Congratulations! Your bill just got significantly larger.

Want a stakeholder to occasionally look at a roadmap? Better figure out whether they need a license.

I understand that software costs money to develop, host, maintain, and support. I'm a software developer, not a magician. But I also believe good software should be affordable, particularly for small teams, independent developers, and organizations that don't have enterprise-sized budgets. That's why affordability is a fundamental part of Hamstik's philosophy, not something I plan to address after I've figured out how to squeeze every possible dollar out of customers.

I'm not trying to win an award for the most creative licensing structure.

Frankly, I'd prefer not to need a spreadsheet to explain what something costs.

Built by a Developer, for Developers

Hamstik started as a personal development project.

I've always enjoyed building software, exploring new technologies, and seeing whether I can approach an old problem differently. Even after three decades, that hasn't changed.

Hamstik also gives me an opportunity to build something the way I think software ought to be built, without a dozen committees, competing organizational priorities, or someone asking whether we can schedule a meeting to discuss scheduling another meeting. It's an opportunity to experiment, make mistakes, learn, and improve.

One of the more interesting aspects is using modern AI-assisted development tools and coding agents as part of the development process. I'm particularly interested in making Hamstik useful not just for human developers, but for the automation and AI tooling that increasingly participates in software development. In fact, one of my goals is for Hamstik to manage the development of Hamstik itself.

I figure if I can't stand using my own product, that's probably a pretty good indication I've done something wrong.

And yes, I'll occasionally build something, look at it, and wonder what on earth I was thinking. That's part of software development too.

I'm Not Trying to Replace Everything

Hamstik doesn't need to be your source code repository, your CI/CD engine, your cloud infrastructure platform, and your coffee maker. There are already excellent tools for those things.

I believe teams should be able to choose the tools that work best for them. GitHub, GitLab, Azure DevOps, Gitea, or whatever makes sense for their environment. Hamstik should complement those tools, not force you to abandon them.

The goal is to provide a practical place to plan, organize, and understand development work without dictating how every other part of your development process must operate. And if your current tools already do everything you need at a price you're happy with, that's great!

I'm not going to tell you that Hamstik will magically make your developers 400% more productive while simultaneously improving morale and reducing coffee consumption. Anyone making those promises should probably be viewed with a healthy amount of suspicion.

So Why a Hamster?

Well, why not?

Software development is serious work, but I don't think every piece of software needs to look like it was designed by an accounting department.

I wanted Hamstik to have some personality.

Something approachable, a little goofy, and hopefully memorable.

Besides, a hamster running on a wheel seems like a reasonably accurate representation of software development sometimes.

The trick is making sure we're actually going somewhere.

Where Does Hamstik Go From Here?

I have plenty of ideas for Hamstik. Probably more than I have any business attempting. But the goal isn't to build the biggest project management platform in the world.

It's to build one that people genuinely enjoy using. One that gets out of their way, provides useful capabilities, respects their time, and doesn't require an uncomfortable conversation with their finance department every time their team grows.

Will Hamstik be perfect? Absolutely not.

Will there be bugs? Almost certainly. I've been writing software long enough to know better than to make that promise.

Will it continue to improve? That's certainly my intention.

At the end of the day, Hamstik exists because I believe there's room for another approach to managing software development.

Less complexity. Reasonable pricing. Useful features. And maybe a little personality along the way.

If that sounds interesting, have a look at hamstik.com.

And if nothing else, you get to see a hamster attempting to bring some sanity to project management.

Which, when you think about it, is a pretty ambitious assignment for a small rodent.