Linear Cycles for solo engineers: how to use them without the team you don't have

Linear is the project management tool that designed itself for teams of 5 to 50 engineers. The Cycles feature — Linear’s name for time-boxed iterations — is built around that team-scale workflow. For solo engineers and tiny teams (1–2 people), the docs are not really written for you.

This guide is from running Linear Cycles both solo and on a 2-person team across eighteen months, and the resulting workflow that makes Cycles work at solo scale. The shortest version: you have to strip Linear down past where it is comfortable, then add back the small number of rituals that actually compound.

The reference point: what Linear looks like at team scale

Before deciding what to strip, it helps to see what a tuned-up Linear setup looks like at the next size up. Brian Casel’s “How I use Linear to manage my SaaS” (27 min, 44K views, April 2025) is the most thorough public walkthrough of a small-SaaS-team Linear configuration — Casel runs ClarityFlow with two developers and a customer-support person, and his board has every Linear feature wired up that you can imagine.

His status flow alone is twelve states: New, Soon, Later, Noted (the pre-queue staging) → Shaping (where he writes up requirements) → To-Do (the active queue) → In Progress → In Review → Reviewed → Ready to Deploy → Pending and Deployed → Deployed → Cancelled. He uses Linear Projects to group issues by app area (Conversations, Forms, Commerce, Appointments), two heavily-used labels (bright yellow “customer request” and red “bug”), nested checklist sub-tasks inside each issue description, and threaded comment discussions that he treats as the canonical async record of design decisions. He starts every morning in Linear’s Inbox, sorting comments by issue status — yellow means in-progress means likely blockers, green means completed means lower-priority.

It is a beautiful setup, and almost none of it is right for a solo engineer. But seeing it laid out is the easiest way to see what each piece is for and decide which of those purposes actually applies when there is no one to coordinate with except yourself.

The real reason solo work benefits from cycles

SJCodes’ “Solo Dev? Here’s How To Ship Projects Super Quick” (5 min, May 2025) names the failure mode Cycles are meant to address. He calls it “decision quicksand” — the small cumulative drag of “should I build this page first or the test for that feature?” that fills a solo engineer’s day and produces nothing shippable. The point he lands on: solo speed is not a code problem; it is a clarity problem. You are not slow because you cannot type fast enough. You are slow because nothing forced you to commit to a small enough set of things to actually finish them.

That is the case for Cycles. A cycle is a hard scoping commitment with a fixed end date. Anything that does not fit gets explicitly bumped. The discipline is rare in solo work where you can always justify “just one more thing” and never finish a release.

If you have ever:

• Started a feature and not shipped it for three weeks
• Looked at your backlog and felt overwhelmed
• Forgotten what you were working on after a vacation
• Said “I’ll get to it” about something for two months

Then Cycles can help. They give you a regular ritual of “what did I commit to, what did I do, what carries over.”

What CreaDev Labs got right by switching off Linear

CreaDev Labs’ “Organize Your Solo Dev Project Like a Pro: 2025 Edition” (9 min, February 2025) is the counter-case worth understanding. He had been using Shortcut for solo project management, found it heavy at solo scale, and switched to a card-game-style tool called Codex (no relation to the OpenAI CLI) — physical-deck metaphor, cards you can put in a “hand” for the current sprint, drag to discard when done. He keeps two-week sprints, runs his own backlog refinement on Sunday, and uses Obsidian + a paper bullet journal for upstream brainstorming before tasks even hit the project tool.

The reason this is worth quoting: he did not switch away from team-style tools because they were bad. He switched because the ceremony-to-output ratio at solo scale was too high. The right framing for solo Linear users is not “should I keep using Linear” but “what is the minimum Linear configuration that earns its keep”. If you cannot get under that line, the answer is to switch tools.

The solo cycle workflow that actually works

After iterating, the workflow that has stuck for me:

One-week cycles, not two

Default Linear cycles are two weeks. For solo work, two weeks is too long — by the time you are reviewing your cycle, the world has moved past most of what you committed to. The framework CreaDev Labs uses with two-week sprints works because he has a long-running side project with stable scope. Most solo engineers do not.

One-week cycles force tighter scoping. You commit on Monday, ship through the week, retrospect on Friday. The cadence matches a solo engineer’s natural attention span.

Plan on Monday morning, retrospect on Friday afternoon

The Monday plan:

• Open the backlog
• Pick 5–8 issues that fit one week
• Move them into the current cycle
• Estimate roughly (do not spend more than 5 minutes total on estimation)
• Close Linear and start working

The Friday retrospect:

• What shipped? Move to done.
• What did not ship? Decide: bump to next cycle, or move back to backlog?
• Did anything block that you did not see coming?
• Anything you want to remember? Put it in a project note or doc.

These two rituals take 30 minutes total per week. The discipline pays off in shipping rhythm.

Do not fake-estimate

Linear has estimates (XS, S, M, L, XL or numeric points). For solo work, estimates are noise. You are estimating yourself; you will be wrong; nobody else needs the data. Brian Casel’s team-scale setup uses estimates extensively because they inform load-balancing between developers and the customer-support person; you have neither.

Either skip estimates entirely or use a binary “this fits in a week” check. That is the only signal worth tracking.

Use cycle goals, not just issues

Linear lets you set a cycle goal — a one-line description of what you are trying to accomplish. Use it. “Ship the search feature” or “Get the migration unblocked” or “Investigate the performance complaint.”

The goal is more useful than the issue list because it tells future-you what cycle this was. Six months later, the goal is the searchable artefact.

Treat cycles as autobiography, not commitment

The mental model that breaks for solo cyclists: treating the cycle as a contract. You will over-commit, miss things, feel bad. Stop.

Instead, treat the cycle as a record. “This week I worked on these things.” Some shipped, some did not. The point is not hitting the commitment exactly; it is having a regular checkpoint for honest self-assessment.

What to strip from Brian Casel’s setup

Going back to the team-scale reference: here is what the solo version cuts.

Status flow: twelve statuses down to three or four. Solo, you have Todo → In Progress → Done. Maybe Blocked. You do not need “In Review” (you are the reviewer), “Pending and Deployed” (you remember if you have announced something), or “Shaping” (you shape in your head or in a notes app).

Projects: Casel uses Projects to group sub-features under big app areas. Solo, unless you are running multiple distinct products, the Project layer is empty ceremony. Drop it.

Labels: Casel uses Customer Request and Bug heavily because they signal to other people what kind of work is queued. Solo, you know what each issue is when you write it. Use labels only if you have a recurring need to filter (e.g., “this week, only bugs”).

Triage: Casel has a triage queue because his customer-support person files issues and his developer picks them up. Solo, you are both ends of that pipeline. Skip the triage column.

Sub-issues: Casel breaks 10–12-issue features into nested sub-issues with checklists. For solo, sub-issues add ceremony with no organizational benefit. Use a single issue with a checklist in the description if you need that level of breakdown.

Comments: Casel’s team uses threaded comments as the canonical async record. Solo, you are not communicating with anyone. Comments become a journal at best and a waste of typing at worst.

Inbox-based triage: Casel starts every morning sorting his Inbox by issue status. Solo, your Inbox is empty unless an integration sends you something. Use it for GitHub PR notifications only.

The rule of thumb: every Linear feature exists to coordinate work between humans. If only one human is involved, the feature is overhead.

The Linear features that genuinely earn their keep solo

A few features that solo work actually benefits from:

• The keyboard-first UX — you can run Linear without a mouse, and that compounds over a year
• The single-issue view for deep work — Linear stays out of your way once you are on an issue
• The mobile app for capturing ideas without context-switching to laptop
• GitHub PR integration — link issues to PRs, see status, close issues on merge
• Sub-issues for breaking down medium tasks into half-day chunks (used sparingly)
• Cycles themselves, when configured to one-week with no estimation

Creator POV vs solo reality

Linear’s own “Intro to Linear” (4 min, 114K views, June 2025) and the official documentation are pitched at the team configuration Brian Casel actually runs. The vendor’s framing is the right framing — for a team. The disconnect for solo users is not that Linear is broken at solo scale; it is that the marketing is honest about who the product is for, and most solo users hear “looks polished, I’ll grow into it” rather than “this product expects coordination overhead”.

Creators who actually ship solo tend to land in one of three places. Brian Casel runs Linear with its full feature set because his SaaS has the team to justify it. CreaDev Labs moved off Shortcut to a lighter card-based tool because the project-management ceremony was eating his shipping time. SJCodes barely talks about a project-management tool at all — his solo speed comes from a reusable component library and a “ship the rough MVP, iterate from feedback” rhythm, not from cycle planning.

The honest pattern: if you find yourself opening Linear once a week and ignoring it the rest of the time, you have evidence that simpler is better. Things, Bear, Apple Notes, or a plain text file all work for solo issue tracking. Linear earns its keep at solo scale only if you are using Cycles or the GitHub-integration features actively, and only if the configuration is stripped to roughly what is described above.

My personal setup

For TopInsight’s solo development:

• One-week cycles starting Monday
• 5–8 issues per cycle, no estimates
• Single cycle goal in plain English
• Three statuses: Todo, In Progress, Done
• No projects, no labels (except a single “research” label for non-shipping issues)
• GitHub PRs linked to Linear issues, auto-close on merge
• Friday afternoon 15-minute retrospect ritual
• Annual “is this still worth $8/month?” check (so far, yes — but it is close)

The honest test: Linear feels worth it because the Friday retrospect ritual genuinely makes me more honest about what I am shipping. If I lost that ritual, I would drop Linear and go back to a text file.

For broader productivity tooling, see our Raycast Pro review.