How to run a scenario analysis for a strategic decision as CPG Founders

Strategy & PlanningFor CPG Founders2 apps11 steps~22 min to set up

You're about to sign a co-packer agreement for a new SKU line. Or you're deciding whether to chase a Target reset that requires 90 days of inventory pre-build. Or your lead investor wants to know your fundraising timeline. Every one of these decisions has a financial consequence you can't fully see because your numbers live in three places: a Stripe dashboard, a Plaid-connected bank account, and a spreadsheet your part-time bookkeeper updates monthly. You build the scenario in Excel, spend four hours on formulas, and by the time you finish the model your Stripe revenue number is already stale. CPG decisions move fast and the margin for error is thin.

Strategy & PlanningFor CPG Founders2 apps11 steps~22 min to set up
Outcome

What you'll set up

A live baseline that pulls real revenue from Stripe and real burn from your Plaid bank feeds — no manual data entry, no waiting on your bookkeeper
Side-by-side scenario comparisons showing runway, burn rate, and break-even under each option (new SKU launch, co-packer rate increase, delayed fundraise, slower DTC growth)
A model you can update in minutes when assumptions change — not a spreadsheet you rebuild from scratch every time a retailer changes their terms
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.

Data sources & config

Starch syncs your Stripe data on a schedule (charges, invoices, subscriptions) and syncs your Plaid bank feed on a schedule (categorized transactions and balances). The Scenario Analysis app uses both as its live baseline. No spreadsheet uploads, no manual refreshes — when your numbers move, the model moves.

Prompts to copy
Connect my Stripe account and Plaid bank feeds, then show me my current baseline: net burn over the last 6 months, projected runway at current pace, and a category breakdown of where cash is going.
Build three scenarios side by side: (1) baseline — no changes, (2) we land the Target reset and pre-build 90 days of inventory starting in 60 days, which adds $180K in COGS and delays $220K in revenue by one quarter, (3) our co-packer raises rates 12% and we absorb it without a price increase. Show me runway, monthly burn, and break-even month for each.
Add a fourth scenario: we raise a $1.5M bridge in month 3. Show how that changes runway and break-even relative to scenario 2.
Run these in Starch → or paste them into your favorite agent
Walkthrough

Step-by-step

1 Connect Stripe and Plaid in Starch. Starch syncs both on a schedule, so your revenue and bank data are live from day one.
2 Open the Scenario Analysis app from the Starch App Store — it uses your connected Stripe and Plaid data to build the baseline automatically. You're not starting from a blank model.
3 Open Runway Analysis in parallel to sanity-check your baseline burn rate and cash position before you start building scenarios. This is the number everything else branches from.
4 Define the decision you're actually trying to make — co-packer contract, retail pre-build, fundraise timing, price increase. Type it into Starch in plain language so the scenarios are anchored to a real choice, not hypothetical.
5 Build your first scenario by describing the specific assumption changes: inventory pre-build amount, timing, COGS impact, expected revenue offset. Starch layers these on top of your live baseline rather than making you re-enter your actuals.
6 Build your second and third scenarios the same way — each one adjusting only the variables that differ. For CPG, this often means tweaking COGS (co-packer rate, input costs), revenue timing (retailer payment terms, seasonal sell-through), or a capital event.
7 Compare runway, net burn, and break-even side by side across all scenarios. Flag the scenario where you fall below 6 months of runway — that's your red line for the decision.
8 Adjust a scenario assumption in real time — for example, change the co-packer rate increase from 12% to 18% — and watch runway recalculate without rebuilding the model.
9 Use the output to frame the actual decision: if the Target reset only works if you raise before month 4, that's the answer. If absorbing a co-packer rate hike drops you below 9 months runway, you know you need to either raise prices or renegotiate.
10 Share the scenario output with your co-founder, lead investor, or board contact. Export or share a link — no need to email a spreadsheet and explain the tabs.
11 Revisit the model monthly or whenever a key assumption changes (distributor deduction dispute resolved, new wholesale PO lands, co-packer invoice comes in higher than estimated). Because Stripe and Plaid sync continuously, your baseline is always current.

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

Target Reset Decision — April 2026

Sample numbers from a real run
Current monthly net burn (baseline)47,000
Target pre-build COGS outlay (one-time, month 2)180,000
Expected Target PO revenue (delayed to month 4)220,000
Current cash on hand (Plaid)610,000
Projected runway, baseline scenario13
Projected runway, Target reset scenario (months)8
Projected runway, Target reset + $1.5M bridge (months)24

Your Plaid feed shows $610K cash on hand. Stripe is bringing in $38K/month in DTC subscriptions and one-time orders. Net burn at current pace is $47K/month — 13 months of runway in the baseline scenario. Then a Target buyer comes back with a reset offer: 180 SKU facings across 400 doors, reset date in 60 days, first PO paying net-60. You run the scenario in Starch. Pre-building 90 days of inventory means a $180K COGS spike in month 2 before a dollar of Target revenue hits. The first PO — roughly $220K — lands in month 4. In the Target reset scenario, runway compresses from 13 months to 8 because of that cash trough in months 2 and 3, even though the deal is profitable on a unit basis. A third scenario layers in a $1.5M bridge closing in month 3 — runway jumps to 24 months and the Target reset becomes straightforward. The model tells you the real question isn't 'do we take the Target deal?' It's 'can we close $1.5M in 90 days?' That's a different conversation to have with your lead investor, and now you have the numbers to have it.

Measurement

How you'll know it's working

Net cash burn per month (separated from gross spend — COGS spikes for inventory builds distort the headline number)
Runway in months at current pace vs. runway under each scenario being evaluated
Break-even month — the specific month where cumulative revenue from a new channel or SKU exceeds its cumulative cost
Cash trough date — the lowest cash point in any given scenario, not just ending runway
Revenue-to-burn ratio by channel (DTC vs. wholesale vs. marketplace) to identify which bets are worth the cash drag
Comparison

What this replaces

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

Excel or Google Sheets
You can model anything, but your baseline goes stale the moment you close the file — Stripe and Plaid data don't update themselves, and rebuilding assumptions from scratch every time a variable changes takes hours you don't have.
Fathom or Mosaic (FP&A software)
Purpose-built for financial modeling but priced for companies with a finance hire; setup requires clean QuickBooks or NetSuite data, which most early-stage CPG brands don't have yet.
QuickBooks reports + manual export
QuickBooks tells you what happened; it doesn't let you model what will happen under different decisions, and it's only as current as your last bank reconciliation.
Hired fractional CFO
A good fractional CFO builds better models than Starch, but you're waiting for their next availability and paying $3K–$8K/month for capacity that mostly sits idle between key decisions.
On Starch RECOMMENDED

One platform — scenario planning, runway analysis 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

Does Starch pull my actual bank transactions or just Stripe revenue?
Both. Starch syncs your Plaid bank feed on a schedule — categorized transactions and balances — and your Stripe data separately (charges, invoices, subscriptions). The Scenario Analysis baseline uses both, so net burn reflects real cash out the door, not just what's in your accounting software.
My bookkeeper is still closing last month's books. Can I still run a useful scenario?
Yes. Starch builds the baseline from Plaid bank transactions and Stripe revenue, not from your closed books. You don't need QuickBooks to be reconciled. The tradeoff is that Plaid shows cash-basis movement — if you need accrual-basis COGS allocations, you'll want to layer in your QuickBooks data once it's available. Starch connects directly to QuickBooks too, when you're ready.
I need to model a co-packer rate negotiation where the rate changes are complex. Can Starch handle non-standard assumptions?
You describe the assumption in plain language — 'co-packer raises per-case rate from $3.20 to $3.84 starting month 3, affects all three SKUs, I'm running 40K cases per month' — and Starch builds the scenario from that. You're not limited to preset fields. If you can describe it, Starch can model it.
Can I share the scenario output with my lead investor without giving them Starch access?
You can export or share a link. You don't need to hand over spreadsheet tabs or explain formulas — the scenario output is self-contained.
Is Starch SOC 2 certified? I'm connecting bank data.
Not yet — Starch is not SOC 2 Type II certified. That's worth knowing before you connect sensitive financial data. It's on the roadmap. If SOC 2 is a hard requirement for your company's security policy, that's an honest limitation today.
What if I want to model something like a deduction reserve — a specific CPG cash flow pattern that most finance tools don't understand?
Describe it in plain language. 'We get hit with about $12K in distributor deductions per month, typically 30-60 days after shipment, and I want to model that as a recurring cash drag in every scenario.' Starch builds the scenario from your description. It doesn't have a dedicated deductions module, but the natural-language authoring means you're not constrained to what the template anticipated.

Ready to run run a scenario analysis for a strategic decision on Starch?

Request closed-beta access. Everything is free during beta.

You're on the list! We'll be in touch soon.