Small Studio, Serious Delivery: How We Use Linear to Manage Projects

Hekla is a two-person remote development studio. We work on modern web projects for clients in the UK, Europe and the US, from headless CMS builds and Next.js front ends to ongoing development and technical support.

Over time, the way we operate has shifted. It looks less like a traditional agency setup and more like a small product team, where technical decisions, client priorities and day-to-day delivery all need to stay aligned across multiple live projects. That kind of work needs proper systems. A shared to-do list or a Kanban board with no real structure starts to show its limits quickly.

At Hekla, we leverage AI across automation, development tooling and agentic development. Linear.app is part of that stack. It is a project management tool built for software teams, with AI features that help keep work structured, visible and moving. This post is about why we use it and how it supports the way we deliver client projects.

What We Needed from a Project Management Tool

The requirements were fairly specific. We needed a tool that was quick enough to capture work before it disappeared into Slack, but structured enough to support ownership, prioritisation and planning across live projects. It also had to handle bugs, client feedback and maintenance work alongside active development, while fitting naturally into workflows that are increasingly shaped by AI.

What We Used Before

Trello was genuinely useful early on. It's simple, visual and easy to get started with. But it starts to feel loose once you're across multiple projects with real priorities, active bug queues, and work happening at different stages simultaneously. A card on a board doesn't hold much context, and context is a lot of what development work runs on. That problem gets worse when most of your communication happens across time zones and inside Slack. Trello has some Slack integration, but it never quite bridged the gap between where conversations were happening and where the actual work was supposed to live.

Jira is the other obvious option. It's familiar to most software teams and it's powerful. But for two people working across a mix of client builds and ongoing support, the configuration overhead feels disproportionate to the actual work being tracked. It wasn't that it was too advanced. It just wasn't worth the weight.

Neither tool was wrong. They just weren't quite right for how we work.

Why Linear Felt Like the Right Middle Ground

Linear is built specifically for software development teams, and it shows. It's fast, it has clear opinions about how work should be structured, and it doesn't ask you to configure your way to something useful before you can start. Linear's own framing is that it's built for the AI era, and that holds up in practice. It's genuinely designed around how development teams move work forward today, including with agents.

For us, it lands in a useful place: enough structure to work like a real product team, without the admin overhead that would make it a burden for two people running client projects.

Issues, projects, cycles, priorities, statuses, updates, views, automations, integrations. All of it is there. None of it requires a lot of effort to maintain.

We do all of our development in Cursor, which is where the Linear integration starts to feel genuinely useful rather than just convenient. Being able to fire a Cursor agent directly from a Linear ticket means we can have multiple things moving concurrently without losing track of what is being worked on or why. It gives us a head start on implementation before a developer has fully sat down with a task. For simpler work, it also means someone without a deep development background can kick off an agent, get a pull request generated, and have it ready for review without it needing to sit in a queue first.

How We Use It as a Service Business

Most writing about Linear is aimed at product companies. We are a service business, so we have had to think carefully about how to adapt it to work across multiple client projects at once. One of the things that makes that work is how Linear handles Teams. We use a Team for each project, which lets us keep work separated by client and codebase while still having a single place to see everything. Each Team has its own issues, cycles and priorities, but we can move across all of them without losing context.

Projects map to client work or larger internal initiatives. Each has its own issues, priority queue and status.

Issues are where almost everything lives: features, bugs, client feedback, improvements, deployment notes, technical debt. If it needs to happen, it becomes an issue in Linear. Crucially, we can create issues directly from Slack, which means a conversation happening at 9pm in one timezone does not get lost by the time someone picks up work in another.

Cycles give us a lightweight Agile planning rhythm. We run regular standups and retrospectives, and Cycles sit around that cadence, giving us a fixed window to decide what gets attention and commit to it. It's close to how a product team would run sprints, without the overhead that comes with more formal process.

Priorities help us make honest calls about what gets attention first. When you're running work across several clients at once, not everything can be urgent, and having that clearly visible in one place means we spend less time negotiating the queue and more time moving the right things forward.

Because all our work is tracked in Linear, there is always a clear record of where something is up to. Updates and comments live on the issue itself, not buried in a Slack thread or someone's inbox, which means less time spent chasing status and more time spent moving things forward.

Teams are how we separate client work without losing sight of the whole picture. Each project gets its own Team in Linear, which keeps issues, cycles and priorities scoped to that client and codebase. Most tools treat everything as one flat list, which works fine for a single project but gets messy fast when you're running several at once across different repos. Linear lets us move between project teams without losing context, and see everything in one place when we need to.

Some clients have access to our workspace. That's a reason to keep things reasonably well-structured rather than using it as a scratchpad.

How Linear Fits into Our AI-Assisted Workflow

AI is a real part of how we build now. Cursor, GitHub Copilot, ChatGPT, Claude. These aren't tools we're experimenting with occasionally. They're in the regular flow of development work, from writing and reviewing code to testing and catching issues before they reach production.

The thing about AI coding tools is that they produce better output when they have better input. A vague issue gets a vague result. A well-written issue, with clear scope, relevant context, links to related work and a defined outcome, gives any AI tool a much better place to start. That applies whether you're using Cursor to work through implementation, asking Claude to think through an approach, or using Linear's own agent capabilities to summarise context or move work through the system.

Linear is where that context lives. The integrations extend this further. Commits, branches and pull requests in GitHub link back to the issues they came from. Feedback from a Vercel preview can become a tracked issue rather than a comment in Slack that gets buried. Conversations that start in Slack find their way into proper issues with owners and priorities.

So work stays connected. Pick something up, and the issue already has the pull request, the design feedback and the original conversation attached. We connect our day-to-day AI tools to Linear too. Through the Linear MCP server, Claude and ChatGPT can read and act on our issues without leaving the editor: pulling up the week's tickets, helping work out what comes first, updating statuses and bulk editing related issues from the same session we're coding in. It cuts out a lot of switching between editor and project board. We still make the prioritisation calls. The tools handle the picture and the repetitive updates, not the decision about what actually matters this week.

The Problems Linear Solves for Us

A few things that genuinely changed once we had a more structured setup:

• Less loose work. Things that used to sit in Slack, in notes or in someone's head now have a home.

• Better prioritisation. With cycles and priorities, it's easier to make a clear call on what happens next, rather than defaulting to whatever feels most pressing.

• Lightweight structure without the ceremony. We get a planning rhythm without turning the studio into a Scrum exercise.

• Clearer async communication. Statuses and updates mean less time asking where something is up to.

• Better AI handoff. Well-described issues with proper context mean development starts faster and AI tools have more to work with.

• Better AI management. When working within ChatGPT or Claude, we can have our agents pull tickets and update tasks on the fly without leaving our session.

• Proper bug triage. Bugs get captured, prioritised, assigned and connected to the environment where they were found. We also use Cursor automations alongside Linear, so bugs are automatically triaged as they come in rather than waiting on someone to process the queue.

What We're Still Figuring Out

No tool fixes process by itself. We're still working out how much detail different types of issues actually need, when something deserves its own project versus sitting in a backlog, and where to avoid adding structure to things that are just small.

The harder question, honestly, is estimation. AI-assisted development changes delivery speed, sometimes quite dramatically. A task that might have taken a full day can occasionally take an hour. But it works the other way too. AI doesn't make everything faster, and it can introduce new complexity or add review overhead that wasn't there before. We're navigating that honestly with clients, and we don't think anyone has fully worked it out yet.

Why This Matters for Clients

You probably don't need to know which project management tool we use.

What you probably do care about is whether things get dropped. Whether a bug reported on a Friday gets picked up on a Monday. Whether priorities shift without warning and without explanation. Whether there's any real record of how a project was delivered once it's done. That stuff matters, and it's where a lot of small studios quietly fall short.

The stack matters, but it's only part of the picture. A well-built Next.js front end or a carefully configured headless CMS will still cause headaches if the work around it is poorly tracked, badly prioritised or lost in a Slack thread somewhere. Getting that right is something we've been deliberately working on for a while now.

Built for How We Actually Work

Linear works for Hekla because it fits how development is changing, and how we work. We're a two-person studio split across two continents, which is not the conventional setup for a development agency. But that's the point. The right tooling means geography stops being a constraint. Work stays visible, context travels with the issue, and nothing depends on two people being online at the same time to move forward. For us, Linear is less about project management and more about having an operating system that makes a distributed team genuinely effective, not just functional. It's a genuinely exciting time to be building software, and we're leaning into that fully.