How I use linear as a solo founder

Accessing external systems is extremely powerful for agents. This article is not about using MCP over CLIs or any other data access protocol, but rather focuses on the specific tool I use for Linear.

When I first started building Cobalt, I thought I needed a project management tool. I set up a number of tickets, but I never actually updated them. Since I was the only one building, I was always aware of what needed to get done. Adding a ticket and updating progress slowed me down, so I didn't really use it for the first few months.

A few months in, I started rewriting many of the systems I had built to improve them. The problem is that these systems hinge on other moving parts of the codebase, so switching implementations often introduces small bugs. With things changing so frequently, I kept forgetting why we made a particular change and how far its scope reached. When did this change happen? What other options did we consider?

At first, we tried documenting these decisions in code comments. It didn't scale. Comments piled up, agents would casually delete pre-existing ones, and the only real history lived in git, which wasn't reliable if you changed the same thing several times in a single session without committing in between. Sprinkling markdown files around the codebase was even worse. Multiple files would end up describing the same decision, and the whole setup felt unhygienic.

I don't remember exactly how I landed on Linear for this. I think I was just trying something. But I started tracking feature progress, tickets, and contingencies there, using the Linear MCP. The agent wrote the tickets and their descriptions, and linked the relevant GitHub issues. That turned out to be very useful for tracking decisions.

This worked great for broken packages and stuff that we had to patch ourselves. We would document this with a reference to the actual GitHub issue and source code links.

One example was when the team chose the right agent architecture for sandboxes. We were looking at Vercel Sandbox, Daytona, and Cloudflare. We would consider each of these, implement the solutions, track how we felt about each, and perform a comparison analysis for our use case. If we ran into bugs, I would say something like, "We had a Linear ticket about sandboxes. Can you look at the recent changes to the package and update if it's still relevant?" This approach worked incredibly well.

I still review all the tickets. I don't close tickets and make them do tickets in the background or something. I still fire off tasks myself. But it is my favorite way to document progress and decisions. Having a state layer for your agents is super important. Almost every new coding thread begins with pulling the Linear ticket and explaining the feature's scope. I even spec features out. I'll have dedicated threads and worktrees for creating a Linear ticket. If I want to add a new feature, I will analyze the trade-offs and required changes and just hold the plan on the Linear ticket. Almost like storing agent "plans" for future use.

This is essential to my workflow. With faster shipment cycles, I tend to forget the exact reasons for everything.

We also use it for packages. When we were building our auth, the better auth api did not support verifying multiple Google client IDs. This was a blocker for anyone who wanted to set up mobile and web auth through Google. This was unresolved for about 2 months. We built our own internal patch but didn't want to cut corners on something as mission-critical as auth. So we set up a Claude background job that would have an AI agent track the GitHub issue and update us.

We're using git history a lot more now. Pulling up source code at different states and the actual technical details of implementations were also important. One example is our architecture for webhooks. To keep our users' financial information up to date, we needed to listen for webhook events from 3rd-party services such as Plaid and Snaptrade. Initially, the logic was very simple. Just update the DB whenever we get updates. But when we integrated Strike, it would bring more complexity. Cobalt uses a freemium pricing model: the first 2 institutions the user connects to are free, and everything after that is paywalled. An edge case we ran into is for a user who bought the paid plan, connected 6 of their accounts, and then downgraded. So they're essentially working around the paywall just by paying once a month. We needed to set up logic in our webhooks where we wouldn't sync their x oldest accounts if they don't have a subscription. We needed to test this logic thoroughly, implement retry logic, and ensure our actions were idempotent. So, we switched to Vercel’s Workflows product. When we initially migrated, we saw many 404 errors in account connection flows. We would simply paste the network logs and ask it to look at the git history regarding our webhook module, and it would just work.