The problem
Most capacity planning spreadsheets are fine for one planner and one afternoon. Then delivery leads, finance, and team managers start editing the same file. Someone locks a column. Someone else works from a downloaded copy. A formula points at a deleted row, and the plan quietly stops matching reality. The file has no history, so nobody can say who moved three engineers off the platform project or when.
Capacity planning also has a specific shape that spreadsheets handle badly. You have supply: people, roles, skills, weekly hours, contractor end dates. You have demand: projects, phases, requested roles, hours by week. Rows are people and columns are weeks, and the grid gets wide fast. One planner can hold that model in their head. Five planners cannot.
The questions you need answered are simple but slow in a spreadsheet. Who has room in week 14? Which role is overloaded in the next quarter? What happens to the plan if the billing migration slips by three weeks? Pivot tables get close, until the next edit breaks the range. Access is all or nothing, so salary notes and manager comments sit in a file that half the company can open. That is the case for a small internal app.
What a good solution looks like
A good capacity app is a system of record, not a prettier grid. Start with two tables. The people table holds name, role, team, skills, weekly capacity hours, employment type, and start or end dates for contractors. The assignment table holds person, project, allocation, start week, end week, and status. Store allocations per person per project per week, or per week with a start and end, so history stays intact. Use Monday as the week start and stick to weekly buckets. Daily capacity planning turns into time tracking, which is a different job.
The main view is a capacity grid: rows by person or team, columns by week, cells showing allocated hours against available hours. Add a demand view that lists projects and the roles they still need. Add a gap report that names over-allocated people, unstaffed demand, and skill mismatches. Filters for team, role, project, and date range matter more than charts. Inline editing should validate: an allocation beyond available hours gets a warning, an end date before a start date is rejected, and a contractor cannot be assigned after their end date.
Permissions and history are why you leave the spreadsheet. Roles should be simple: admin, planner, contributor, viewer. Planners edit allocations. Contributors see their own schedule and can flag a conflict. Viewers see aggregates without private notes. Every change writes an audit record with who, when, old value, new value, and an optional comment. The app should export to CSV and push a read-only feed to your finance or BI tool. Email a weekly digest to planners and send an immediate alert when someone crosses capacity. That is enough for version one.
How to build it
Discovery takes a week or two, not a month. Export the current spreadsheet and list every column with the person who uses it. Mark each column as must-have, nice-to-have, or habit. Interview three planners and a couple of contributors. Decide the planning horizon, usually 12 to 26 weeks, and the capacity formula: contracted hours minus recurring meetings and known leave. Write those decisions down; they will come up again at every demo.
Build in slices. Slice one is a read-only import of people and assignments plus the capacity grid. Slice two is inline editing with validation and audit history. Slice three is the demand side and the gap report. Slice four is permissions, notifications, and exports. Put slice one in front of a pilot group of planners and one team manager. Fix the model before you add features.
On the technical side, a relational database such as Postgres and a web framework your team already knows will carry this for years. Sign in through your identity provider with SAML or OIDC, and map identity provider groups to app roles so you are not maintaining a second user list. Keep allocations in their own table with a week column; a single allocation number on the person row cannot answer historical questions. Add an audit table and a nightly job to recalculate capacity and send digests. Server-rendered pages reduce moving parts and are easier to secure.
Migration is where most replacements fail. Import the last 12 weeks and the next 26 weeks. Reconcile totals against the spreadsheet before anyone edits. Run both tools in parallel for two weekly cycles, then freeze the spreadsheet as read-only with a banner pointing to the app. Train planners in one 45-minute session. Give contributors a short written guide. Write a runbook that covers adding a person, closing a project, fixing an over-allocation, and restoring from backup. Name one owner for the app and one backup owner, or it will drift back to a spreadsheet the first time it breaks.
Risks and how to manage them
Over-modeling is the most common failure. Skill matrices, cost rates, scenario planners, and approval chains all sound useful. Together they turn a small tool into a platform nobody maintains. Start with hours, role, and project. Add skills only when a real staffing decision depends on them. Keep a request list and review it monthly with the planners.
Data freshness is the second risk. A capacity app is only as good as the assignments people keep current. Fold updates into rituals that already exist: project kickoff, weekly delivery standup, monthly finance review. Send a Friday digest that lists assignments ending in two weeks and projects with unstaffed demand. Give contributors a one-click way to flag a wrong assignment. Track assignments that have not changed in three weeks and ask the planner about them.
If the app is used to judge individual utilization, people will pad their allocations or hide bench time. State the purpose in the tool itself: plan work, not police people. Show utilization by team unless a manager has a private view. Keep free-text notes restricted. Trust is a feature, and you build it by being clear about what the data is for.
Access and audit need the same care. Allocation data shows who is busy, who is idle, and which projects are at risk. Use single sign-on, least privilege, and log every export. Test role boundaries before launch with a contributor account and a viewer account. Keep the old spreadsheet readable for 90 days and keep nightly database backups with a tested restore. Watch for spreadsheet creep: someone exports to Excel and starts a shadow file. Publish one link to the app and one link to the official export, and say plainly that the shadow file is not a source of truth.
How to measure success
Measure the work, not the tool. Count the minutes it takes a planner to answer a staffing question, such as who has room in week 14. Count the over-allocations caught before a project starts. Count the stale assignments older than three weeks. Count the reconciliation meetings removed from the calendar. Count the planners who open the app each week. Those numbers are easy to collect and hard to fake.
Watch for qualitative signals too. Finance stops asking which version is current. A new project gets staffed in one meeting instead of three. Contributors check their own schedule before they ask a manager. If nobody opens the app after the pilot, the problem was smaller than it looked, and you should stop or simplify.
Review at eight weeks. Keep what planners use, remove what they ignore, and decide whether the next slice is worth it. If you want the first slice built for you, the Cloudverg Internal tool sprint is $16,500/month and covers one workflow end to end in four weeks, with sign-in, roles, history, import, and exports. It is one option among others: a contractor, an internal build, or a lighter off-the-shelf tool can also work. The test is the same either way. Can your team answer a capacity question in under a minute without opening a spreadsheet?
Frequently asked questions
Can we just improve the spreadsheet instead of building an app?
You can, and for one planner it may be enough. Add data validation, locked formula columns, and a change log tab, and you buy time. The limits show up when several people edit, when you need history, or when finance needs a clean export. At that point an app is cheaper than weekly reconciliation.
What should we build first?
Build the read-only import and capacity grid first. It proves the data model and gives planners something useful in days. Add editing and audit history next, then demand and gap reporting. Permissions and notifications can follow once the core numbers are trusted.
How do we keep the app from becoming another stale spreadsheet?
Tie updates to existing rituals: project kickoff, weekly standup, monthly review. Send a digest of assignments ending soon and unstaffed demand. Give one person ownership and a backup. Track stale assignments and ask about them in the weekly review.