A Freelance Developer's Stack for Client Projects

You're a freelance developer. You have three active clients.

Client A uses Jira. Their QA team lives in their system.

Issues, subtasks, story points. You have to work in their flow.

Client B is a startup using Linear. They're moving fast.

You're doing feature development and pushing code multiple times a day. You live in Linear.

Client C uses Asana internally but you're building an integration so you live in both Asana and their Jira server.

You're not consolidating. You're managing.

The Developer-Specific Problem

You're not a PM. You don't care about project status. You care about:

What am I building today?
What's blocking me?
Where do I commit code related to this?
How do I prove I shipped it?

The PM tools matter only insofar as they track what you need to build.

But they're structured for PM, not for development.

Jira has story points and sprints. You don't care.

Asana has project templates and milestones. You don't care.

Linear has issue links and projects. This is closer to how you think, but still.

You need the tasks. You need to know the scope. You don't need the PM theater.

Your Daily Standup

You're on a standup with each client. That's 45 minutes. Three clients.

For each standup, you need to know:

What did I ship yesterday?
What am I shipping today?
What's blocking me?

Before standup, open each client's tool.

Client A (Jira): Check your assigned issues. Look at the Sprint board. See what you moved to "done" yesterday. What's next? Anything that moved to "blocked" overnight?

Takes 3 minutes.

Client B (Linear): Check "My Issues" filtered by the current cycle. Same thing. What shipped? What's next?

Takes 2 minutes.

Client C (Asana): Check tasks assigned to you. Due this week?

Takes 2 minutes.

7 minutes total prep. Now you're ready for standups.

The Scope Problem

Each tool expresses scope differently.

Jira: "As a user, I want to log in so that I can access my account. Acceptance criteria: ..."

Linear: "Add login page. Subtasks: auth flow, styling, tests."

Asana: "Login page - due Friday."

Same work. Three descriptions.

When you read a task, you need to extract the actual scope. Not the template. Not the jargon. The scope.

What's the minimum viable change that resolves this?

Jira forces you to read the full description. Linear lets you skim. Asana is too vague - you have to ask in comments.

Spend 90 seconds per task clarifying scope. If the description is unclear, ask in comments immediately. Don't wait until standup.

The Commit Message Dance

You commit code. Your commit message needs to reference the task.

Client A (Jira): "ACME-234: Add login page"

Client B (Linear): "Add login page [LIN-45]"

Client C (Asana): "Add login page (Asana: login-page-task)"

Different formats. All correct for their systems.

Develop a muscle memory. Before you push, you know the format for each client.

Better: add a template to your shell. A function that asks you the client and auto-formats the commit message.

The Code Review Workflow

Code review in Jira: someone comments on the issue. You have to find the PR and check the comments there too.

Code review in Linear: they might comment in Linear or in the PR. You have to check both.

Code review in GitHub: PR is the source of truth, but you need to reference the task somewhere.

Establish a rule: PR comments are where the actual feedback lives. Task comments are for status only.

If a reviewer has feedback, they leave it in the PR. You update your task when the PR ships.

This prevents duplicate conversations in two systems.

The Time Tracking Question

You're billable. You need to log hours somewhere.

Jira has time tracking built-in. Client A probably wants you to use it.

Linear doesn't have time tracking. You'll use a separate tool.

Asana has time tracking but it's clunky. You might skip it.

Use a separate time tracking tool for all clients. Something simple. Toggl or Timely.

Start a timer when you open the task. Stop it when you move to the next task.

At the end of the week, you have the logs. Match them to invoices.

Do not try to maintain time logs in three different tools. You'll lose data.

The Async Communication Problem

Client A communicates in Jira. They update tasks.

They comment. You live in Jira.

Client B communicates in Slack and Linear. Most decisions are in Slack. You have to check both.

Client C communicates via email and Asana. Important decisions are in email. You have to check email.

Establish a rule: you respond once daily to each client.

Morning: check email, Slack, the task tool. Respond to anything that needs a response.

Afternoon: if someone pings you directly (not in a task), respond immediately. Otherwise, wait until next morning.

This prevents you from being interrupted 20 times a day.

The Blocker Pattern

Something blocks you. Your PR is waiting on a code review. A decision is pending.

In Jira, you move it to "blocked" and comment why.

In Linear, you might use a status or just leave a comment.

In Asana, you comment and hope someone notices.

The rule: if it's blocked, you communicate it outside the tool.

You message the blocker directly. Slack. Email. Whatever the client uses.

Don't rely on the task tool to broadcast that you're stuck. You'll wait forever.

Tell people directly. "Hey, I shipped the PR. Waiting on your review before I move to the next task."

The Weekly Deliverables Sync

Once a week, usually Friday, you send each client a summary.

"This week I shipped: X, Y, Z. Next week I'm working on: A, B. Blockers: none currently."

Write it directly from the task tool.

Don't try to maintain a separate status document. You'll update it for two weeks and then stop.

Reference the actual tasks. Client A: "Shipped ACME-233 and ACME-234." Client B: "Shipped LIN-43, LIN-44, LIN-45."

This creates a paper trail. It's proof of work.

The Technical Details

Some clients want you to document technical decisions in their tool.

Jira: add a "Technical Notes" field.

Linear: leave a long comment.

Asana: attach a document.

You could maintain a wiki or a separate doc. Or you could put it in the tool.

Put it in the tool. One source. Less to maintain.

Scaling to More Clients

As a freelancer, four to six active clients is your practical ceiling.

More than that and you're context-switching constantly.

At four clients, you have four tool-switches per day in standup alone.

At six, you're context-switching 8+ times daily just for standups.

That's your limit.

If you need more income, increase your rate or take longer projects instead of more projects.

Tools to Consider

Time tracking: Toggl ($20/month) or Timely ($40/month). Use one across all clients.

Note-taking: OneNote or Obsidian. Keep developer notes separate from task tools.

Code annotation: Inline comments in your IDE. When you read a task, you understand what needs to be coded. Write the comment in the code. "// TODO: this is for ACME-234, login flow check below"

Dashboard: If you're juggling many clients, a unified view like Huddle helps. One glance tells you what's assigned across all clients.

The Context Switching Reality

You are context-switching. Accept it.

Your job is to minimize it where you can.

Batch your tool-checks to before standups. Before you start coding for a new client. At end of day.

Don't check Jira every 30 minutes. You're killing your focus.

You'll have Slack notifications. Someone will ping you.

Address those when they come. But scheduled tool-checks should be batched.

The Common Mistake

Developers often try to create a "master task list" in their personal system.

They open all three client tools and recreate the tasks in Things or Todoist.

By week two, the personal system is out of sync. The source of truth is still the client tool, but the personal system is stale.

They waste time maintaining a parallel system that doesn't work.

Skip the personal system. Trust the client tools.

The client tool is annoying. That's the point.

The annoyance forces you to actually check it. You don't miss things.

FAQ

What if a client uses a tool nobody's heard of?

Learn their tool for the engagement. Treat it like any other tool.

It has a way to see what's assigned to you. Check it daily.

Should you push back on clients using specific tools?

No. You're not in a position to negotiate that. Pick clients whose tools you can tolerate or add a premium for tools you hate.

How do you bill for tool overhead?

Don't. Tool overhead is part of doing business with multiple clients. It's baked into your rate. If the tool overhead is so bad that you can't bill reasonably, you've picked the wrong client.

What if two tools have contradictory status?

Choose one as the source of truth per client. Usually the native tool is correct. Comment in the other tool: "Status updated in [tool], check there for current state." Then move on.

How long does it take to onboard to a new client's tool?

One day. You learn the interface enough to create/update/close tasks. That's all you need. Advanced features don't matter.