Giving a contractor access to your project management tool for six weeks
What guest access actually means, what a contractor can see, what it costs to add them, and how to reverse it cleanly on the last day. With the member cap stated as a cap.
A contractor starts on Monday. Six weeks, fixed scope, one repository. They need to file issues, pick them up and close them, and before standup someone has to decide how to give a contractor access to your project management tool.
That decision takes about ninety seconds. It answers one question — what does it cost — and defers two harder ones. What will they be able to see. And what happens on day forty-two, when the invoice is paid and nobody remembers who still has a login. Pricing pages answer the first. The other two cause the trouble.
What it costs to give a contractor access to a project management tool
Four tools, four different answers, all read at the vendors' own pages.
| Tool | The outsider is a | They cost | The constraint that bites |
|---|---|---|---|
| Jira, Standard and above | Guest | "free of charge (up to 5 guests per paid user)" | One Jira software or business space per site; no guests on Free |
| Linear, Business and above | Guest account | "billed as regular members" — $16 per user/month on Business, yearly | Does not exist below Business |
| Basecamp, Pro | Guest or client | "Invite guests and clients for free" | Pro is $15 per user, billed monthly, for the employees |
| Kevta | Board member | Nothing; the bill does not move | One member against the workspace cap: 10 on Free, 50 on Pro |
A free guest is rarely free of arithmetic. Atlassian's guest costs nothing per head but is metered against paid seats, and "Total number of users (paid + guests) can't exceed your Jira site's user limit". Atlassian also "reserves the right to change the ratio of guests to paid users" (support.atlassian.com). None of that is unreasonable. It means the guest is counted against something, and on a three-person team the something is you.
Linear does not pretend otherwise, which makes it the most expensive of the four and the clearest: nothing to find out later. We have argued elsewhere that per-seat billing produces a rationing habit on small teams. This post goes where that essay stopped.
Jira's guest model is better designed for this than ours
Worth saying before anything else, because it is true. Jira's guest is a distinct class of account with its own rules: scoped to a single space, unable to "see work or data outside that space unless it's been explicitly shared", locked out of site-wide experiences like dashboards and goals, and not consuming a paid licence. That is a purpose-built answer to exactly this problem. Kevta does not have one, and nor does most of the category.
Two constraints bite. "Guests can only belong to one Jira software or business space per site" — a contractor who needs to touch two projects is not a guest, they are a user. And "Guest access is only available in Standard, Premium, and Enterprise plans", so the teams most likely to be counting seats, the ones still on Free, cannot use it at all.
Basecamp's answer is blunter and on this axis beats everybody: on Pro, "Invite guests and clients for free. We will only bill you for employees" (basecamp.com/pricing). No ratio, no account class to learn.
What they can see is a defaults question
The expensive mistake is not overpaying. It is adding someone at the wrong altitude and never noticing.
In Kevta, a board role resolves in a fixed order: board creator and workspace owner are owner, then an explicit role on the board, then the person's workspace role, then no access. Workspace membership defaults to editor — so a contractor you add to the workspace can edit issues on every board in it, including the one about hiring and the one about the thing you have not announced yet.
So the shape that fits a six-week engagement is not workspace membership. It is a board invite: an email address, one board, and one of the four roles you can hand out — viewer, commenter, editor or admin. Owner is the fifth role and not one of them; it belongs to the board's creator and the workspace owner. It works whether or not they already have a Kevta account, and they land on that board with the rest of the workspace invisible (boards documentation).
The bill does not move for any of this: Pro is $10 per workspace per month regardless of headcount (pricing). But free at the margin is a claim about money, not about the ceiling, and the honest version has a number in it. Board-only guests count as members. Free allows 10 members per workspace and Pro allows 50. Sitting at nine on Free, the contractor is your tenth and the next person waits. Fifty is a real limit, not a euphemism. One thing genuinely is free: a guest who already holds a seat does not take a second one when you add them to another board in that workspace. The cap counts people, not memberships.
And one limitation you should hear from us rather than find out: the granularity is the board. There is no client portal, no per-issue privacy and no way to hide a field from one person. If something on that board should not be read by an outsider, it belongs on a different board.
Day forty-two
Offboarding is the part nobody plans, which is the argument for deciding it on day one. Three things about what "remove" does in Kevta.
Removing someone from a board deletes their membership and unassigns their issues on that board, so open work is not left pointing at somebody who can no longer open it. Their comments and the task history stay: the record of what they did survives, only their claim on unfinished work goes. The seat comes back immediately, so a workspace at its cap has room again. And an invite sent but never accepted can be revoked, which matters more than it sounds — the pending invite is the one that outlives everybody's memory.
Then the part that is not about the tracker at all. The tracker is one door. The repository, the deploy target and the shared drive are others, each with its own removal screen and none of them wired to this one. Taking the board back feels like offboarding and closes one door out of four. Write down what you granted on the day the contract starts, while you still know.
Which shape fits
On Jira Standard or above, with a contractor who needs one project, use guest access. It is the most granular of the four models and costs nothing per head. On Jira Free, or with a contractor who needs two projects, or on Linear below Business, that mechanism does not exist and the honest answer is that you are buying a seat for six weeks. Fine answer. Worth knowing it is the answer before the renewal arrives.
If what you want is for the question to stop coming up — a contractor, a designer and a client simply in the tool, no arithmetic — then a flat price with a stated ceiling is the trade. Ours is 50 members per workspace on Pro, with one board and four grantable roles behind it, which is not governance and we would rather say so than let you find out.
Kevta is in beta. If a board you can hand someone for six weeks and take back on the last day is the shape you want, join the waitlist — an early invite, a founding-member price at launch, and a direct line to shape what we build next.
Disclosure
We build an issue tracker and price it per workspace rather than per seat, so this post argues for our own model and should be read that way. Every competitor price and policy above was checked at that vendor's own page, and they change — the linked page counts, not this one. Kevta's caps live on the pricing page and the access model is answered on the FAQ.
- small-teams
- pricing
- issue-tracking