Linear for Issue Tracking

Why Linear?

The biggest predictor of whether an agency ships software on time is not the size of the team or the budget — it is whether issue tracking is fast enough that engineers actually use it. Most agencies discover this the hard way. Jira is the safe choice for someone signing the budget, but it is heavy enough that engineers either route around it or spend so much time grooming tickets that the actual code stops moving. Trello is light, but it falls apart the moment a project has more than thirty open items. Asana is fine for marketing tasks but feels alien to engineers used to thinking in pull requests and cycles. The result is a familiar pattern: the tracker stops reflecting reality, the standup becomes a guessing game, and the project slips because nobody knows what is actually in flight.

Linear is an opinionated issue tracker built specifically for product and engineering teams. It is fast — operations that take three clicks in Jira take one keystroke in Linear — and the design decisions are tuned for how engineers actually think. Issues, cycles, projects, and roadmap views are first-class concepts; everything else is removed. For agencies running engineering-heavy work, strong linear issue tracking is what keeps a small team shipping at the pace of a much larger one. The tool gets out of the way, which is the entire point.

What separates Linear from a general-purpose project tool is the assumption that the user is a developer. Keyboard shortcuts cover almost every action. The data model maps cleanly to how software gets built — issues belong to projects, projects belong to teams, work happens in cycles. The integrations with GitHub and Slack mean issues update themselves as pull requests open, branches push, and conversations happen. Engineers who hate Jira tend to like Linear within an afternoon, which is a remarkable fact about a category of software that engineers usually resent.

How Commonwealth Creative Uses Linear

At Commonwealth Creative, Linear is the system of record for every piece of engineering work we run for clients across Fredericksburg, Culpeper, Woodbridge, Ashland, and Richmond. Web development sprints, custom feature work, integration projects, bug fixes, and infrastructure changes all live as Linear issues. The wider agency context — brand decisions, client communication, content strategy — lives in Notion, but the moment work crosses into “this needs to ship as code,” it moves into Linear. That clean separation is what makes linear issue tracking actually work in practice.

Each client engagement that includes development has a Linear team or project. Issues are scoped tightly — small enough that a single engineer can complete one in a few hours to a few days. Larger pieces of work are broken into a project with a parent issue and child issues that ladder up to it. The project view shows progress as percent-complete based on issue status, which means client-facing status updates are generated from the system rather than manually written, and they are accurate because they reflect what actually got merged.

Cycles — Linear’s name for sprints — run weekly for active client engagements. Every Monday morning, the team scopes the cycle from the backlog, sets a realistic load based on the previous cycle’s velocity, and commits. Anything that does not fit gets explicitly bumped, which is more honest than the implicit slipping that happens in trackers without an enforced cycle. By Friday, the burndown tells us whether the cycle was scoped correctly, and the next planning meeting incorporates that signal. Over a few months, the team’s cycle estimates get sharply more accurate, which is the difference between client commitments that hit and ones that miss.

The GitHub integration is where Linear earns most of its keep. Every Linear issue gets a deterministic identifier — something like CWC-123 — and any branch or pull request that includes that identifier in the name automatically links back to the issue. When the PR opens, the issue moves to “In Review.” When the PR merges, the issue closes. The engineer never updates the tracker manually; the tracker updates itself from the work that actually happened. For a small team, that automation removes the most common reason engineering trackers fall out of sync with reality.

For a Richmond client running a multi-quarter platform build, we maintain a roadmap view in Linear that the client can subscribe to. They see the projects in flight, the upcoming projects in the queue, and the rough timeline. They do not see the individual issues — that level of detail is for the engineering team — but the higher-level view gives them confidence that work is moving and lets them plan their own dependent work without status meetings. That is the version of agency-client transparency that scales.

Linear for Engineering-Heavy Agency Work

The reason linear issue tracking works for engineering-heavy agency work is that it removes the overhead that makes other trackers expensive to use. The cost of creating an issue in Linear is low enough that engineers create issues for things they would not have bothered to track in Jira. The cost of updating an issue is low enough that issues stay current. The cost of finding an issue is low enough that nobody is digging through stale tickets to figure out the state of the project. Each of those costs in isolation looks small. Multiplied across a small team running multiple client engagements, the savings are large.

The keyboard-first design is the most underrated part of this. Engineers who use Linear well rarely touch the mouse. C creates a new issue. M assigns it. S sets status. The whole interaction surface is built so that the tracker takes seconds, not minutes, to maintain. For a five-person agency where engineers are also doing client communication and code review and deployment, those saved minutes per day compound into capacity for actual feature work.

Triage is the other place Linear is meaningfully better than the alternatives. New issues land in a triage queue that has its own dedicated view. The project lead processes triage in a single sweep — accept, reject, prioritize, defer — and the backlog stays clean as a result. Compared to the typical pattern of new issues piling up in an undifferentiated backlog until the project lead occasionally tries to clean it up, the triage workflow is a meaningful operational upgrade.

Cycles also enforce a healthy discipline that other trackers do not. A cycle has a fixed duration, a fixed scope at the start, and a clean handoff at the end. Issues that did not finish either roll over with explicit acknowledgment or get returned to the backlog. The team has a regular rhythm of planning, executing, and reflecting that is hard to maintain in trackers without an enforced cadence. For agency engineering work — where it is easy to get pulled into reactive client requests and lose the proactive momentum — the cycle is what holds the rhythm together.

For Virginia agencies running both engineering and non-engineering work, Linear handles only the engineering side and that is by design. Trying to run brand work, copy decks, or photo shoots in Linear is fighting the tool. Marketing and creative work belongs in Notion or another system designed for that shape of project. The discipline of keeping Linear focused on what it is good at — and not trying to make it the universal tracker — is part of why it stays useful as the agency grows.

Setup and Best Practices

Configure the GitHub integration on day one. The single biggest unlock from Linear is the automatic issue-PR linking, and it requires connecting the GitHub integration in workspace settings, then ensuring branch names and PR titles include the Linear issue identifier. Set up the integration before the first issue gets created and the team will form the right habits from the start. Retrofit it later and you will spend weeks unwinding old patterns.

Keep issues small enough to fit in a cycle. A useful upper bound is “one engineer can complete this in a week of focused work.” Anything bigger should be a project with multiple child issues. Large issues that span multiple cycles are how trackers become works of fiction, because the status field stops carrying useful information for weeks at a time.

Use projects, not labels, for grouping. Labels in Linear exist and work, but they tempt teams into building elaborate label taxonomies that decay over time. Projects are the better grouping primitive — they have a real lifecycle, a real owner, and a real status, which means they stay accurate. Reserve labels for cross-cutting concerns like “needs-design” or “blocked-on-client.”

Hold cycle planning and cycle review meetings religiously. The cadence is what makes cycles work. Skipping planning means the cycle fills up haphazardly; skipping review means the team never improves its estimates. Forty-five minutes per week is a small price for a meaningfully more predictable engineering operation.

Decide explicitly what does not belong in Linear. Brand decisions, marketing copy, content calendars, and client meeting notes do not belong in Linear. Decide upfront that those live elsewhere — Notion, Google Docs, Figma — and link to them from Linear when an engineering issue depends on them. Trying to make Linear the universal source of truth for everything an agency does is the most common mistake teams make with it.

Limitations and When to Choose Alternatives

Linear is the right tool when the work is engineering. It is the wrong tool when the work is something else, and being clear about that boundary is the difference between using Linear well and resenting it.

Marketing and creative work fits poorly. Asana, Monday, and ClickUp are all better tools for marketing campaigns, content calendars, and creative production work. We use Notion for those workflows at Commonwealth Creative — the database flexibility handles content calendars and creative pipelines naturally — and reserve Linear for engineering. Trying to run a content calendar in Linear is forcing a square peg into a round hole.

Customer support ticketing is not Linear’s job. Tools like Intercom, Zendesk, and HubSpot Service Hub are built for customer-facing ticket workflows. Linear can hold internal escalations from those systems — when a support ticket reveals an actual bug, that bug becomes a Linear issue — but the customer-facing layer belongs elsewhere.

Heavyweight enterprise governance — formal change management, audit trails for regulated industries, and integration with enterprise resource planning systems — is where Jira’s enterprise tier still wins. For most agency work this does not matter, but if the client mix includes regulated industries with strict change control requirements, Jira may be a contractual necessity even if it is not the better tool.

Documentation is thin. Linear has a documents feature, but it is not where long-form documentation belongs. Specs, design documents, and architecture decision records belong in Notion or Google Docs, with the relevant Linear issues linked from them.

Reporting is more limited than enterprise PM tools. Linear’s analytics cover cycle velocity, project progress, and basic team load, which is enough for most agencies. Teams that need elaborate cross-team capacity planning, dependency analysis, or executive-style portfolio dashboards may need to layer something else on top.

Finally, the Linear pricing model assumes you are paying for engineers. For an agency with a single developer working alongside a larger non-engineering team, the math is straightforward. For agencies where everyone gets a Linear seat regardless of role, the cost climbs faster than the value, which is another reason the right pattern is to use Linear for engineering and Notion for everything else.

Frequently Asked Questions

How much does Linear cost for a small agency?
Linear has a free plan supporting up to 250 issues and limited team members, which is enough to evaluate the product but not enough to run real engineering work. The Standard plan is $8 per user per month billed annually, the Business plan is $14 per user per month, and Enterprise pricing is custom. For a small agency engineering team of three to five people, that lands around $24 to $70 per month — meaningfully cheaper than Jira’s equivalent tier and dramatically faster to use day-to-day. The price-to-velocity ratio is one of the strongest arguments for Linear at agency scale.

Can a small business with one developer use Linear effectively?
Yes, and it is one of the better single-developer tools because the keyboard-first design rewards individual fluency. A solo developer running client work benefits from cycles for personal accountability, the GitHub integration for automatic status updates, and the project view for client-facing progress reporting. Most of our Virginia small business clients with internal development teams of one or two engineers run on Linear successfully without dedicated project management overhead. The tool is opinionated enough that the structure stays in place even with a single user.

Should we use Linear or Jira for our agency engineering work?
For most agency engineering work, Linear is the better choice. It is faster to use, the design assumptions match how small engineering teams actually operate, and the GitHub integration eliminates the manual sync work that makes other trackers stale. Jira is still the right answer if you need deep enterprise governance, custom workflows for regulated industries, or integration with a specific Atlassian ecosystem your client mandates. For a Virginia agency building websites and custom features for small to mid-size businesses, Linear will produce faster shipping and less tracker overhead than Jira every time.

Get Started

Linear is available at linear.app with a free plan that is enough to evaluate the product seriously and a fourteen-day trial of the paid tiers. Setup takes under an hour for a small team — workspace creation, GitHub integration, team configuration, and importing the first project. The decisions worth taking time on are the team structure, the project naming convention, and the workflow states; everything else can be adjusted as the team learns what works.

If you are a Virginia small business or agency with engineering work that needs proper linear issue tracking — cycles set up correctly, GitHub integration configured, and the boundary between engineering and non-engineering work clean — Commonwealth Creative’s membership model includes the setup and ongoing engineering project management for our Fredericksburg, Richmond, and Culpeper clients. We use Linear for our own engineering work, which means the patterns we deliver are ones we have tested on every project we ship.

References:

• Linear
• Linear Documentation
• Linear GitHub Integration
• Linear API