Lific

I think Lific is one of those ideas you can only have when you are genuinely annoyed by an existing solution you’ve used.

I recall sometime in April 2026 I was sitting in the dentists office waiting room on my phone working on a project via termux + OpenCode (Amazing combination by the way. Genuinely still shocked at how good of an experience it is for coding on your phone) And my issue tracker at the time was Plane, a self hostable Linear alternative. I had already migrated all of my issues from Linear about a month earlier because I was creating too many issues for their free tier across my different projects.

The problem came up when suddenly my home-lab that was hosting the Plane instance was starting to report it was out of memory. Keep in mind this is an old gaming computer rig that I had converted to a homelab, it had 64GB of DDR4 and there is no system I was running on there that I thought should be able to use a quarter of that.

It turns out that Plane had been secretly growing every time I was using it. Something in the MCP implementation + the stdio configuration had managed to spin up a python process every time I connected to the MCP and the process never closed. For the month and a half or so that I was using Plane, it had been having process leaks that were eating into my homelab’s memory. One of the downsides of having a beefy homelab is you don’t notice weird things eating your resources until it’s been going on for a while.

I already had my problems with Plane for my use case before I found this out, things like them spending 30k tokens on over 100 tools for their MCP. Genuinely way too many entities in their schema for you to give each entity full CRUD tools. That and the weight of just the actual running of plane was something like 12-17 docker containers? This MCP python process debacle was just the final straw for me.

And of course I want to clarify that there is no hate/disparaging Plane meant in this post. I do genuinely understand that my use case is different then what they are looking to support. They from what I understand are focused on larger teams using them over Linear or Jira, and that MCP in 2026 is still in it’s early integration phase in a lot of projects. I try my best not to be too hard on plane in official Lific statements on it’s website, but on a personal blog I want to clarify that this is just my personal experience. The reason why I was disappointed is purely because at the time I couldn’t find and optimized issue trackers that had a high quality web UI and MCP. Plane offered the features but not the optimization. Most of the existing single binary issue trackers offered the optimization but not the features.

And so sitting in that dentists office I decided I would make my own issue tracker. I didn’t know what stack yet, or what I would call it. But I knew that it was an opportunity to make a high quality tool that if nothing else, I would use.

And so that night Lific was born, a pun on the word “Prolific” and with a logo of a white snake on a green background. Originally the logo was going to be just a ‘wavy’ L shape. But while working on the design I remembered a video I had watched of a small white snake called ‘Tofu’ on Youtube Shorts who hated the Youtuber Markiplier and decided a cute white snake logo would be charming.

Traditionally I’m a C#, Python, Typescript guy. The options that were in front of me for a single binary distribution were none of those. It was:

• Rust
• Go
• Zig
• C++ arguably

The problem with all of these options is that they are outside of my wheelhouse with my object oriented and web dev experience. But I ended up choosing rust.

There were a few reasons I picked Rust.

• First it was the only language I had dabbled with before. I have a C# video game in development that does FFI (basically running code from outside the C# codebase) into some optimized Rust algorithms.
• It has a reputation as the “optimized, safe option” which is attractive to someone with an empty project.
• Cargo is genuinely a nice package setup and has a good flow of people looking through it.
• Many AI coding benchmarks list Rust as the best of the group for AI’s to code with thanks to the feedback loop from the compiler. C++ has the most training data of the group but agentic workflows benefit more from a harsh compiler than more examples

That last point is very important. Because Lific’s codebase is entirely delivered by AI coding agents. My job with this project was never to write code, It was to iterate on the design of the architecture, come up with and flesh out features, and have taste in the UI/UX of the entire Web surface.

It’s easy to have some imposter syndrome when you first start working like this, but genuinely: frontier coding models are just at that point now. They can code, audit, review, and do first passes at web ui. Trying to compete with them in those domains is genuinely inefficient if you have access to them. That’s not to say you shouldn’t know every nook and cranny of your project, and you shouldn’t be the final decision maker 99% of the time, because you definitely should know as much about your project’s architecture and algorithms as you would if you wrote it yourself. I spent just as much time asking agents to explain the codebase as I spent actually having agents implement.

2026 AI coding politics aside, it was very charming to dogfood Lific right away by creating the MCP in day 1 and having agents use Lific to track Lific’s development and feature ideas. As of writing, Lific’s project in my instance has about ~350 issues that have ever been tracked with about 275 of them labeled as complete. A few of the projects that I use Lific to track also have a couple hundred issues each, dozens of pages, and dozens of plans the agents use to share their implementation strategies between different sessions. It’s half of why im so confident in the quality of Lific is that it’s the first project that was from the ground up handled with heavy use of Lific. Meta, I know, but what I’m saying is that when the agents are encouraged to not just write, but go through a flow of detailed specs you can audit and rewrite, and then implement, all from your local issue tracker, it’s a whole different flow for large projects, especially if you’re a big user of sub agents who can just be told to look up a certain issue.

As of writing I just released Lific v2.3.0 and the project has just under 30 stars on GitHub. For people who work like me I think that Lific is going to be a big hit some time soon.

Thanks for reading!