How to use Cursor and Linear to be a product team solo

At the moment I am busy expanding a SaaS solution that I had been running for a while. It's called Trusthero and it's a platform to manage online reviews and feedback. Normally, such a Saas building only takes a lot of time. Writing code is not the problem. Determine what to build and ensure that it is well built.

Recently, I am satisfied with a workflow by using cursor and linear. They ensure that I can work more as a small, well-structured product team instead of as a solo developer. Specifications are written, automatically changed to linear issues, and then delegated to cursor agents who fully implement that. My role changes from typing code to reviewing PRs, testing locally and making product decisions.

In this post I will take you in that workflow step by step. How I write specifications, how I delegate them to AI agents and how I ensure that I stay in control.

The stack

This workflow works only because the right tools are used.

Cursor is not just an IDE with car complete. The value is precisely in the way agents can be used within the cursor. They can also create pull requests, but that only works if the input is structured and the scope is clear.

Linear plays that role on the product side. Compared to tools like Jira or general GitHub Issues, Linear ensures that there is sufficient structure: a clear title, description and status. And that without task management becomes a process in itself.

The combination is important. Cursor needs well-defined tasks to operate effectively, and Linear provides a clear, stable source of truth for those tasks. I'm not pasting back and forth. Everything lives in one place, flows in one direction and is easy to review later.

Writing specs

Before code is written I start with a spec. Not because it is a "best practice", but because AI agents are incredibly literal. If something is vague, they will implement the wrong with full confidence.

I use a custom cursor command to generate the specs. The main difference with a normal prompt is that it cannot immediately write specs. First it has to ask me questions. Only when they have been answered does it produce a structured specification. This takes care of 2 things. It forces me to think about edge cases and conditions in advance. And it reminds me of assumptions that I was not aware of. The outcome is a concrete, implementation-ready specification. Scope, acceptance criteria, and explicit requirements; It's all there.

The cursor command also does something else. It ensures that the current state of the solution is analyzed. In addition, it also has a connection to the MCP server from Linear. This means that it can collect all existing issues.

Finally, the cursor command also ensures that specifications are automatically created or updated as issues in linear. Very handy, no copying and pasting.

If you want this exact command, please send me a message on my LinkedIn.

Delegate to Cursor Agents via Linear

Once an issue exists, it can be picked up. From Linear, I delegate the issue to a cursor agent. That agent uses the full context available in the linear issue: title, description, acceptance criteria, scope, dod etc. No additional prompt is required.

In practice, this means that I can have several agents work in parallel. I don't check the execution in real time. My attention remains with high-level decisions, while implementation is progressing in parallel and only strand when there is a pull request to review.

Pull Requests as surveillance

Once an agent has finished his work, the outcome is always a pull request. Nothing is immediately pushed to Main, and nothing escapes a review.

With a pull request I get full control back. I review them just like that of any other software developer. I check out the branch locally and also test the actual implementation. In the code, look for correctness, unintended side effects, missing edge cases and whether the solution fits in with the overall architecture.

By using PRs as Handoff, the responsibility remains clear. Agents propose changes, but they do not determine what goes to production. This limit is what makes the entire workflow safe to use in a real product instead of a demo.

Sometimes an agent has not fully implemented something as I expected. If it is something very small, I adjust it myself. If it is slightly larger, I will start an agent locally to solve those problems. This way a pull request can still continue and it does not have to be fully started again.

What it replaces (and what not)

This workflow significantly changes the role of a product maker, but not on all fronts.

On the side of what is being replaced, it takes over a lot of repetitive and time-consuming work: constantly disappearing back and forth over specifications because the agents follow the clear specs. Micromanagement is no longer necessary; You don't have to check small steps or split each task. And a lot of repetitive code that would otherwise be written manually is automatically generated by the agents.

What is not replaced are the core decisions that make the product. Product thinking, determining what needs to be built, which features have priority, and how it fits into the larger picture remains entirely with you. The final responsibility for the code and the product cannot be delegated either. Finally, taste, judgment and intuitive decisions remain essential: the agents can implement, but do not determine whether something is "good enough" or elegant.

This separation of tasks is exactly what makes the workflow powerful: the agents take over executive burdens while you keep control of direction and quality.

Conclusion

The use of cursor and linear does not change that you are the person ultimately responsible. What it does is streamline execution: repetitive tasks disappear, back and forth is limited, and small details are handled automatically.

Your role shifts to designing, assessing and deciding. You write less code yourself, but you make more product and architectural decisions. Pull Requests remain your checkpoint, specs form the contracts, and Linear keeps everything clear.

In short: the workflow makes it possible to work as one person with the efficiency of a small team, without losing quality, responsibility or product vision. It is a way to use AI and tooling as an extension, not as a replacement, of your own judgment.