We stopped paying for Linear

In the last two months, me and my friend Pinglin have been building an interesting project, Pingbo, together, and we have iterated our way into one setup for project management. The road there was longer: a ten-person team on the sleekest SaaS, then a two-person board run entirely by an agent. We dropped both, for very different reasons, and ended up on plain GitHub issues. I think that is where this is all going.

I used to love Linear, but it is not perfect

I am a fan of Linear. We ditched ClickUp for it without a doubt back in 2023.

Compared to Linear, ClickUp immediately felt like a clumsy all-in-one platform that tries to do everything and excels at nothing. Linear is a winner that suits my tastes better, elegant and focused. As a product, it is sleek, it is professional, the UI/UX is phenomenal. It holds high standards when delivering a feature, which I appreciate A LOT. I love products that do less but better.

But this does not mean that it is all a fairy tale when using it. Our team had grown to 10-ish, with one PM, one designer, and the rest engineers. I was overseeing the project development.

We constantly encountered issues: an ever-growing, overblown, outdated backlog; sprints stuffed with more tickets than they could ever finish. Fail enough of them in a row, and the sprint stops meaning anything. Of course, you can say: the tool is not the problem, the way you use it is. Set strict team rules, keep the dashboard clean, and the problem goes away.

But I just don’t think it is that simple. We definitely tried. We defined the full workflow: what labels to use, who should do what after what has finished, setting up every automation we could to cover for human forgetfulness. Constantly reminding the team to follow the rules. No matter how smooth Linear is, none of it held, because the problem is not the rules. Everyone works differently. These tools create a unified platform for everyone to work on, but that does not mean co-working is solved. You can FORCE a unified way for a team to work together, but that demands adjustment, or sacrifice, that bends how each person usually works.

I still remember being stressed, sending messages to our PM complaining: what is the actual status of the project, are we going to finish all the planned features in the sprints? She was also frustrated, because she couldn’t understand why I needed her constant updates, why I couldn’t just read her daily report and go to the dashboard to see for myself.

To make the communication smooth — funny, the word, smooth — we agreed on how the daily report should look, what it should include and what it should not.

Looking back, it is funny to think that we did EXTRA paperwork, designed our workflow around whatever tool we used, and called it smooth communication. Then the rules on the wall slowly got ignored, the docs went stale, and over time it all decayed into a chaotic, outdated junkyard — the paperwork we invented to manage the project became the thing nobody managed. It was not pleasant for either of us. Our PM spent more time managing my expectations; I spent more time trying to feel more in control.

That was my compromise. I started to accept that modern project management is a mess, inevitably. Like, what can you do?

Then, the agent era comes. Things have changed.

Our team stepped into the vibe coding period. Everyone was anxious, doubting, resisting and excited at the same time. More code was produced, so features were expected to iterate and launch faster. At the same time, the market changed daily; we needed to pivot, and we had to cut the team size down. All of it added to the chaos of project management. As a coder and manager, I lived in uncertainty.

We opened the Linear UI less and less; we managed via Linear MCP. I just asked the AI agent to summarize the status. I didn’t need to — or WANT to — go somewhere, click a button, or ask a person in the team, back and forth, to get what I wanted. I would honestly say that the things I used to appreciate — the good UI, the well-built workflow and automations — do not matter that much anymore.

So, I outsourced everything in PM to the agent. Turns out not the best idea

Unfortunately, our product did not work out. It is a long story that I may tell another day, another time. Fast-forward to now: me and Pinglin are building Pingbo together.

OK, a super tiny team still needs project management. I would say even a one-person army still needs project management. Things can get out of hand very quickly when the scope or the details keep changing.

What tool should we use? After everything the ten-ish team had taught us, we dropped Linear first. The price was not even the main reason: if sleek UI/UX does not matter anymore, I just need a place to manage tickets, that’s all.

Then we took it a step further. Since we had become so used to vibe coding, I suggested: why don’t we just use an agent purely for management? I vibed a simple ticket board and hosted it on a page via Cloudflare. We could just go there and eyeball all the tickets; it even had a Gantt chart. We even had an agent routinely check the status every day — if anything was outdated, the agent could send a PR to fix it.

We ran it while rapidly developing the project.

The residue

I don’t know if you have ever watched a Japanese horror movie called 回路 Kairo. When people die, they leave a charcoal-stained residue on the wall, in the room.

At first, the board worked fine. Then our project’s dead specs started doing what the dead in Kairo do: they left a residue. We had defined team rules again, this time for the agent, and written skills to keep the specs, the tickets and the board up to date. It happened anyway. Outdated docs and tickets got left behind every time we updated the specs, and the agent kept building on them. Slowly, the old discussions crawled back.

Initially we hoped that the daily agent board correction could be helpful. But it slowly became an empty ritual. I merged the board correction PR without even reviewing it, because I simply did not have the time to read through the growing markdown docs and html. It became like we were maintaining and updating the board for the sake of management.

PM is semi-structured work: it holds your thoughts about the project, and it needs to constantly evolve, so it needs lifecycle and workflow. If you let an agent manage all of it via markdown and html, it does well on the unstructured part — every thought you went through, every detail you pinned down, the reasons behind them and how they evolved — but it lacks the structure. The boundary of things is loose, and when you update, reject ideas, or change specs, it gets lost in the details. Your board becomes a hoarder’s house.

It took me longer to see that the hoarder’s house was not the biggest problem. The mess actively misleads; it does not just sit there being untidy.

When an agent reads the board, everything in the file arrives with the same standing. There is no field marking one paragraph current and another historical — the model has to infer that from the prose, and prose does not reliably carry it. In a tracker, being current is a property. In a document, being current is a claim the reader has to evaluate.

So when we changed a spec or reversed a decision, the old one did not go anywhere. It stayed in the plan that proposed it, in the other specs that referenced it, in the ticket text written around it. We even stamped the docs with statuses and update times, and left notes saying the old references were historical, not current. But a stamp is one line, and the doc under it is two thousand. Every sentence of a spec claims, just by its grammar, that it is true right now; the one line saying otherwise is outvoted by the body it sits on. Nothing tells the model which sentence is newer, so it weighs what it sees: which version is mentioned more, which sits closer to the end, which sounds more certain. Sometimes the new decision wins. Often the old one does, because the old one was discussed longer and left more supporting text behind it. Being current is just one signal among many, and often not the loudest.

And the stamps themselves decayed. Changing the content and updating the stamp are two actions, and the second is something an agent has to remember while holding ten other things in context. It drops it, not often, just sometimes. Then the shape drifts: updated becomes last_updated, 2026-08-17 becomes Aug 17, because nothing constrains it. A query over the stamps does not throw when this happens. It just returns fewer results.

That is what the residue does. It is not noise. It votes.

So after several weeks, we gave up on the idea. As the project grew bigger and the specs iterated fast, the self-built, self-hosted board was slowing us down and causing confusion. We needed a proper tool.

GitHub issues are enough in the agent era

Years ago we had left GitHub issues for Linear, and never looked back at what we left.

But, this time we chose GitHub issues. 返璞歸真 — back to the plain thing. It wins in so many ways.

First, if you use GitHub for code, you get issues and projects for free — and they link to pull requests, so closing the work closes the ticket. The code and the management live in the same place. One less tool to deal with, one less subscription. The same layer ships with GitLab, by the way; our code just lives on GitHub.

Second, these features provide the basic lifecycle and workflow that an agent needs for project management. Yes, the agent. The era of humans directly managing projects is over; GitHub issues and projects hand the agent the APIs to run it. A thin layer is exactly what an agent needs.

Third, the lack of fancy UI is not a disadvantage anymore. Well, just for being fancy, I vibed a project board that better matches mine and Pinglin’s taste and habits. It renders itself straight from the GitHub API every couple of hours, nothing on it hand-maintained, so we have the best of both worlds. To be clear, the board is not necessary at all. It is taste — a treat we made for ourselves, so everyday work feels good. The mechanics live in the issues; the taste lives in our board. And when the taste changes, we throw the board away and vibe a new one. The state underneath does not move.

We have run with this for several weeks, and are genuinely happier with this setup.

Not because issues cannot rot. An issue can go stale — nobody touches it for six months and it rots, the same as any list anywhere. The difference is that here you can find it. An issue carries its whole lifecycle as data: when it was opened, touched, closed, by whom, and what state it sits in. So “every open issue untouched in ninety days” is a query, and an agent can run it and close or revise what comes back. A line in a markdown file has no time of its own.

That lifecycle cannot decay the way our stamps did. GitHub writes updated_at as a side effect of the change: there is no second action to remember, no shape to drift, no way for it to be wrong. That is the whole difference. Not what the format can represent, but who guarantees it. We had written skills to keep the board current, and the skills were advice. The tracker’s fields are not advice.

The residue is a separate thing again. In markdown, changing your mind is an edit: you either delete the old decision and lose the reason for it, or you strike it through and leave it sitting in the context. Either way the file only grows. Closing an issue rewrites nothing — the dead thing leaves the default view without anyone remembering to remove it, and it is still there when you go looking for why.

The review ritual from the board era simply disappeared. Not because we became more disciplined: there is nothing left to review. An issue opened or closed notifies us by itself. A markdown diff was prose with no shape, and reading it cost more than it returned. A state change is one fact, and the fact comes to us.

Opening an issue mid-implementation is cheap too, and not because there is no lookup — there is. The agent still checks whether something similar is already open. The difference is where the filtering happens. Against a markdown board, “is this a duplicate?” means loading the whole file and letting the model do the filtering in its own attention: two hundred tickets go into the context so that one of them can be compared. Against the API it is a search that comes back with three, and the other one hundred and ninety-seven never cost anything. The operations are typed, too — search, create, close — so the agent never has to decide how to write the change, only what it is.

Remember the daily report our PM and I fought over? We still get one every morning — the agent writes it now, shaped the way we want. But the negotiation is gone. When I want to know something about the project, I no longer go through another person. I just ask the agent, and so does Pinglin, each in our own way.

Is project management SaaS dead?

A PM tool is a productivity tool, after all. The deal it offered was this: everyone bends to the one workflow the tool defines, and in exchange the UI makes the bending painless. That is why teams shopped on UI polish. The polish was the compensation. Agents break the deal from the other side: nobody has to bend anymore. Each of us works the way we feel most comfortable, and the friction between those ways, the communication bumps, the syncing, the back and forth, all gets ground away by the agent plus basic issue management.

This made me think: in this era, what is the true value of a PM SaaS tool? I know that Linear has built more features, even shipped fancy agents that triage your issues and write your code. That is not catching up — it is a pivot: a bet that the thing worth paying for becomes managing agents, not people. Even Linear themselves now say “issue tracking is dead”. Maybe they are right. But it is a different product than the one we left.

There is a line in that essay I love:

Overhead kept growing, and the process became the work.

That was exactly my life back then. The funny thing is, the same essay says Linear was always built on the opposite belief: remove the overhead, let teams focus on building. I believe they meant it. Their product is the best in class, and I felt that pain anyway. If the best product in the category could not remove the overhead, the problem was never the product. It was the category.

And look at where their roadmap points: code review, coding sessions — straight into territory where Claude Code and Codex already sit, powered by the same frontier models Linear has to rent. Their edge is supposed to be context. But the context a PM tool holds is secondhand: statuses, priorities, conversations about the work. The ground truth is the code. Roadmaps, progress, docs are all projections of the repo now, and an agent can regenerate a projection whenever it goes stale. There is no moat in a layer your customers can derive, and not much point in managing one by hand either. Context grows where the work happens.

In our case, the context lives in the repo. The agent became the interface. We stopped visiting Linear’s UI and talked to it through MCP. Then we stopped paying for Linear and kept only the thin free layer underneath — the issues and projects API. Everything the subscription used to sell — the overview, the reminders, the coordination, even the pretty board — the agent now does, on top of a commodity. The SaaS didn’t lose to a better SaaS. It got eaten from above.

I personally feel pessimistic about project management SaaS tools. In a small team, I no longer see the point. To be fair: we are two engineers who live in the terminal, and between the two of us, we are also the entire management chain. Nobody to report up to, no compliance review, no teammate who never touches code. I have not run this in a fifty-person org — maybe the SaaS still earns its seat there. But we are not engineers dodging the management work; we own it, and delivery is on us. After watching what the agent ate in our tiny team, I would not bet on it.