Xiaofei's Yuanyang hotpot

第一次創業最貴的一課：太早 scale

Tue, 13 Oct 2026 00:00:00 GMT

第一次創業，拿到 seed 之後，我們就開始招人。engineer、designer、marketing、sales，一個一個補齊，公司從三、四個人，一路長到最多的時候二十來人，終於像一間公司了。

那幾年，公司的 vision 沒變過，產品倒是一直在改。2022 年底 ChatGPT 出來以後，整個市場都被 LLM 帶著走，外面的環境也跟著大變。

一切似乎都在變好。後來我才發現，人越多，我們跑得越慢。

能靠招人解決 Go-to-Market（GTM）嗎？

我是學術背景出身。為了 steer founder 的 vision，我當時在公司負責團隊管理和產品開發。

一開始，我們自己在賣，也真的拿到了客戶。於是開始找業務，想把它放大。

後來才發現，那是假的 PMF。有客戶，不代表有 PMF。真正的 PMF，是你感受到市場推著你往前走：客戶追著你，新的需求也追著你。我們當時沒有這種感覺。

過早地以為自己找到了 PMF，比沒有 PMF 更危險。

第一位業務沒有跑通。我們當時的分析是：早期新創沒有 playbook，環境一直在變，業務得從零開發陌生客戶，而我們做的又是 AI infra，產品本身就很難講清楚。

後來我們試了別的路。請一位 Chief Commercial Officer（CCO），希望用更高的視野和策略，補上執行面的僵化和主動性。同一時期，我們也找了 Developer Relations（DevRel）經營社群，想解決產品的 distribution channel。總之，就是想靠招進不同角色，各管一塊、各有 KPI，多位一體地解決產品的 GTM。

為什麼人越多，跑得越慢？

現在回頭看，問題從來不在找進來的人身上，而在「多位一體」這個策略本身。對早期新創來說，它非常危險，因為 founder 會把大量精力放在招募和團隊建設上。

你可能會問，這有什麼錯？

想像你開著一輛拼裝車，路很顛簸，車上的人快被甩出去。於是你一手掌舵，一手攏住大家。

早期新創就是有這麼一段很 ugly 的階段：邊修，邊往前跑。車上的人越多，出狀況的地方就越多，你的注意力也越容易被拉到這些問題上：

「我精力不夠了，要不要找個更勝任的人來分擔？」

「我要怎麼優化我的團隊？」

然後就陷入惡性循環：多位，卻不一體。每個角色朝不同方向用力，互相拉扯，更糟的是原地空轉。

早期新創最怕的，是內耗。這裡說的內耗，不是人和人處不來，而是角色切得太早。每多切出一個角色，就多一條要對齊的線，溝通成本和管理成本一層一層往上疊。最後拖垮的，是新創唯一的優勢：快速迭代。

我們低估的，正是這種成本：對齊、招募、one-on-one、解釋方向，這些時間本來應該花在客戶和產品身上。人變多了，founder 的執行力反而變弱。

PMF 之前，公司只有一件事要做：搞清楚誰是客戶、他到底要什麼、為什麼願意付錢。每多一個人，founder 的 focus 就被稀釋一點。

這不只是我們的問題。2011 年 Startup Genome 的報告指出，74% 的高成長網路新創，死於過早擴張。YC 合夥人 Pete Koomen 在 Startup School 也講過：PMF 之前的銷售，本質上是創業，需要願景、客戶的信任、大量實驗，還要跟做產品的人緊密回饋。這是 founder 的工作，還不能交給別人。

我們後來怎麼補救

認識到這一點後，我們有意識地精簡團隊，安頓好員工，重新聚焦。

我明顯感受到，掌控感回來了。

這是痛苦而正確的決定，但一擴一縮之間，公司還是付出了代價，最貴的是時間。

回頭看，這幾乎是早期摸索繞不開的一段路。沒有人一開始就知道答案，重要的是發現走偏的時候，能不能及時承認、及時調整。

對抗自己的本能

心理學家 Jonathan Haidt 有個比喻：我們以為自己是騎在大象上、決定方向的那個人。其實更多時候，是大象（直覺）先轉了彎，騎象人（理性）才回頭解釋為什麼要往這邊走。

而且這不是某一刻的決定，是一道滑坡，是溫水煮青蛙。每一步都說得通，每一步都讓你更靠近舒適圈一點。最迷惑的是，從表面來看，大家都在忙碌，你安慰自己，事情總有起起伏伏。實際上，你的體感已經無法反映真實的狀況。等回過頭來，才發現自己已經離 founder 真正該做的事很遠了，focus 也散了。

「我的時間應該花在我擅長的事情上。」這句話沒有錯，但在新創初期，它是反直覺的。Founder 要有意識地保護自己的 focus、注意力和執行力，即使這個過程讓你不舒服：把擅長的事情自動化，再把時間花在不擅長的事情上。

招人並不會彌補短板。因為 founder 的短板，就是公司的短板。

We stopped paying for Linear

Mon, 17 Aug 2026 00:00:00 GMT

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.

<div class="figure-row"><figure><img src="/media/kairo-shadow.webp" alt="A dim room in the film Kairo; on the wall, a dark human-shaped stain where a person used to be" width="1080" height="590"><figcaption>When someone dies in <em>Kairo</em>, they do not vanish — a charcoal stain in their shape stays on the wall of the room (回路, 2001, dir. Kiyoshi Kurosawa)</figcaption></figure><figure><img src="/media/kairo-door.webp" alt="A doorway sealed with red tape in the film Kairo, seen across an empty gravel yard" width="1080" height="573"><figcaption>The rooms the ghosts came through get sealed with red tape; the film keeps finding the tape, and it keeps not being enough</figcaption></figure></div>

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

<figure><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 700" role="img" aria-label="Three places to keep the tickets: an agent-maintained markdown board that only grows, GitHub issues where state is a field, and a project management SaaS that pays in UI" style="max-width:100%;height:auto;display:block"><rect width="1200" height="700" rx="14" fill="var(--code-bg)"/><text x="64" y="96" style="font-family:var(--font-sans);font-size:38px;font-weight:600;letter-spacing:-.5px" fill="var(--fg)">Where do the tickets live?</text><text x="65" y="132" style="font-family:var(--font-sans);font-size:22px" fill="var(--fg-muted)">The same job, three homes. Only one of them has a machine-readable lifecycle.</text><rect x="64" y="180" width="330" height="380" rx="14" fill="var(--bg)" stroke="var(--rule-strong)" stroke-opacity=".45" stroke-width="1.5"/><clipPath id="c1"><rect x="64" y="180" width="330" height="380" rx="14"/></clipPath><g clip-path="url(#c1)"><rect x="104" y="216" width="176" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="243" width="196" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="270" width="150" height="13" rx="6" fill="var(--accent)" opacity="0.18"/><line x1="104" y1="276.5" x2="254" y2="276.5" stroke="var(--accent)" stroke-width="2.5" opacity=".85"/><rect x="104" y="297" width="188" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="324" width="214" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="351" width="164" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="378" width="196" height="13" rx="6" fill="var(--accent)" opacity="0.18"/><line x1="104" y1="384.5" x2="300" y2="384.5" stroke="var(--accent)" stroke-width="2.5" opacity=".85"/><rect x="104" y="405" width="154" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="432" width="182" height="13" rx="6" fill="var(--accent)" opacity="0.4"/><rect x="104" y="459" width="200" height="13" rx="6" fill="var(--accent)" opacity="0.28"/><rect x="104" y="486" width="170" height="13" rx="6" fill="var(--accent)" opacity="0.22"/><rect x="104" y="513" width="190" height="13" rx="6" fill="var(--accent)" opacity="0.16"/><rect x="104" y="540" width="160" height="13" rx="6" fill="var(--accent)" opacity="0.1"/></g><text x="229.0" y="542" text-anchor="middle" style="font-family:var(--font-sans);font-size:23px;font-weight:600" fill="var(--fg)">Agent-run markdown</text><text x="229.0" y="594" text-anchor="middle" style="font-family:var(--font-mono);font-size:19px" fill="var(--fg)">the file only grows</text><rect x="435" y="180" width="330" height="380" rx="14" fill="var(--bg)" stroke="var(--accent)" stroke-width="2.5"/><circle cx="487" cy="228" r="9" fill="var(--accent)"/><rect x="509" y="222" width="150" height="13" rx="6" fill="var(--accent)" opacity=".42"/><circle cx="487" cy="262" r="9" fill="var(--accent)"/><rect x="509" y="256" width="196" height="13" rx="6" fill="var(--accent)" opacity=".42"/><circle cx="487" cy="296" r="9" fill="var(--accent)"/><rect x="509" y="290" width="172" height="13" rx="6" fill="var(--accent)" opacity=".42"/><circle cx="487" cy="330" r="9" fill="var(--accent)"/><rect x="509" y="324" width="188" height="13" rx="6" fill="var(--accent)" opacity=".42"/><line x1="469" y1="364" x2="731" y2="364" stroke="var(--rule-strong)" stroke-width="1.5" stroke-dasharray="5 5" opacity=".6"/><text x="731" y="356" text-anchor="end" style="font-family:var(--font-mono);font-size:16px" fill="var(--fg)">the view</text><circle cx="487" cy="392" r="8" fill="none" stroke="var(--fg-faint)" stroke-width="2" opacity=".7"/><rect x="509" y="386" width="180" height="13" rx="6" fill="var(--fg-faint)" opacity=".28"/><circle cx="487" cy="423" r="8" fill="none" stroke="var(--fg-faint)" stroke-width="2" opacity=".7"/><rect x="509" y="417" width="150" height="13" rx="6" fill="var(--fg-faint)" opacity=".28"/><circle cx="487" cy="454" r="8" fill="none" stroke="var(--fg-faint)" stroke-width="2" opacity=".7"/><rect x="509" y="448" width="190" height="13" rx="6" fill="var(--fg-faint)" opacity=".28"/><text x="600.0" y="542" text-anchor="middle" style="font-family:var(--font-sans);font-size:23px;font-weight:600" fill="var(--accent)">GitHub issues</text><text x="600.0" y="594" text-anchor="middle" style="font-family:var(--font-mono);font-size:19px" fill="var(--fg)">closed leaves the view</text><rect x="806" y="180" width="330" height="380" rx="14" fill="var(--bg)" stroke="var(--rule-strong)" stroke-opacity=".45" stroke-width="1.5"/><rect x="844" y="218" width="254" height="240" rx="10" fill="none" stroke="var(--fg-muted)" stroke-width="1.6" opacity=".75"/><line x1="844" y1="252" x2="1098" y2="252" stroke="var(--fg-muted)" stroke-width="1.2" opacity=".55"/><circle cx="864" cy="235" r="4.5" fill="var(--fg-muted)" opacity=".6"/><circle cx="880" cy="235" r="4.5" fill="var(--fg-muted)" opacity=".6"/><circle cx="896" cy="235" r="4.5" fill="var(--fg-muted)" opacity=".6"/><rect x="1020" y="226" width="64" height="18" rx="9" fill="var(--accent)" opacity=".16"/><text x="1052" y="239.5" text-anchor="middle" style="font-family:var(--font-mono);font-size:13px;font-weight:600" fill="var(--accent)">$ /seat</text><rect x="862.0" y="266" width="37.61333333333333" height="9" rx="4.5" fill="var(--fg-muted)" opacity=".55"/><rect x="862.0" y="288" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="870.0" y="298" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="862.0" y="332" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="870.0" y="342" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="862.0" y="376" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="870.0" y="386" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="940.6666666666666" y="266" width="37.61333333333333" height="9" rx="4.5" fill="var(--fg-muted)" opacity=".55"/><rect x="940.6666666666666" y="288" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="948.6666666666666" y="298" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="940.6666666666666" y="332" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="948.6666666666666" y="342" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="1019.3333333333333" y="266" width="37.61333333333333" height="9" rx="4.5" fill="var(--fg-muted)" opacity=".55"/><rect x="1019.3333333333333" y="288" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="1027.3333333333333" y="298" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="1019.3333333333333" y="332" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="1027.3333333333333" y="342" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><rect x="1019.3333333333333" y="376" width="60.666666666666664" height="34" rx="6" fill="none" stroke="var(--fg-muted)" stroke-width="1.3" opacity=".55"/><rect x="1027.3333333333333" y="386" width="30.666666666666664" height="7" rx="3.5" fill="var(--fg-muted)" opacity=".4"/><text x="971.0" y="542" text-anchor="middle" style="font-family:var(--font-sans);font-size:23px;font-weight:600" fill="var(--fg)">The PM SaaS</text><text x="971.0" y="594" text-anchor="middle" style="font-family:var(--font-mono);font-size:19px" fill="var(--fg)">pays in UI you no longer visit</text></svg><figcaption>Three homes for the same tickets; we ended up in the middle one</figcaption></figure>

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

But, this time we chose GitHub issues. <span lang="zh-Hant">返璞歸真</span> — 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.

<figure><a href="/media/board-full.mp4" target="_blank" rel="noopener" title="Open the full-resolution recording"><video autoplay loop muted playsinline width="1104" height="689" poster="/media/board-poster.jpg"><source src="/media/board.webm" type="video/webm"><source src="/media/board.mp4" type="video/mp4"></video></a><figcaption>Our own board for Pingbo, regenerated from GitHub issues — watch it jump into the GitHub Project that automates the lifecycle</figcaption></figure>

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?

<figure><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 600" role="img" aria-label="What the subscription was paying for: before agents, the UI made everyone the same shape; with agents everyone contributes and reads in their own shape, and the agent is the interface" style="max-width:100%;height:auto;display:block"><rect width="1200" height="600" rx="14" fill="var(--code-bg)"/><text x="64" y="92" style="font-family:var(--font-sans);font-size:38px;font-weight:600;letter-spacing:-.5px" fill="var(--fg)">What the subscription was paying for</text><text x="65" y="128" style="font-family:var(--font-sans);font-size:22px" fill="var(--fg-muted)">The UI existed to absorb the difference in how each person works. Now something else absorbs it.</text><rect x="64" y="170" width="520" height="360" rx="14" fill="var(--bg)" stroke="var(--rule-strong)" stroke-opacity=".45" stroke-width="1.5"/><text x="94" y="212" style="font-family:var(--font-mono);font-size:17px;letter-spacing:2px" fill="var(--fg)">BEFORE</text><circle cx="134" cy="278" r="13" fill="var(--fg-muted)" opacity=".85"/><path d="M134 337 L146.35 359.75 L121.65 359.75 Z" fill="var(--fg-muted)" opacity=".85"/><rect x="122.3" y="410.3" width="23.400000000000002" height="23.400000000000002" rx="4" fill="var(--fg-muted)" opacity=".85"/><rect x="252" y="242" width="92" height="226" rx="12" fill="var(--accent)" opacity=".14"/><rect x="252" y="242" width="92" height="226" rx="12" fill="none" stroke="var(--accent)" stroke-width="2"/><text x="298" y="362" text-anchor="middle" style="font-family:var(--font-sans);font-size:19px;font-weight:600" fill="var(--accent)">the UI</text><line x1="160" y1="278" x2="244" y2="278" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="278" x2="235.86335072184644" y2="281.8464189221045" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="278" x2="235.86335072184644" y2="274.1535810778955" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="344" y1="278" x2="402" y2="278" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="278" x2="393.8633507218465" y2="281.8464189221045" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="278" x2="393.8633507218465" y2="274.1535810778955" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><rect x="410" y="267" width="22" height="22" rx="5" fill="var(--accent)" opacity=".55"/><line x1="160" y1="350" x2="244" y2="350" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="350" x2="235.86335072184644" y2="353.8464189221045" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="350" x2="235.86335072184644" y2="346.1535810778955" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="344" y1="350" x2="402" y2="350" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="350" x2="393.8633507218465" y2="353.8464189221045" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="350" x2="393.8633507218465" y2="346.1535810778955" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><rect x="410" y="339" width="22" height="22" rx="5" fill="var(--accent)" opacity=".55"/><line x1="160" y1="422" x2="244" y2="422" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="422" x2="235.86335072184644" y2="425.8464189221045" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="244" y1="422" x2="235.86335072184644" y2="418.1535810778955" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="344" y1="422" x2="402" y2="422" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="422" x2="393.8633507218465" y2="425.8464189221045" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><line x1="402" y1="422" x2="393.8633507218465" y2="418.1535810778955" stroke="var(--accent)" stroke-width="1.8" opacity=".7"/><rect x="410" y="411" width="22" height="22" rx="5" fill="var(--accent)" opacity=".55"/><text x="324.0" y="564" text-anchor="middle" style="font-family:var(--font-mono);font-size:19px" fill="var(--fg)">everyone comes out the same shape</text><rect x="616" y="170" width="520" height="360" rx="14" fill="var(--bg)" stroke="var(--rule-strong)" stroke-opacity=".45" stroke-width="1.5"/><text x="646" y="212" style="font-family:var(--font-mono);font-size:17px;letter-spacing:2px" fill="var(--fg)">WITH AGENTS</text><circle cx="680" cy="278" r="13" fill="var(--fg-muted)" opacity=".85"/><path d="M680 337 L692.35 359.75 L667.65 359.75 Z" fill="var(--fg-muted)" opacity=".85"/><rect x="668.3" y="410.3" width="23.400000000000002" height="23.400000000000002" rx="4" fill="var(--fg-muted)" opacity=".85"/><path d="M878 320 C884.6 343.4 884.6 343.4 908 350 C884.6 356.6 884.6 356.6 878 380 C871.4 356.6 871.4 356.6 848 350 C871.4 343.4 871.4 343.4 878 320 Z" fill="var(--accent)"/><path d="M901.4 324.2 C903.5 331.4 903.5 331.4 911.0 333.8 C903.5 336.2 903.5 336.2 901.4 343.4 C899.3 336.2 899.3 336.2 891.8 333.8 C899.3 331.4 899.3 331.4 901.4 324.2 Z" fill="var(--accent)" opacity=".6"/><text x="878" y="452" text-anchor="middle" style="font-family:var(--font-sans);font-size:15px;font-weight:600" fill="var(--accent)">the agent is the interface</text><line x1="712" y1="271" x2="836" y2="326.16" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="326.16" x2="827.0023885033015" y2="326.36733392023507" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="326.16" x2="830.1290597919225" y2="319.33855872464045" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="336.4" x2="716" y2="287" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="287" x2="724.9882661562757" y2="286.54057481136783" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="287" x2="722.0598159669281" y2="293.65421899601773" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><circle cx="776.0" cy="313.7" r="8" fill="var(--accent)" opacity=".9"/><line x1="712" y1="343" x2="836" y2="342.0" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="342.0" x2="827.8946337969994" y2="345.9119098552057" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="342.0" x2="827.832596799426" y2="338.21932215611344" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="358.0" x2="716" y2="359" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="359" x2="724.104314392216" y2="355.0859115707331" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="359" x2="724.1684191484301" y2="362.7784823164282" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><path d="M776.0 352.5 L783.6 366.5 L768.4 366.5 Z" fill="var(--accent)" opacity=".9"/><line x1="712" y1="415" x2="836" y2="357.84" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="357.84" x2="830.2208787490229" y2="364.7394026963574" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="357.84" x2="827.000419523703" y2="357.75310206760213" stroke="var(--fg-muted)" stroke-width="1.8" opacity=".55"/><line x1="836" y1="379.6" x2="716" y2="431" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="431" x2="721.9649379651968" y2="424.2605997988431" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><line x1="716" y1="431" x2="724.9938727748319" y2="431.33204293417793" stroke="var(--accent)" stroke-width="1.8" opacity=".75"/><rect x="768.8" y="400.1" width="14.4" height="14.4" rx="4" fill="var(--accent)" opacity=".9"/><line x1="918" y1="344" x2="958" y2="344" stroke="var(--accent)" stroke-width="1.8" opacity=".85"/><line x1="958" y1="344" x2="949.8633507218465" y2="347.8464189221045" stroke="var(--accent)" stroke-width="1.8" opacity=".85"/><line x1="958" y1="344" x2="949.8633507218465" y2="340.1535810778955" stroke="var(--accent)" stroke-width="1.8" opacity=".85"/><line x1="958" y1="358" x2="922" y2="358" stroke="var(--accent)" stroke-width="1.8" opacity=".45"/><line x1="922" y1="358" x2="930.1366492781535" y2="354.1535810778955" stroke="var(--accent)" stroke-width="1.8" opacity=".45"/><line x1="922" y1="358" x2="930.1366492781535" y2="361.8464189221045" stroke="var(--accent)" stroke-width="1.8" opacity=".45"/><rect x="968" y="298" width="104" height="104" rx="10" fill="none" stroke="var(--accent)" stroke-width="2"/><circle cx="986" cy="318" r="5" fill="var(--accent)" opacity="1"/><rect x="999" y="313.5" width="56" height="9" rx="4.5" fill="var(--accent)" opacity="0.42"/><circle cx="986" cy="348" r="5" fill="var(--accent)" opacity="1"/><rect x="999" y="343.5" width="42" height="9" rx="4.5" fill="var(--accent)" opacity="0.42"/><circle cx="986" cy="378" r="5" fill="var(--accent)" opacity="0"/><circle cx="986" cy="378" r="4.5" fill="none" stroke="var(--fg-muted)" stroke-width="1.6"/><rect x="999" y="373.5" width="50" height="9" rx="4.5" fill="var(--accent)" opacity="0.2"/><text x="1020" y="426" text-anchor="middle" style="font-family:var(--font-mono);font-size:17px" fill="var(--fg)">issues</text><text x="876.0" y="564" text-anchor="middle" style="font-family:var(--font-mono);font-size:19px" fill="var(--fg)">everyone contributes — and reads — in their own shape</text></svg><figcaption>The UI's job moved to the agent, and the reason to pay moved with it</figcaption></figure>

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.