People & HR

How to plan headcount as Small HR Teams

People & HRFor Small HR Teams3 apps12 steps~24 min to set up

Your CFO asks for a headcount plan every quarter. You spend two days pulling salary data from Paylocity or ADP into a spreadsheet, chasing department heads for open req status in Greenhouse, cross-referencing offer letters in your inbox, and building a tab for each scenario (hire 5, hire 8, freeze everything). By the time you send the model, one manager has already extended an offer you didn't know about. The spreadsheet is wrong before it lands. There's no single view connecting what you're actually spending on people today to what adding three engineers in Q3 costs across salary, benefits load, and equity — so every board prep cycle starts from scratch.

Build this on Starch → See the apps used

People & HRFor Small HR Teams3 apps12 steps~24 min to set up

Outcome

What you'll set up

A live headcount model that pulls current payroll actuals from your Paylocity or ADP sync and layered open-req data, so your numbers are never stale when the CFO asks

Scenario comparisons — hire 4 in Q2 vs. freeze headcount vs. backfill only — with runway impact calculated against real burn data from Plaid and Stripe

A repeatable monthly process that takes 20 minutes instead of two days, with outputs you can paste directly into a board deck

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Scenario Analysis Runway Analysis Budgeting

Data sources & config

Starch syncs your Paylocity data on a schedule (employees, payroll runs, pay statements) and your Plaid bank feed on a schedule (transactions, balances) — these are the two primary data sources. Stripe revenue is also synced on a schedule for runway calculations. Open-req and offer data from Greenhouse is connected from Starch's integration catalog and queried live when your headcount model runs. Notion headcount planning docs, if you maintain them, connect from Starch's integration catalog and are queried live.

Prompts to copy

Build me a headcount scenario model that shows three hiring plans side by side: hire 4 engineers and 1 AE in Q2, backfill only the open SDR role, and a complete freeze. For each scenario show total annualized salary cost, estimated benefits load at 22% of base, net monthly burn increase, and months of runway remaining. Pull current headcount costs from Paylocity and current cash burn from Plaid.

Show me our current monthly burn broken down by people costs vs. non-people costs, using Plaid transactions and Paylocity payroll runs, and project out 18 months at each of the three headcount scenarios I just modeled.

Build a people-cost budget tracker that compares our Q2 approved headcount budget against actual payroll spend from Paylocity by department, with a variance column showing dollars over or under and a pace indicator for each team.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Paylocity in Starch — Starch syncs your employee roster, payroll runs, and pay statements on a schedule. This becomes the source of truth for current headcount cost by department, not a spreadsheet someone copied last month.

2 Connect Plaid so Starch syncs your bank transactions on a schedule. This feeds the burn side of your runway model with real cash out the door, not bookkeeper estimates.

3 Connect Stripe so Starch syncs your revenue data on a schedule. This gives the CFO a complete picture — cash in, cash out, and people cost as a share of burn.

4 Connect Greenhouse from Starch's integration catalog — the agent queries it live when your model runs, pulling open req status, role titles, and offer stage so your plan reflects what's actually in flight.

5 Start with the Scenario Analysis app from the App Store. It loads your Plaid and Stripe baseline automatically. Then prompt it with your specific hiring scenarios — numbers, roles, and your benefits load assumption (e.g., 22% of base).

6 Run the Runway Analysis app alongside it so every scenario immediately shows months of runway at that burn rate — the CFO's first question is always 'how long does this give us?' and you should have the answer before the meeting.

7 Use the Budgeting app to compare your Q-level approved people budget against Paylocity actuals by department. Prompt it to flag any department that is more than 10% over their approved headcount spend.

8 Ask Starch to build a headcount roster view on top of your Paylocity sync — department, role, start date, annualized cost, and whether the person was in the original Q budget or added mid-quarter.

9 When a manager wants to add a role mid-quarter, prompt Starch: 'Add one senior engineer at $175k base to the Q2 freeze scenario and show me the updated burn and runway impact.' Takes 30 seconds instead of a spreadsheet edit you might make in the wrong tab.

10 Before each board meeting, prompt Starch to summarize the headcount plan: total current employees by department, open recs in progress, approved headcount budget vs. actual spend, and which scenario you're operating against. Paste the output into your board prep doc.

11 Set an automation so that every Monday Starch pulls the latest Paylocity payroll data and Plaid transactions, recalculates burn and runway, and Slacks you a one-line update: current headcount count, last payroll total, and months of runway at current pace.

12 After the CFO approves a scenario, fork it in Starch as the locked plan and build a monthly check-in dashboard that compares actual hiring pace and payroll spend against that approved scenario — so you can see drift before it becomes a board-level conversation.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

Q2 2026 headcount plan — 3-scenario board prep, 2 people, 4 hours

Sample numbers from a real run

Current monthly payroll (Paylocity sync)	187,400
Benefits load at 22% of base	41,228
Scenario A: add 4 engineers + 1 AE (annualized)	1,080,000
Scenario B: backfill SDR only (annualized)	132,000
Scenario C: freeze (delta)	0
Current monthly burn (Plaid)	341,000
Runway at Scenario A burn rate (months)	11
Runway at Scenario B burn rate (months)	16
Runway at freeze burn rate (months)	19

Before the April board meeting, your CFO asks for the Q2 headcount plan by Friday. Last quarter this took you two days: export from Paylocity, paste into a Google Sheet, email three department heads for their open-req list, rebuild the benefits load formula that broke when someone added a column. This time you open Starch. Paylocity is already synced — you can see all 148 employees, their departments, and last payroll run totaling $187,400 in monthly base salary. You start with Scenario Analysis and type: 'Show me three hiring scenarios for Q2 — add 4 engineers and 1 AE, backfill the SDR role only, and a full freeze. Use 22% benefits load on base. Pull burn from Plaid and show runway for each.' In a few minutes you have three columns: Scenario A adds $90k/month in people cost and drops runway from 19 months to 11. Scenario B adds $11k/month and barely moves the needle. Scenario C holds. You open Runway Analysis to sanity-check — it confirms current net burn of $341,000/month against your Plaid feed. You send the three-scenario summary to the CFO before lunch. She picks Scenario B with one modification: backfill the SDR and also approve one senior engineer. You type that into Starch, get the updated numbers in 30 seconds, and that's the version that goes into the board deck. The whole thing took four hours instead of two days, and the numbers were current as of this morning's payroll sync, not last Tuesday's export.

Measurement

How you'll know it's working

Monthly people cost as a percentage of total burn (target: under 65% for most early-stage companies)

Headcount budget variance by department: approved vs. actual payroll spend

Months of runway at each approved scenario, updated weekly from Plaid and Paylocity

Open req to offer-extended ratio — how many roles are sitting in Greenhouse vs. moving toward a hire

Time to produce the quarterly headcount plan — from CFO request to delivered model

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Spreadsheet (Google Sheets or Excel)

Free and flexible, but every number is manually entered and stale the moment someone in Greenhouse extends an offer or Paylocity runs payroll — you rebuild from scratch each cycle.

Rippling or BambooHR built-in headcount reports

Good for roster and comp data inside the HRIS, but won't combine people costs with Plaid cash burn or Stripe revenue to show runway impact — you still need to build the scenario model yourself.

Anaplan or Workday Adaptive Planning

Purpose-built for headcount modeling at scale, but implementation takes months, requires a dedicated admin, and costs more than most 150-person companies will spend on HR tools in a year.

ChartHop or Pave

Solid for comp benchmarking and org charting, but they show you current state — they don't let you build custom what-if scenarios against your actual bank burn from Plaid.

On Starch RECOMMENDED

One platform — scenario planning, runway analysis, quarterly budgeting all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

We use Rippling, not Paylocity or ADP. Can Starch still pull our headcount data?

Rippling is available from Starch's integration catalog and the agent queries it live when your apps run. It won't have the same scheduled-sync depth as Paylocity or ADP (which sync on a schedule and store data in Starch), but for most headcount planning use cases — roster, roles, compensation data — a live query gets you what you need.

Does Starch store our salary and payroll data? We're cautious about where employee comp information lives.

For Paylocity and ADP, yes — Starch syncs payroll data on a schedule and stores it in Starch's database to power your apps. Starch is not SOC 2 Type II certified today, so if your company or your legal team requires that certification for systems holding employee compensation data, that's an honest blocker you should weigh.

Our CFO wants the headcount model in a specific Excel format. Can Starch export to that?

You can export data surfaces from Starch, but if you have a rigid Excel template with specific tabs and formulas, the realistic answer is that Starch gives you the data and scenarios fast, and you paste the numbers into the CFO's template. That's still 90% of the time savings.

Can Starch pull open-req data from Greenhouse so our headcount plan includes in-flight hires?

Yes. Connect Greenhouse from Starch's integration catalog and the agent queries it live when your headcount model runs. You'll see open recs, stages, and offer status alongside your Paylocity roster so your model reflects what's actually happening, not just who's currently on payroll.

We also track contractor and PEO headcount separately from full-time employees. Can Starch handle that?

Yes. If your contractors are tracked in a system in Starch's integration catalog — or even in a Google Sheet — the agent can pull that data live and include it in your model. If contractor invoices run through Plaid or QuickBooks, Starch can pull those costs directly so your people-cost total is accurate, not just the W-2 payroll number.

What if our QuickBooks data doesn't match what Paylocity says we spent on payroll?

That mismatch is real and common — payroll timing, benefits pass-throughs, and employer taxes create gaps between what's in the HRIS and what hits the books. Starch can show both side by side and let you prompt it to explain the delta, but reconciling them is still a judgment call your team makes. Note: QuickBooks report views like P&L are temporarily unavailable pending an upstream fix, but entity-level data — bills, payments, journal entries — syncs normally.