Capacity planning tools for teams without a dedicated planner

Capacity planning software is built on an assumption that quietly fails in small companies. It assumes somebody owns the schedule. In a 200 person agency a resource manager spends the morning moving allocations and the data stays current. In an eight person team the person who would do that is also shipping the work, so the allocations are accurate on the day they are entered and fiction by Thursday.

That is the real decision behind this search. Not which tool has the best utilization chart, but which approach survives having no one whose job it is to keep it fed.

The three numbers capacity planning is trying to produce

Every tool in this category, and every spreadsheet that replaces one, exists to compare three quantities.

Capacity. How many hours the team can actually work in a period. Not headcount multiplied by forty. Working days minus public holidays, minus booked time off, minus the share of each person's week that goes to support, meetings, and internal work. Teams that skip the last subtraction produce plans that are wrong by twenty percent before any project starts.

Commitment. How many hours the accepted work needs in that same period. This is the number nobody has, because it requires an estimate on every piece of work. A tool cannot supply it. It can only hold it once someone writes it down.

The gap, by person and by week. One person at 140 percent while another sits at 60 percent is a different problem from the whole team at 110 percent. The first is a reassignment. The second is a conversation with a client about a date.

Everything else the category sells, scenario planning, skills matching, billable utilization, forecast revenue, is built on those three. A tool that produces beautiful charts from estimates nobody maintained produces confident wrong answers, which is worse than an honest blank.

Two families of tool, priced very differently

The market splits cleanly, and the split matters more than any feature list.

Dedicated resource schedulers treat people as the primary object. A person is a row, dates run across, and work is placed into their week. They price per person scheduled, and none of the established ones has a free tier.

Tool	Entry price	Next tier	What the next tier adds
Float	$7 per scheduled person a month	$12	Time tracking, rate cards with multi-currency, project cost estimation, SSO
Resource Guru	$5 per person a month	$8, then $12	Timesheets, custom reports, project rates and budgets, custom fields, then approval workflow and SSO
Runn	$7 per resource seat a month	$11	Timesheets, 5 custom fields, integrations, API, 30 day audit log

Resource Guru charges separately for non-human resources such as rooms and equipment, at $2.50, $4, or $6 each depending on tier. Float and Runn both offer a 30 day trial, and Runn notes volume discounts starting at 100 or more resource seats. All three published figures come from their own pricing pages.

The second family is general project management tools that added a capacity view. Here the capability tends to sit on a higher tier. Asana places resource management on its Advanced plan at $24.99 per user a month billed annually, above Starter at $10.99, and describes it as identifying who is overloaded within one portfolio. Wrike lists advanced resource and capacity planning on Pinnacle, which is quoted by contact rather than published, above Business at $25 and Team at $10 per user a month. Both have a free tier, and in neither case does the free tier include the capacity view.

The arithmetic is the point. For an eight person team, a dedicated scheduler at $7 a head is about $56 a month, while moving an existing project tool up two tiers to reach a capacity view can cost more than that and changes the tool everyone uses. Neither is expensive. Both are wasted if the estimates behind them go stale.

What the per-person price actually buys

Three things, and they are worth naming because a spreadsheet gives you none of them.

Time off and holidays handled once. Capacity and time off management is the feature that most clearly earns the subscription. A person on leave for a week disappears from availability automatically, in every view, without anyone editing a plan. Global holiday calendars do the same across countries, which matters for a distributed team where September 23 is a working day in one place and not in another.

Placeholders for work you have not staffed. Float and Runn both support placeholder rows, sometimes called tentative projects, so a project that is probably happening can be planned against an unnamed person. This is how a small team decides whether it needs to hire, and it is genuinely hard to do in a spreadsheet.

Utilization over time rather than today. The chart that shows the team at 95 percent this week and 40 percent in three weeks is what turns capacity planning from reporting into a decision. Runn includes capacity and utilization charts on its entry tier and puts saved scenarios at 3 per user there, with unlimited scenarios higher up.

What the price does not buy is estimates. Every tool in the table depends on somebody entering how long the work will take. The tools that also sell timesheets, which is most of them at the second tier, are selling the feedback loop: compare estimated hours against recorded hours and the next estimate is less of a guess.

The failure mode that has nothing to do with software

A capacity plan decays at a predictable rate. A week in, the estimates on new work are missing. Two weeks in, three projects have shifted dates and nobody moved the allocations. A month in, the chart still renders, and people have quietly stopped believing it.

With a dedicated planner this does not happen, because maintaining it is the job. Without one, the only plans that stay alive are the ones maintained as a side effect of doing the work. That points to a specific design rule for small teams.

Put the capacity numbers on the work, not in a separate plan. If the estimate lives as a field on the task, then moving the task changes the plan. If the estimate lives in a resource scheduler that mirrors the task, someone has to update two places and eventually updates one.

This is why an eight person team sometimes gets more from a coarse view inside the tool where the work already lives than from a precise view in a tool nobody opens. A board that shows people down the side and dates across the top, built from the same cards the team drags every day, is a weaker instrument than Float. It is also never out of date, because the cards are the work. The board types available in a project tool are worth checking against this test: does the capacity view read from the tasks, or does it need its own data entry?

Feeding the tool without entering everything twice

If a scheduler is bought, the next question decides whether it lasts: where does the data come from.

Three routes exist. Someone types allocations into the scheduler by hand, which is accurate at first and the first thing to lapse. An integration pulls projects or tasks in from the tool the team already uses, which keeps the two in step but usually syncs project shells rather than the day to day movement of individual tasks. Or the API is used to push data across on a schedule, which works and costs a developer half a day plus maintenance.

The tiers matter here. Float lists API and integrations access on its entry plan. Runn puts out-of-the-box integrations and API access on Standard at $11 per resource seat a month rather than on Lite, so a team planning to automate should price the higher tier from the start. Resource Guru publishes integrations and lists AI integrations through MCP, which is the newer route for pulling numbers out on demand rather than pushing them in.

Before buying, write down who types what, and when. If the honest answer is that the founder will update allocations on a Monday if nothing catches fire, the plan will be current about half the time, and a coarse view built from the tasks themselves will beat it. If the answer is that one person owns the schedule for two hours a week, a dedicated tool earns its price immediately. The tool is not the variable. The named person is.

Getting a usable answer with no new subscription

For a team of five to ten, the following sequence produces the three numbers without buying a scheduler.

Add an estimate field to every task. A custom field for estimated hours, filled in with a rough number at the moment work is accepted. Rough is fine. Missing is not. Half day granularity is enough for planning at this size.

Write down the real weekly capacity per person. Start from working days, subtract known leave, then subtract the recurring load. Most people in a small team have between 25 and 32 hours a week available for project work, not 40, and using the honest figure changes every conclusion that follows.

Lay people against dates once a week. A view with people as rows and dates as columns, populated from the cards, is enough to see pile-ups. Fifteen minutes on a Monday, looking two to three weeks ahead rather than at today.

Record actual hours if invoicing needs them. Timesheets are a separate discipline from planning, and worth adding only when hours turn into invoices or when estimates need calibrating. Where a project tool offers it as an add-on the cost is comparable to the schedulers above, and the pricing page is the place to check whether managers who only approve hours are counted as billed users, because that assumption varies between vendors and changes the total.

Review estimates against actuals monthly. This is the step that makes the next quarter's plan credible, and it is the step every team skips.

When a dedicated tool is the right answer

Buy the scheduler when one of these is true. Someone is accountable for utilization as a number, which usually means billable work sold by the hour. Non-human resources need booking alongside people, such as studios, vehicles, or equipment. Hiring decisions turn on forecast demand, so placeholder planning has real money attached. Or the team is above roughly fifteen people, where the coordination cost of a shared view exceeds the maintenance cost of a dedicated one.

Below that, the deciding factor is not features. It is whether the estimates will be entered at all, and estimates get entered where the work already is. Comparisons of what different project tools include without an upgrade are collected in the side by side tables.

What to change first

Add an estimated hours field to the next ten pieces of work the team accepts, and write down each person's honest available hours for the coming three weeks. Compare the two totals before evaluating any tool, because that comparison tells you whether the problem is visibility or overcommitment. If the tasks have no home that can hold a field like that, Pinateca includes custom fields and a resource view on its free plan for a team of five.

Q1. Is there a free capacity planning tool?

Among dedicated resource schedulers, not really. Float, Resource Guru, and Runn all start at a paid per-person rate with a trial rather than a free tier. Free tiers exist in general project management tools, but the capacity and resource views in those products usually sit on paid plans, so the free route is a board with an estimate field plus a weekly review rather than a purpose built chart.

Q2. What is the difference between capacity planning and resource scheduling?

Capacity planning asks whether the team can absorb the work over the coming weeks. Resource scheduling assigns named people to specific work on specific days. Most tools in this category do both, but the first question is answered with totals and the second with a calendar, and a small team usually needs the totals more urgently.

Q3. How accurate do the estimates have to be?

Accurate enough to spot a person at double capacity, which means half day granularity is sufficient. Precision beyond that is wasted at small scale, because the schedule changes faster than the error. The larger risk is not a rough estimate but a missing one, since work without an estimate is invisible to every calculation.

Q4. How often should a capacity plan be updated?

Weekly, looking two to three weeks ahead, is the cadence that survives in teams without a dedicated planner. Daily updating is a job nobody has, and monthly is too slow to prevent the overload it would have shown. The update is cheap if the estimates live on the tasks and expensive if they live in a separate plan.

Q5. Do timesheets need to be part of this?

Only for two reasons: invoicing by the hour, and calibrating estimates against reality. Planning works without them. Most of the schedulers place timesheets on their second tier, so the decision has a price attached, and adding hour entry to a team that does not bill by the hour tends to produce data nobody reads.