Tools I Built Because the Others Got in the Way

Most project management tools don’t fail because they’re bad. They fail because they assume a world I don’t live in.

Big teams. Permanent roadmaps. Endless tickets. Meetings to manage the tool that’s meant to manage the work.

DevBoard started as a reaction to that. I wanted something closer to how I actually think and work. Something that sits quietly in the background, keeps me honest about what I’m doing, and doesn’t try to turn my attention into a revenue stream.

At its core, DevBoard is a lightweight project and task management system. Kanban-based, fast, opinionated in a few places, and deliberately boring everywhere else. It’s what Jira would look like if it had never met procurement, compliance, or quarterly upsell targets.

Each project lives as a real thing. It has tasks, but it also has context. A markdown README that explains why the project exists, what decisions were made, and what “done” actually means. Tasks support attachments, screenshots, notes, and just enough structure to stop things leaking out of my head. Projects can be nested, locked when finished, and exported when it’s time to move on.

The interface is dark and quiet by design. It’s meant for focus, not dopamine. There are no notifications begging for attention, no charts pretending activity equals progress. If I open it, it’s because I intend to do something.

Under the hood it’s deliberately simple. PHP and MySQL on the backend. Vanilla JavaScript on the front. Self-hosted. Fast. Predictable. Entirely under my control. No subscriptions. No tracking. No feature tiers. No dependency on someone else’s roadmap or pricing strategy.

There are automations and integrations where they genuinely save time. A bit of intelligence to reduce repetition and friction. Nothing loud. Nothing branded. Just small nudges that make the system feel alive rather than mechanical.

StudioBoard grew out of the same thinking, but aimed at a slightly different problem. Where DevBoard is about execution, StudioBoard is about shaping work before it becomes execution. Ideas, experiments, half-formed concepts, creative projects, and things that aren’t ready to be “managed” yet. It’s the space upstream of commitment, where thinking is still fluid and outcomes aren’t locked.

Together, they form a loop I actually trust. StudioBoard for exploration and sense-making. DevBoard for delivery. Both built around how I move between thinking and doing, rather than forcing me into a process diagram someone else designed.

I didn’t build these to sell them. I built them because I was tired of tools that felt heavier than the work they were meant to support. They’re a reminder that not every piece of software needs to be a product, and not every problem needs a platform.

Sometimes the most useful tools are the ones you build quietly, for yourself, shaped by your own friction points, and allowed to stay small, sharp, and honest.

And if they never grow beyond that, that’s fine. They already do exactly what I need them to do.