A year ago, I was consulting for a client whose director was venting about their Jira invoice. My first instinct was to defend the tool. Jira is genuinely an excellent software, packed with capability. Their response stuck with me: "That's exactly the problem. We're paying for capability we don't use."

That's not a Jira problem. It's a market-segmentation problem.

The gap nobody's pricing for. Enterprise tools like Jira and Monday.com are built, correctly, for large organizations, and they price accordingly. Startups get by on free tiers. But the mid-sized company, the one that's outgrown "free" but doesn't need enterprise-grade workflow customization, gets squeezed. You're not paying for what you use, you're paying for the tier you happen to fall into. That gap widens fast. Jira's paid plans stay manageable until when your few engineers but then gradually increases as you hire more engineers and all of a sudden you are paying $1000 to $2000 in monthly invoice. The pricing can be justified if you are using all the features. But in most cases that's not so. 

This wasn't unique to my client. It was true of my own company. A round of calls to other founders confirmed it was true of theirs too, and the frustration wasn't confined to Jira. Monday.com carries the same bloat. Redmine is a credible open-source alternative and its robust, and worth setting up if you have the systems capacity to self-host it, but its interface hasn't aged well, and asking a team to adopt it is its own kind of tax. Despite 15+ years in this industry, I found its interface genuinely hard to navigate.

Validating the problem before building anything. Before writing a line of code, I did what I'd tell any engineer on my team to do: I validated the demand. I drew up the feature set I'd want as a Head of Engineering, the minimum that keeps a team productive without becoming a maintenance burden, and sent it to my network. Roughly 70% said they'd switch to a simpler alternative if one existed. The recurring caveat: migration had to be painless. Nobody was going to re-key months of backlog by hand.

That response rate is what turned this from a personal itch into a product decision.

The Design Principle: Subtraction, Not Addition

The goal wasn't to out-feature Jira. It was to build the smallest tool that still does the job and to make data migration a first-class feature, not an afterthought, so switching costs nothing.

I named it Dubuku — Tamil colloquial for "small, insignificant." The name is the thesis.

A few deliberate omissions and decisions:

• No custom workflows, custom fields, or custom statuses. Fixed fields, fixed statuses. Configurability is where most tools quietly become unmanageable.
• A dedicated bug view, separate from the general backlog, so defects don't get buried in a general issue list.
• Color-coded issue types — bugs in red, features in turquoise, epics in a lighter purple, for at-a-glance triage.
• Kanban by default, with a list view for anyone who prefers it. No forced methodology.
• Issues require project assignment before user assignment, you can't create orphaned work.
• Comments are permanent. No deletion. This was intentional: it keeps the full decision history of an issue intact, which matters more the longer a project runs.
• No mobile app. This is an internal engineering tool. Anyone using it is already at a computer, ready to work, a mobile app would be effort spent on a use case that doesn't exist.

The last point is worth generalizing: I built for the problems my team actually had, not the problems a "real" product might eventually have. Scale, extensibility, and mobile access were all explicitly out of scope. Solving for hypothetical future needs is how simple tools become the next bloated one.

From Idea to Production in Two Weeks

The stack decisions were made for speed, not novelty: Laravel (built on an existing starter kit with auth and user management already solved), MySQL, Memcached, and RabbitMQ for queuing, with workers running as systemd services. Vue.js handled the frontend, with Livewire for a few admin screens. None of this was a technology bet — it was the fastest path to something my team could use.

The first version, built in two weeks, was deliberately bare: create a project, assign users, create and assign issues, change status and priority, comment, reassign. A "take" button let developers self-assign unclaimed work. The UI was functional, responsive, and intentionally unpolished. I spent zero time on visual refinement I didn't need yet.

Migration was the part I took most seriously, because it was the part my survey respondents cared about most. Over a weekend at the end of a sprint, I cut developer access to Jira and ran a full migration through a purpose-built importer that parsed Jira's export schema and mapped it into Dubuku's tables. By Monday, the team was live on the new tool, with no training required, since everyone already knew the Jira mental model Dubuku had deliberately preserved.

The tell that mattered: the only feedback was about missing features — epics, linked issues, blocked issues — not confusion about how to use what was there. Adoption friction was zero. That was the actual goal: something even a new graduate could pick up without a walkthrough.

Scaling Development with Claude Code

Once the core was validated in production, I used Claude Code to accelerate the next phase rather than building it feature-by-feature myself. I gave it access to the Dubuku codebase, walked it through the product vision, and handed it a written spec with features like user tagging in comments, pinning for issues and projects, archiving, sprints, sprint task assignment, a manager-level dashboard, file attachments, email and push notifications, and two-factor authentication including hand-drawn UI references.

It completed the full set of requested features in about 15–20 minutes. My role shifted to review: reading the generated code, checking correctness, and making a handful of manual adjustments. The output held up well, Claude Code handled a nontrivial feature backlog competently and left me with review and deployment work rather than implementation work.

What I'd Tell Another CTO

The market doesn't need a better Jira. It needs an honest acknowledgment that most teams are paying for a ceiling they'll never hit. A feature set built for a company three times their size, priced the same way.

Dubuku isn't a Jira competitor. It's not trying to win on feature count, and it never will. It's a bet that "good enough, and ours" beats "excellent, and expensive" for a very specific band of company — the one that's outgrown free tiers but hasn't outgrown common sense.

I don't know if Dubuku stays internal forever, or if it becomes something I open up to other teams facing the same bill I once did. Either way, the exercise taught me something worth keeping: before you buy the bigger tool, ask what you're actually solving for. Sometimes the answer isn't more software. It's less.