DEV Community: Micheal Slyderink

How Much Should a Seed-Stage Founder Pay Themselves? A Python Model Against Runway

Micheal Slyderink — Fri, 06 Nov 2026 13:23:02 +0000

Arron Bennett, Founder of Bennett Financials

Most seed-stage founders set their founder salary once, on the day the money lands, and then feel guilty about it for two years. Too low and you're making decisions while worrying about rent. Too high and you've quietly spent months of runway that should have gone into the product.

The honest answer isn't a benchmark. At seed stage, revenue is small, so the question is how many months of runway each salary costs, measured against your hiring plan.

This post builds that model in plain Python for a hypothetical AI meeting-notes startup that raised $2.5M, has six people, and pays its two founders $60,000 each. Every figure is example math. Tax points are general information, so confirm how they apply to you with your CPA.

Key takeaways

At seed stage, founder salary is a runway decision. Model it in months, not feelings.
Include employer payroll taxes. Every $30,000 raise for two founders costs $64,590 a year, not $60,000.
In this example, $90,000 each keeps 18 months of runway. $120,000 each falls short, unless the hiring plan drops one engineer.
Decide salary and hiring together, because they spend the same cash.

How much founder salary can a seed-stage startup afford?

Enough to live without money stress, and no more than your runway can carry. Model monthly costs, include employer payroll taxes and your hiring plan, and find the highest founder salary that still leaves your target runway, often 18 months or more. Revisit it when you raise funds or revenue grows.

Benchmarks by revenue are useful later. A company with $5 million of revenue can pay its CEO from profit. A seed-stage company with $6,000 of MRR pays its founders from the money investors gave it to build, so cash runway is the constraint.

What goes into a founder salary model?

Cash in the bank, current payroll, planned hires and their start month, benefits per person, other monthly costs, current revenue and a growth rate. Add employer payroll taxes on every salary. Then step month by month until cash runs out, once for each founder salary you're considering.

Employer payroll taxes are the piece people forget. If the founders are on payroll, which they usually are in a C corporation, the company pays 6.2% Social Security and 1.45% Medicare on top of each salary. IRS Publication 15 sets the 2026 Social Security wage base at $184,500. Everyone in this example is under it, so 7.65% applies to all pay. State unemployment taxes are left out to keep it simple.

The model uses only the standard library.

CASH = 2_180_000           # in the bank today, after the $2.5M seed
TEAM_SALARIES = 520_000    # four employees today, per year
HIRES = [(4, 150_000), (4, 150_000)]  # hiring plan: (start month, salary)
OTHER_COSTS = 36_000       # per month: inference, cloud, tools, rent
BENEFITS = 650             # per person per month (health cover)
MRR, GROWTH = 6_000, 0.04  # revenue today and monthly growth
EMPLOYER_FICA = 0.0765     # 6.2% social security + 1.45% Medicare
TARGET = 18                # months of runway you want from today


def runway(founder_salary, founders=2, horizon=60):
    cash, mrr = CASH, MRR
    for month in range(1, horizon + 1):
        hired = [s for start, s in HIRES if month >= start]
        salaries = TEAM_SALARIES + founders * founder_salary + sum(hired)
        heads = 4 + founders + len(hired)
        costs = salaries / 12 * (1 + EMPLOYER_FICA) + BENEFITS * heads + OTHER_COSTS
        cash += mrr - costs
        if cash < 0:
            return month - 1
        mrr *= 1 + GROWTH
    return horizon


base = runway(60_000)
print(f"{'salary each':>12}{'runway':>8}{'vs $60K':>9}  target {TARGET}")
for salary in (60_000, 90_000, 120_000, 150_000):
    months = runway(salary)
    flag = "ok" if months >= TARGET else "SHORT"
    print(f"{salary:>12,}{months:>8}{months - base:>9}  {flag}")

extra = 2 * 30_000 * (1 + EMPLOYER_FICA)
print(f"+$30K each for two founders: {extra:,.0f} a year incl. employer FICA")
HIRES = HIRES[:1]
print(f"one hire instead of two, $120K each: {runway(120_000)} months")

Output:

 salary each  runway  vs $60K  target 18
      60,000      19        0  ok
      90,000      18       -1  ok
     120,000      17       -2  SHORT
     150,000      16       -3  SHORT
+$30K each for two founders: 64,590 a year incl. employer FICA
one hire instead of two, $120K each: 19 months

Runway is the number of full months before cash goes below zero, counting from today. Every figure is pre-tax company cash. Founders' personal income tax comes out of their own pay, not the company's runway.

The constants are where the arguments belong. The growth rate is your revenue forecast in one number, so test it. Set GROWTH to zero and run it again before any board reporting, because that's the scenario planning investors will do in their heads anyway. If the salary you want only works at 4% monthly growth, it isn't affordable yet. It's a bet on the forecast.

This short gives CEO salary ranges by revenue, from $1 million up to $20 million. It's the later-stage view. At seed, before revenue, the model above is how I'd decide instead.

What does the model say about this startup?

At $60,000 each, the company has 19 months. Raising both founders to $90,000 costs one month and still meets the 18-month target. At $120,000 each, runway drops to 17 months, and at $150,000 to 16. The hiring plan does more damage than salary: two engineers starting in month four.

So the honest options are clear:

$90,000 each, with both hires. 18 months of runway, on target.
$120,000 each, with one hire. 19 months, but slower product work.
$60,000 each, with both hires. 19 months and two tired founders.

None of these is the right answer for every company. The point is that the founders and the board can see the trade in months. A salary that keeps a founder focused can be worth one month of runway. It's not worth three.

I'd usually pick the first option. Founders on $60,000 in an expensive city can end up taking side work or making short-term decisions to fix personal cash, and that costs more than a month.

When should founders revisit their salary?

At every round and every time the financial projections change materially. A new raise resets runway and usually justifies a step up. Revenue growth, a lost hire or a cost cut also changes the answer. Re-run the model, agree the result with the board, and write down the trigger for the next review.

A few practical rules I'd add:

Keep founder salaries in the same model as hiring plans, so the trade-off is always visible.
Show potential investors the model. Reasonable founder pay rarely worries them. Unexplained pay does.
Check the result against the 18-month line in a downside scenario too, for example zero revenue growth.

There's more on the early finance decisions in this piece on CFO guidance for startups, and how founder pay sits alongside the cap table in SaaS founder tax strategy.

What should you do on Monday?

Copy the script and replace the constants with your bank balance, payroll, hiring plan and revenue. Run it with the salaries you're considering. Take the output to your co-founder and board, pick a salary that clears your runway target, and set the date you'll review it.

FAQ

Should co-founders be paid the same?

Usually, at seed stage, if they're full time and equally committed. Unequal pay is a conversation to have early and in writing.

Should seed-stage founders take a salary at all?

Yes, once you've raised. A founder under money stress makes worse decisions, and payroll keeps your records clean.

Is a founder salary taxed differently from other wages?

Not usually. A founder on payroll in a C corporation is paid ordinary wages, with income tax withheld and Social Security and Medicare paid on both sides. How salary and equity interact for you is a question for your CPA.

Do founder salaries count toward employer payroll taxes?

Yes, if they're paid as wages. The company pays 6.2% Social Security, up to the wage base, and 1.45% Medicare on top of each salary.

Backlog Forecasting for Engineering Firms: A Python Script That Turns Signed Work Into a Revenue Curve

Micheal Slyderink — Thu, 05 Nov 2026 11:15:16 +0000

Arron Bennett, Founder of Bennett Financials

Ask the owner of an engineering firm how next year looks and you'll usually hear one number: the backlog. "We've got $5.3M signed." It sounds safe. It tells you almost nothing about when that money turns into revenue, and timing is the whole question.

Backlog forecasting fixes that. You take every signed project, spread its remaining fee over the months the work will actually happen, and add the months up. The result is a revenue curve, and the curve usually shows a cliff that the single number hides.

This post builds that curve in plain Python for a hypothetical 44-person MEP engineering firm: $7.1M of revenue last year and $5.3M of signed backlog. Every figure is example math. Swap in your own projects.

Key takeaways

A backlog total says how much work is signed. A burn schedule says when it becomes revenue. You need both.
In this example, $5.3M of backlog is nine months of revenue, yet it covers only 43% of each month from July onward.
The gap to fill over the next 12 months is about $2.04M, which at a 35% win rate means roughly $5.83M of proposals.
Track book to bill monthly. Under 1.0 for a year is how a cliff like this gets built.

What is backlog forecasting?

Backlog forecasting turns signed but unearned fees into a month-by-month revenue forecast. For each project you set the remaining fee, the start month and how long the work will take, then spread the fee across those months. Summing every project by month shows how much of each future month is already covered and how much still has to be won.

The total backlog is a stock. Revenue is a flow. A firm with $5.3M signed can still have a thin summer if most of that money sits in one long hospital job and a handful of projects that finish by spring. That's why I'd rather see the curve than the total.

For project-based firms, the curve is also the best early warning you have. The P&L tells you what happened last month. The backlog curve tells you what will happen in month seven, while there's still time to do something about it.

Why isn't the backlog total enough?

Because it hides timing. "Nine months of backlog" sounds like nine full months of work. In practice, some projects burn fast and finish early, others stretch past the year, and new starts slip. The total stays the same while coverage of specific months collapses. You find out when utilization drops and the team is already on payroll.

It also hides the trend. A backlog that held at $5.3M because you won a lot is different from one that held because projects slowed down. Book to bill, new signed work divided by revenue for the same period, tells you which. Here, say the firm signed $6.4M of new work over the last 12 months against $7.1M of revenue. That's a book to bill ratio of about 0.90. Backlog fell by $700,000 in the year, from about $6.0M to $5.3M.

There's a second source of work the backlog never shows: clients who come back. In this short I talk about repeat rate, how often a client comes back in a year, as the number that lets you predict next year's revenue. For an engineering firm, that's the repeat-client side of this forecast.

What does the Python look like?

One list of signed projects with four fields: name, remaining fee, start month and months to finish. The script spreads each fee evenly across its months, sums the months, and compares each month with last year's monthly revenue. It prints coverage, the monthly gap, the 12-month total and the proposals you'd need at your win rate.

Even burn is a simplification. Real projects ramp up, peak through design development and taper during construction administration. If your project management tool exports planned hours by month, use those instead. The structure doesn't change. Standard library only, and you can paste it and run it.

BACKLOG = [  # signed work: (project, remaining fee $, start month from now, months to finish)
    ("Hospital wing MEP", 1_450_000, 0, 14),
    ("Office tower retrofit", 880_000, 0, 12),
    ("K-12 school renovation", 620_000, 0, 8),
    ("Senior living campus", 560_000, 2, 10),
    ("Lab fit-out", 540_000, 0, 6),
    ("Data center cooling", 410_000, 0, 5),
    ("Municipal library", 300_000, 0, 6),
    ("Hotel renovation", 300_000, 1, 6),
    ("On-call small jobs", 240_000, 0, 12),
]
MONTHS = ["Nov", "Dec", "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct"]
RUN_RATE = 7_100_000 / 12          # last year's revenue, per month
WIN_RATE = 0.35                    # share of proposed fees you win, from your own history

curve = [0.0] * 24
for name, fee, start, months in BACKLOG:
    for m in range(start, start + months):
        curve[m] += fee / months   # even burn schedule; swap in your own

print(f"signed backlog ${sum(f for _, f, _, _ in BACKLOG):,.0f} = "
      f"{sum(f for _, f, _, _ in BACKLOG) / RUN_RATE:.1f} months of revenue")
print(f"{'month':<6}{'from backlog':>14}{'coverage':>10}{'gap':>11}")
gap_total = 0
for i, name in enumerate(MONTHS):
    gap = max(RUN_RATE - curve[i], 0)
    gap_total += gap
    print(f"{name:<6}{curve[i]:>14,.0f}{curve[i] / RUN_RATE:>10.0%}{gap:>11,.0f}")
year = sum(curve[:12])
print(f"next 12 months from backlog ${year:,.0f} ({year / 7_100_000:.0%} of last year)")
print(f"gap to fill ${gap_total:,.0f}; proposals needed at {WIN_RATE:.0%} win rate ${gap_total / WIN_RATE:,.0f}")
print(f"backlog burning after month 12: ${sum(curve[12:]):,.0f}")

Output:

signed backlog $5,300,000 = 9.0 months of revenue
month   from backlog  coverage        gap
Nov          496,405       84%     95,262
Dec          546,405       92%     45,262
Jan          602,405      102%          0
Feb          602,405      102%          0
Mar          602,405      102%          0
Apr          520,405       88%     71,262
May          380,405       64%    211,262
Jun          330,405       56%    261,262
Jul          252,905       43%    338,762
Aug          252,905       43%    338,762
Sep          252,905       43%    338,762
Oct          252,905       43%    338,762
next 12 months from backlog $5,092,857 (72% of last year)
gap to fill $2,039,357; proposals needed at 35% win rate $5,826,735
backlog burning after month 12: $207,143

What does the revenue curve say about this firm?

The firm is full through spring and exposed after it. January to March run at 102% of last year's monthly revenue, so the team is stretched. From May, coverage falls fast, and July to October sit at 43%. The backlog total looked comfortable. The curve shows a summer cliff that new wins have to fill.

Three numbers matter here:

$5,092,857 of the next 12 months is already signed, about 72% of last year's revenue. The rest, $207,143, burns after month 12, mostly the tail of the hospital job.
The gap is $2,039,357. That's the revenue that has to come from work not yet signed, before you even think about growth.
At a 35% win rate, that's roughly $5.83M of proposals. Treat it as a floor. Work you win in June won't all burn by October, so the real pipeline you need is bigger.

The over-coverage in January to March is a signal too. It means overtime, outside help or late deliverables, and a reason to stagger new starts instead of saying yes to every one at once.

How do you use the forecast to make decisions?

Use the coverage line to time hiring, pursuit effort and cash. If coverage six months out is under about 70%, pursuit becomes the priority now, not in month five. If coverage is over 100%, slow new starts or plan the capacity. Review it monthly alongside book to bill and win rate, the key performance indicators that move the curve.

A few rules I'd keep:

Update the start months honestly. Slipped notices to proceed are the most common reason a backlog forecast flatters you.
Keep a separate line for repeat clients. If, say, 60% of last year's $6.4M of signed work came from clients who'd hired you before, that's about $3.84M of next year's pipeline to protect with relationships, not proposals.
Don't hire against the January peak. Hire against the coverage six to nine months out.
Watch cash alongside revenue. Coverage tells you what you'll bill, and your collection days tell you when it turns into operating cash flow.

I've written a longer guide to backlog forecasting for project-based firms, and one on reading the book-to-bill ratio in a service business.

What should you do on Monday?

Export your signed projects with remaining fee, expected start and duration. Paste them into the script, set your own run rate and win rate, and run it. Then look at coverage six months out. If it's under 70%, put pursuit on this week's agenda, and agree who owns which proposals.

FAQ

What is a good book to bill ratio for an engineering firm?

Above 1.0 means backlog is growing, below 1.0 means it's shrinking. A single quarter below 1.0 isn't a crisis. A full year below it, as in this example, is how a revenue cliff gets built.

How many months of backlog should a firm have?

It depends on project length. Months of backlog is a useful headline, but coverage by month is what tells you whether next summer is safe.

Should backlog forecasting use fees or hours?

Fees for the revenue curve, hours for capacity. If your tools hold planned hours by month, convert them to fee and use that shape instead of an even burn.

Marketing Attribution for Small SaaS Teams: Tie Signups to Revenue With Python

Micheal Slyderink — Wed, 04 Nov 2026 13:30:45 +0000

Arron Bennett, Founder of Bennett Financials

Most small SaaS teams can tell you which channel brings the most signups. Very few can tell you which channel brings the most revenue. That gap is what marketing attribution is for, and you don't need an attribution platform to close it. You need two exports and a join.

Signups are easy to count, so they end up running the budget. But a signup isn't revenue. Some channels bring lots of people who never pay. Others bring a few who pay a lot.

This post builds a first-touch attribution report in pandas for a hypothetical bootstrapped job board for travel nurses, where staffing agencies pay a monthly subscription to post jobs. It's at $39,000 of MRR, with four acquisition channels and no attribution at all. Every figure is example data.

Key takeaways

Tag every signup with its first-touch UTM source and store it on the account, not just in your analytics tool.
Join signups to paid invoices by account, and judge channels on revenue in a fixed window, not on signups.
In this example, Google Ads brings the most signups and the least revenue per dollar spent. A newsletter sponsorship brings the fewest signups and the most.
Count untagged signups. If a tenth of your accounts have no source, fix tracking before you move budget.

What is marketing attribution for a small SaaS team?

Marketing attribution is working out which acquisition channel gets the credit for each customer, so you can compare channels on what they bring in. For a small team, first-touch attribution is enough to start: record the UTM source on the first visit that led to a signup, keep it on the account, and later join it to revenue.

There are fancier models: last touch, linear, time decay. They answer questions a team at $39,000 of MRR usually isn't asking yet. The question here is simpler: of the money we spend on each channel, which one comes back as paying customers?

UTM parameters are the plumbing. Google's guide to campaign URLs says to always set utm_source, utm_medium and utm_campaign. For this report, utm_source is the one that matters, and it has to land in your database, not just in an analytics dashboard.

How do you capture the first-touch UTM source?

Read the UTM parameters when a visitor first lands, store them in a first-party cookie or local storage, and write them onto the account record when they sign up. Don't overwrite them on later visits. Then every account carries its first-touch source, and you can join it to billing data whenever you like.

A few rules that save a lot of cleanup later:

Use one spelling per channel. "linkedin", "LinkedIn" and "li" will show up as three channels.
Tag every link you control: ads, sponsorships, emails, social posts.
Leave untagged signups as blank, not "direct". You want to see how many you're missing.

This short isn't about UTM tags. It's about diagnosing marketing with the wrong numbers: if you judge cost per acquisition and lifetime value before pricing and cost of revenue are settled, every marketing metric moves under you. Attribution has the same trap. Judge channels on signups and you're reading the wrong number.

How do you tie signups to revenue in pandas?

Export signups with their account ID, signup date and first-touch source. Export paid invoices with account ID, paid date and amount. Merge them on account ID, keep only invoices paid within 90 days of signup, and group by source. Add each channel's spend for the same period, and you can compare channels on revenue, not signups.

The 90-day window matters. Without it, older channels look better simply because their customers have had longer to pay. With it, every channel gets the same time to prove itself.

The sample data is inline so you can paste it and run it. You'll need pandas.

import io
import pandas as pd

signups = pd.read_csv(io.StringIO("""account_id,signup_date,utm_source
a101,2026-07-03,google_ads
a102,2026-07-08,linkedin
a103,2026-07-11,google_ads
a104,2026-07-15,newsletter
a105,2026-07-19,google_ads
a106,2026-07-22,seo
a107,2026-07-28,
a108,2026-08-02,google_ads
a109,2026-08-05,seo
a110,2026-08-09,linkedin
a111,2026-08-14,google_ads
a112,2026-08-18,newsletter
a113,2026-08-21,linkedin
a114,2026-08-27,google_ads
a115,2026-08-30,seo
a116,2026-09-02,
a117,2026-09-05,google_ads
a118,2026-09-09,newsletter
a119,2026-09-12,linkedin
a120,2026-09-16,google_ads
a121,2026-09-20,seo
"""), parse_dates=["signup_date"])

invoices = pd.read_csv(io.StringIO("""account_id,paid_date,amount
a103,2026-07-25,149
a104,2026-07-29,499
a103,2026-08-25,149
a104,2026-08-29,499
a106,2026-08-05,299
a107,2026-08-11,299
a110,2026-08-23,299
a103,2026-09-25,149
a104,2026-09-29,499
a106,2026-09-05,299
a107,2026-09-11,299
a110,2026-09-23,299
a114,2026-09-10,149
a115,2026-09-13,149
a118,2026-09-23,299
a104,2026-10-29,499
a106,2026-10-05,299
a107,2026-10-11,299
a110,2026-10-23,299
a114,2026-10-10,149
a115,2026-10-13,149
a118,2026-10-23,299
"""), parse_dates=["paid_date"])

spend = {"google_ads": 4500, "linkedin": 2700, "newsletter": 1800, "seo": 1200}  # Jul-Sep

signups["utm_source"] = signups["utm_source"].fillna("(no utm)")
paid = invoices.merge(signups, on="account_id")
paid = paid[paid["paid_date"] <= paid["signup_date"] + pd.Timedelta(days=90)]

by = signups.groupby("utm_source").size().to_frame("signups")
by["paying"] = paid.groupby("utm_source")["account_id"].nunique()
by["revenue"] = paid.groupby("utm_source")["amount"].sum()
by = by.fillna(0).sort_values("revenue", ascending=False, kind="stable")

print(f"{'channel':<12}{'signups':>8}{'paying':>8}{'rev_90d':>9}{'spend':>8}{'cost/payer':>12}{'rev/$':>7}")
for ch, r in by.iterrows():
    sp = spend.get(ch, 0)
    cpp = f"{sp / r.paying:,.0f}" if sp and r.paying else "-"
    rps = f"{r.revenue / sp:.2f}" if sp else "-"
    print(f"{ch:<12}{r.signups:>8.0f}{r.paying:>8.0f}{r.revenue:>9,.0f}{sp:>8,}{cpp:>12}{rps:>7}")
untagged = (signups["utm_source"] == "(no utm)").mean()
print(f"\ntotal: {len(signups)} signups, {paid['account_id'].nunique()} paying, "
      f"{paid['amount'].sum():,} in first-90-day revenue, {untagged:.0%} of signups untagged")

Output:

channel      signups  paying  rev_90d   spend  cost/payer  rev/$
newsletter         3       2    2,095   1,800         900   1.16
seo                4       2    1,195   1,200         600   1.00
(no utm)           2       1      897       0           -      -
linkedin           4       1      897   2,700       2,700   0.33
google_ads         8       2      745   4,500       2,250   0.17

total: 21 signups, 8 paying, 5,829 in first-90-day revenue, 10% of signups untagged

Revenue here is invoices paid in each account's first 90 days. Cost per payer is the channel's spend for the quarter divided by the accounts from that channel that paid at least once. Notice one invoice is missing from the totals: an account's fourth payment landed on day 106, outside the window.

What does the attribution report say about this business?

Google Ads brings the most signups and the least revenue for its spend. It produced 8 of the 21 signups but only $745 of first-90-day revenue on $4,500 of spend, 17 cents per dollar. The newsletter sponsorship produced 3 signups and $2,095 on $1,800, $1.16 per dollar. Ranked by signups, the budget runs backwards.

The detail behind it is common. Google Ads pulls in individual recruiters on the cheapest plan, and many never post a job. The newsletter reaches agency owners who buy the bigger plans. SEO sits in the middle: $1,195 on $1,200 of content spend, and that content keeps working next quarter.

Two more things jump out. LinkedIn costs $2,700 per paying account, the highest of the four. And 10% of signups have no UTM source at all, one of which became an $897 customer. Until that bucket shrinks, every channel's numbers are understated.

In total, the quarter's $10,200 of spend is about $3,400 a month, about 8.7% of MRR, and it brought 8 paying accounts. If you want context on how much to spend in the first place, I've collected research on marketing spend as a share of revenue.

What should you change in the budget?

Move money slowly, toward the channels that bring revenue per dollar, and test before you cut. Shift part of the Google Ads budget to a second newsletter sponsorship for one quarter, keep SEO going, and fix the untagged signups. Then rerun the same report on the next quarter's cohort before moving more.

A few cautions before you act on a report like this:

Small samples lie. A handful of paying accounts per channel is a signal to test, not proof. Run it every quarter and look for the pattern holding.
First touch isn't the whole story. A customer might find you on Google and decide after a newsletter. First touch credits Google. That's fine for a start; just know it.
Revenue isn't profit. If one channel brings customers with much higher hosting or support costs, look at gross margin at the company level too.
Watch retention by channel. Join the same table to cancellations later, and you'll see which channels bring customers who stay.

What should you do on Monday?

Check that every signup in your database has a first-touch source field. If it doesn't, add one this week and start capturing it. Then export last quarter's signups and paid invoices, paste them into the script, add each channel's spend, and read the table. Write down one budget test for next quarter.

FAQ

What is first-touch attribution?

It gives full credit for a customer to the first channel that brought them to your site. It's simple, stable and good enough for a small team comparing a few channels.

Do I need an attribution tool for this?

Not at the start. If you store the UTM source on the account and can export invoices, a short script does the job. Tools help once you have many channels and campaigns.

How long should the revenue window be?

Long enough for a typical customer to pay a few times. Ninety days works for monthly plans. Use the same window for every channel so the comparison is fair.

Engineering Headcount Planning: A Small Python Model for When You Can Afford the Next Engineer

Micheal Slyderink — Tue, 03 Nov 2026 15:08:03 +0000

Arron Bennett, Founder of Bennett Financials

At most bootstrapped companies, engineering headcount planning happens in the founder's head. Revenue is growing, the backlog is growing faster, so you hire. A few months later the bank balance is lower than you expected and you're not sure which decision did it.

A spreadsheet fixes that. So do about 30 lines of Python, which some technical founders will actually keep up to date. This post walks through a small month-by-month cash model for deciding when the next engineer is affordable, using a hypothetical bootstrapped transactional email API at $118,000 of MRR with nine people, planning its 2027 hires.

Key takeaways

Plan hires against monthly cash, not annual profit. The start date of each hire changes the answer.
Use fully loaded cost: salary plus payroll taxes, benefits and equipment. Add a one-time hiring cost in the start month.
Set a cash floor, such as three months of total costs, and treat any month below it as a no.
In this example, one engineer in February is comfortable, a second in June dips under the floor in November, and the same second hire in October doesn't.

What is headcount planning for a bootstrapped SaaS?

Headcount planning is deciding who you'll hire, and when, based on what the business can afford month by month. For a bootstrapped SaaS without investor cash behind it, the binding constraint is the bank balance, not the budget. A good plan shows the lowest cash month for each set of hiring plans before anyone signs an offer.

Annual numbers hide the problem. A hire can look fine across the year and still push one month under the line you've promised yourself. That's why the model below runs month by month.

What inputs does an engineering headcount plan need?

Seven numbers: starting cash, current MRR, monthly growth, variable costs as a share of revenue, today's fixed costs, the fully loaded monthly cost of an engineer, and a one-time hiring cost. Add a cash floor, the minimum you'll let the bank balance fall to. Everything else is a scenario: which start month for which hire.

For the email API, all hypothetical:

Starting cash on January 1, 2027: $420,000.
MRR: $118,000, growing 1.5% a month.
Variable costs, meaning sending infrastructure, payment fees and support tools: 20% of MRR.
Fixed costs for today's nine people, tools and rent: $74,000 a month.
One engineer, fully loaded: $17,500 a month, or $210,000 a year, covering base salary, employer payroll taxes, benefits and equipment.
One-time hiring cost per engineer: $25,000, in the start month.
Cash floor: three months of total costs.

In January the business makes about $20,400 of pre-tax operating profit: $118,000 of MRR, less $23,600 of variable costs and $74,000 of fixed costs. That's the cushion every hire draws on.

The model is pre-tax. Taxes matter, and the 2025 tax law changed them for software teams: domestic development costs can again be deducted in the year you pay them, while offshore development still amortizes over 15 years, per the IRS summary of the law. I've written about how that changes a domestic vs offshore development budget. Add a tax line once your accountant has given you an estimate.

What does the Python model look like?

It's one function that walks through twelve months. Each month it grows MRR, adds the cost of every engineer who has started, takes the hiring cost in the start month, and updates cash. It also tracks headroom, meaning cash above the floor, and reports the tightest month. It's plain Python with no libraries, so paste it and run it.

START_CASH = 420_000   # cash on Jan 1, 2027
MRR0 = 118_000         # January MRR
GROWTH = 0.015         # MRR growth per month
VARIABLE = 0.20        # sending infrastructure, payment fees, support: share of MRR
FIXED = 74_000         # today's 9 people, tools and rent, per month
LOADED = 17_500        # one engineer, fully loaded, per month
RECRUIT = 25_000       # one-time hiring cost in the start month
FLOOR = 3              # months of total costs to keep in the bank

def run(starts):
    cash, tightest, when = START_CASH, None, None
    for m in range(1, 13):
        mrr = MRR0 * (1 + GROWTH) ** (m - 1)
        heads = sum(1 for s in starts if s <= m)
        costs = mrr * VARIABLE + FIXED + heads * LOADED
        cash += mrr - costs - RECRUIT * starts.count(m)
        headroom = cash - FLOOR * costs
        if tightest is None or headroom < tightest:
            tightest, when = headroom, m
    return cash, tightest, when

plans = {
    "no hires": [],
    "1 hire: Feb": [2],
    "2 hires: Feb, Jun": [2, 6],
    "2 hires: Feb, Oct": [2, 10],
    "3 hires: Feb, Jun, Sep": [2, 6, 9],
    "3 hires: all in Feb": [2, 2, 2],
}
for name, starts in plans.items():
    end, low, month = run(starts)
    flag = "ok" if low >= 0 else "BELOW FLOOR"
    print(f"{name:<23} Dec cash ${end:>9,.0f}  tightest headroom ${low:>9,.0f} in month {month:>2}  {flag}")

Output:

no hires                Dec cash $  763,090  tightest headroom $  147,600 in month  1  ok
1 hire: Feb             Dec cash $  545,590  tightest headroom $   73,354 in month  2  ok
2 hires: Feb, Jun       Dec cash $  398,090  tightest headroom $  -13,274 in month 11  BELOW FLOOR
2 hires: Feb, Oct       Dec cash $  468,090  tightest headroom $   56,726 in month 11  ok
3 hires: Feb, Jun, Sep  Dec cash $  303,090  tightest headroom $ -159,808 in month 12  BELOW FLOOR
3 hires: all in Feb     Dec cash $  110,590  tightest headroom $ -352,308 in month 12  BELOW FLOOR

The cash model tells you whether you can afford the engineer. This short is about the other half of the decision, the return each hire should produce, which is the question I'd ask right after.

What does the model say about 2027 hires?

One engineer in February is comfortable. The tightest month still leaves about $73,400 above the floor. A second engineer in June pushes cash about $13,300 under the floor by November. Move that second start to October and the tightest month keeps about $56,700 of headroom. Three hires in 2027 break the floor in both timings tested.

The difference between June and October for the second hire is $70,000 of cash by December: four months of loaded cost at $17,500. Same person, same salary, different start date.

Hiring all three in February is the clearest warning. By December the business is losing about $15,300 a month before tax, and cash is about $352,300 short of the floor. The cash runway hasn't run out yet, but the trend has turned.

None of this means "don't hire". It means sequence the hires so each one starts when the business can carry it, and decide in advance what has to be true before the next offer goes out, such as MRR above a set number.

What should you change before trusting the output?

Replace every input with your own numbers, then stress them. Run growth at half your plan, add a month where a large customer churns, and check what happens if the recruiting fee lands a month before anyone starts. If a hiring plan only clears the floor with optimistic growth, it doesn't clear the floor.

Two things the simple version leaves out on purpose:

Revenue from the new hire. The model assumes none, which is conservative. If an engineer is meant to unlock a feature customers will pay for, add that revenue as its own scenario, starting months after the hire.
Raises and taxes. Add both once you have real numbers for them.

If you later raise funds, this same monthly view becomes the base for your revenue forecast, financial projections, scenario planning and board reporting. The SaaS financial planning framework I use builds on exactly this kind of month-by-month cash model.

What should you do on Monday?

Paste the script, replace the inputs with your real numbers, and add every hire you're considering for 2027 as its own scenario. Pick a cash floor you'd defend to a co-founder. Then write down, for each hire, the MRR level or date that has to be reached before the offer goes out, and put it in the plan.

FAQ

How much cash should a bootstrapped SaaS keep before hiring?

There's no single answer. Three months of total costs is the floor I'd start with for a profitable bootstrapped company. Pick a number you'd defend and stick to it.

What is the fully loaded cost of an engineer?

Base salary plus employer payroll taxes, benefits, equipment and software. Use the monthly figure in the model and add recruiting as a one-time cost in the start month.

Should the model include revenue from the new hire?

Not in the base case. Add it as a separate scenario with a realistic delay, so the decision doesn't depend on revenue that hasn't happened yet.

A Financial Dashboard That Isn't Noise: Five Numbers a Small SaaS Can Pull With Python

Micheal Slyderink — Mon, 02 Nov 2026 13:34:05 +0000

Arron Bennett, Founder of Bennett Financials

Most small SaaS teams I meet have a financial dashboard. Few of them read it. It has a chart for every metric the tool could compute, it moves every day, and nobody can say what it's telling them to do.

Most of a dashboard is expensive noise. It makes you feel busy while the business does whatever it was already going to do. A short list of numbers actually decides whether a company scales or just gets bigger and poorer.

This post builds that short list in plain Python, using a hypothetical bootstrapped online-booking SaaS for escape rooms at $46,000 of MRR, five people, and a dashboard with 23 charts nobody reads.

Key takeaways

Five company-level numbers cover most of what a small SaaS needs to steer by: growth, gross margin, sales and marketing as a share of revenue, pre-tax operating margin and months of cash.
Compare three-month windows, not single months. Quarterly trends are signal; monthly moves are mostly noise.
Set a target for each number before you look, and flag only what misses.
In this example, five numbers show what 23 charts hid: marketing spend rose sharply and growth barely moved.

What should a financial dashboard for a small SaaS show?

A handful of financial metrics that each lead to a decision. For a small SaaS, I'd start with five: monthly revenue growth, gross margin, sales and marketing as a share of revenue, pre-tax operating margin, and months of costs in the bank. If a number can't change what you do next month, leave it off.

Everything else, such as traffic, sign-ups, feature usage and support tickets, belongs to the team that runs it. It can live in their tools. The financial dashboard is for the few key performance indicators that tell you whether the business is getting healthier.

Notice what's not on the list: anything per customer. You don't need customer-level economics to see whether the company is on track. Company totals from your books are enough, and they're numbers your accountant already produces.

Why are 23 charts worse than five numbers?

Because more charts means more noise, and noise hides signal. Daily and monthly numbers jump around for reasons that don't matter: a big annual renewal, a holiday month, a vendor bill paid early. With 23 charts, something is always up or down, so nothing stands out, and the one real trend gets lost.

The fix is two habits. First, prune to the numbers that drive decisions. Second, compare windows, not points. Three months against the three months before is long enough to smooth out monthly noise and short enough to catch a trend while you can still act on it. That's signal vs noise in one rule.

In this short I rank the numbers I'd actually steer a business by, starting with gross margin, the one most owners get wrong by a mile.

What does the Python look like?

One CSV export with a row per month and six columns: month, revenue, cost of revenue, sales and marketing, other operating costs and ending cash. Most accounting tools can export a monthly P&L, and the bank balance comes from your statements. The script computes the five numbers for two three-month windows and flags any that miss your targets.

Mapping your accounts into those four cost buckets is the only fiddly part. Cost of revenue is hosting, payment processing and support. Sales and marketing includes salaries and tools, not just ads. Everything else goes in other operating costs. If your chart of accounts makes that hard, that's worth fixing on its own, and it's one of the more common SaaS accounting problems I see.

The script uses only the standard library. The sample data is inline so you can paste it and run it.

import csv, io

CSV = """month,revenue,cost_of_revenue,sales_marketing,other_opex,ending_cash
2026-05,40800,8900,4900,23800,234200
2026-06,41900,9100,5300,23800,237900
2026-07,42700,9500,6400,24100,240600
2026-08,43900,9800,7100,24100,243500
2026-09,45100,10200,7600,24400,246400
2026-10,46000,10600,8200,24700,248900
"""

TARGETS = {  # your own lines: (target, "min" or "max")
    "MRR growth per month": (0.020, "min"),
    "gross margin": (0.75, "min"),
    "sales & marketing % of revenue": (0.15, "max"),
    "pre-tax operating margin": (0.10, "min"),
    "months of costs in the bank": (6.0, "min"),
}

rows = list(csv.DictReader(io.StringIO(CSV)))  # or: csv.DictReader(open("export.csv"))
for r in rows:
    for k in r:
        if k != "month":
            r[k] = float(r[k])


def five_numbers(rs):
    rev = sum(r["revenue"] for r in rs)
    cor = sum(r["cost_of_revenue"] for r in rs)
    sm = sum(r["sales_marketing"] for r in rs)
    costs = cor + sm + sum(r["other_opex"] for r in rs)
    growth = (rs[-1]["revenue"] / rs[0]["revenue"]) ** (1 / (len(rs) - 1)) - 1
    return {
        "MRR growth per month": growth,
        "gross margin": (rev - cor) / rev,
        "sales & marketing % of revenue": sm / rev,
        "pre-tax operating margin": (rev - costs) / rev,
        "months of costs in the bank": rs[-1]["ending_cash"] / (costs / len(rs)),
    }


before, now = five_numbers(rows[:3]), five_numbers(rows[3:])
print(f"{'number':<32}{'May-Jul':>9}{'Aug-Oct':>9}{'target':>9}  flag")
for name, (target, kind) in TARGETS.items():
    b, n = before[name], now[name]
    ok = n >= target if kind == "min" else n <= target
    fmt = (lambda x: f"{x:.1f}") if "months" in name else (lambda x: f"{x:.1%}")
    sign = ">=" if kind == "min" else "<="
    print(f"{name:<32}{fmt(b):>9}{fmt(n):>9}{sign + fmt(target):>9}  {'ok' if ok else 'CHECK'}")

Output:

number                            May-Jul  Aug-Oct   target  flag
MRR growth per month                 2.3%     2.4%   >=2.0%  ok
gross margin                        78.1%    77.3%  >=75.0%  ok
sales & marketing % of revenue      13.2%    17.0%  <=15.0%  CHECK
pre-tax operating margin             7.7%     6.1%  >=10.0%  CHECK
months of costs in the bank           6.2      5.9    >=6.0  CHECK

Growth is the compound monthly growth across each window. Months of costs in the bank is ending cash divided by average monthly total costs in that window. Everything is pre-tax.

What do the five numbers say about this business?

Marketing spend jumped and growth didn't follow. Sales and marketing went from 13.2% of revenue to 17.0%, past a 15% line. Monthly growth barely moved, from 2.3% to 2.4%. Pre-tax operating margin fell from 7.7% to 6.1%, and months of costs in the bank slipped under six.

In dollars, the team spent $6,300 more on sales and marketing in August to October than in May to July, about $2,100 a month. That spend bought almost no extra growth. Gross margin slipped a little, from 78.1% to 77.3%, which is worth watching but still clears the target.

Each of those numbers was somewhere in the 23 charts. Nobody saw them together, because they were spread across tabs and each one moved a bit every day. Five lines with a target and a flag make the story obvious in ten seconds.

The decision follows from it. Find out which channel took the extra $2,100 a month, give it one more month with a clear test, and cut it if growth doesn't move. That's the job of a dashboard: to start the right conversation, quickly.

How do you stop the dashboard growing back to 23 charts?

Make every number earn its place. Before adding a metric, write down the decision it would change and the target that would trigger it. If you can't, don't add it. Review the list once a quarter and drop anything nobody has acted on. Five numbers read monthly beat fifty glanced at daily.

A few practical rules I'd add:

Keep the targets in the code, next to the numbers, so they're reviewed together.
Run it once a month after the books close, not daily. Daily runs bring the noise back.
Add a sixth number only when the business changes, for example net cash flow once you start borrowing, or close rate once you hire salespeople.

If you want a longer list to choose from, here are ten financial KPIs worth knowing. Pick the ones that match decisions you actually make.

What should you do on Monday?

Export six months of P&L by month, add the ending bank balance for each, and map your accounts into the four cost buckets. Paste the script, swap in your CSV, and set your own targets. Then read the five lines with your co-founder or team and agree on one action for any number that misses.

FAQ

What is the most important number on a SaaS financial dashboard?

Gross margin. It decides how much of every revenue dollar is left to fund growth and overhead. If it's weak, every other number has less room to work.

How often should a small SaaS review its financial dashboard?

Monthly, after the books close. Compare the last three months with the three before, so a single unusual month doesn't drive a decision.

Should operating cash flow be on the dashboard?

For most small SaaS companies, months of costs in the bank and pre-tax operating margin cover it. Add operating cash flow when timing gaps grow, such as annual prepayments or slow-paying customers.

SaaS Due Diligence: What Buyers Will Ask a Technical Founder For

Micheal Slyderink — Fri, 30 Oct 2026 12:55:44 +0000

Arron Bennett, Founder of Bennett Financials

The letter of intent feels like the finish line. It isn't. It's the start of due diligence, the 45 to 90 days where a buyer checks everything you told them, and often finds a few things you didn't.

Technical founders tend to expect the code review and dread the finance questions. In practice, the code is rarely what moves the price. Messy revenue data, missing paperwork and a couple of large customers do that.

This post covers what buyers ask for, how to rebuild your MRR history in SQL before they do, and the findings that most often cut the price.

Key takeaways

Due diligence checks revenue quality, the code and its ownership, contracts and people. Revenue is where most price cuts start.
Have a month-by-month MRR rollforward ready: new, expansion, contraction and churn. It should tie to your billing system and your books.
Every contractor and employee who wrote code should have signed an IP assignment. Missing ones get fixed before closing, at your cost.
Customer concentration, deferred revenue and open-source licences are the usual surprises.

What is SaaS due diligence?

SaaS due diligence is the buyer's check of your business after you sign a letter of intent and before the deal closes. They verify revenue and retention, review the code and who owns it, read customer and vendor contracts, and look at security, infrastructure and people. Anything that doesn't match what you told them becomes a price cut, an escrow or a reason to walk away.

What financial data will buyers ask for?

Expect requests for monthly P&L and balance sheets for two to three years, a customer list with MRR by customer, an MRR rollforward, churn and retention by cohort, deferred revenue, and your billing system export. The buyer will rebuild your numbers from raw billing data. If their numbers don't match yours, they'll trust theirs.

That's why the most useful thing you can do before a sale is build the rollforward yourself. This query works on a table with one row per customer per month and their MRR that month (PostgreSQL):

-- MRR rollforward: new, expansion, contraction and churn by month
WITH m AS (
  SELECT customer_id, month, mrr,
         LAG(mrr) OVER (PARTITION BY customer_id ORDER BY month) AS prev_mrr,
         LAG(month) OVER (PARTITION BY customer_id ORDER BY month) AS prev_month
  FROM customer_mrr            -- one row per customer per month with mrr >= 0
)
SELECT month,
  SUM(CASE WHEN prev_mrr IS NULL OR prev_month < month - INTERVAL '1 month'
           THEN mrr ELSE 0 END)                                   AS new_mrr,
  SUM(CASE WHEN prev_mrr > 0 AND mrr > prev_mrr
            AND prev_month = month - INTERVAL '1 month'
           THEN mrr - prev_mrr ELSE 0 END)                        AS expansion,
  SUM(CASE WHEN prev_mrr > 0 AND mrr > 0 AND mrr < prev_mrr
            AND prev_month = month - INTERVAL '1 month'
           THEN mrr - prev_mrr ELSE 0 END)                        AS contraction,
  SUM(CASE WHEN prev_mrr > 0 AND mrr = 0
            AND prev_month = month - INTERVAL '1 month'
           THEN -prev_mrr ELSE 0 END)                             AS churn,
  SUM(mrr)                                                        AS ending_mrr
FROM m
GROUP BY month
ORDER BY month;

For this to count churn, a cancelled customer needs a row with mrr = 0 in the month after they leave. A returning customer after a gap shows as new MRR, which is how most buyers treat reactivations. Check that each month's opening MRR plus new, expansion, contraction and churn equals the ending MRR. Then check the totals tie to revenue in your books. If they don't, find out why before the buyer does.

What will buyers check in the code?

Less about style, more about risk. Expect questions on:

Ownership. Who wrote the code, and did each of them sign an IP assignment?
Open-source licences. A scan for copyleft licences that could force you to release your own code if you distribute it.
Security. Past incidents, pen test results, access controls and how secrets are stored.
Infrastructure. What it costs to run, what's documented, and whether it depends on one person's personal accounts.
Bus factor. Whether the product survives if one engineer, often you, leaves after the sale.

Run a licence scan and list every person who's committed code before you list the company. Both are cheap to do early and slow to do mid-deal.

What findings cut the price?

Here's a hypothetical example. Every number is made up to show the mechanics.

A compliance-automation SaaS has $1.43 million of ARR. A buyer signs an LOI at 4.2 times ARR, about $6.0 million. Diligence finds three issues.

Deferred revenue. Customers prepaid $310,000 for service still to be delivered. The buyer will have to deliver it without being paid again, so they treat it as a debt-like item and want it deducted from the price.
IP assignments. Two former contract developers never signed one. The buyer makes signed assignments a condition of closing.
Customer concentration. One customer is 14% of ARR, with a contract that renews in four months.

After negotiation, the founders agree to a $5.6 million price and pay a lawyer to track down the two contractors. They also lose a few weeks. The code review, which they'd worried about most, found nothing that changed the price.

I talk about the gap between a business that's an asset and one that's a job in this video. Buyers pay for the asset. Diligence is how they find out which one they're buying.

How do you prepare before you sell?

Start six to twelve months before you plan to sell. Build the MRR rollforward and reconcile it to your books. Collect signed IP assignments from everyone who has written code. Run a licence scan. Move infrastructure out of personal accounts. Write down how to deploy and run the product. Reduce your reliance on any one customer where you can. And know which items on your balance sheet a buyer will treat like debt. I've written a fuller guide on debt-like items in a business sale.

What should you do on Monday?

Run the rollforward query on your billing data and check it against last year's revenue in your books. Then list every person who has committed to your main repository and confirm you have a signed IP assignment for each. Those two checks catch the problems that most often cost founders money in diligence.

FAQ

How long does SaaS due diligence take?

Often 45 to 90 days from the signed LOI, longer if the data room is incomplete or the buyer finds issues that need fixing.

What is a data room?

A shared folder of documents buyers review during diligence: financials, contracts, cap table, IP assignments, security reports and policies.

Do buyers review the source code?

Usually, either directly or through a third-party code scan for licences, security and quality. Smaller buyers sometimes rely on a scan and a call with the lead engineer.

Why is deferred revenue treated as debt in a sale?

Because the buyer must deliver service customers have already paid for, without receiving that cash. Some buyers deduct the full amount and some only the cost to deliver it, so it's a point to negotiate.

Venture Debt for SaaS Founders: How It Works and When It Turns Dangerous

Micheal Slyderink — Thu, 29 Oct 2026 12:40:45 +0000

Arron Bennett, Founder of Bennett Financials

A few weeks after a Series A closes, the term sheets start arriving. Not from investors. From lenders. "Add $3 million of runway with minimal dilution." It sounds like free time.

It isn't free, and it usually isn't as much time as it sounds. Venture debt can be a smart tool for a SaaS company with strong unit economics and a clear plan. It can also turn a slow quarter into a crisis, because a lender, unlike an investor, can ask for the money back.

This post covers how venture debt works, how much runway it really adds, a short Python model you can run on your own numbers, and the terms that make it dangerous.

Key takeaways

Venture debt is a term loan for venture-backed companies, usually with an interest-only period, then monthly principal payments, plus fees and warrants.
It adds less runway than the headline suggests, because repayments start before most companies raise again.
It's cheapest and safest when it funds growth with a known payback, not when it's the plan for survival.
Read the covenants and the default clauses before the interest rate. They decide how dangerous the loan is.

What is venture debt?

Venture debt is a loan to a venture-backed startup, usually sized as a fraction of the last equity round. Typical terms include an interest-only period, then monthly principal repayments, a final payment fee and warrants that give the lender a small right to buy equity. It costs less dilution than equity, but it must be repaid on schedule whatever happens to growth.

Lenders lend because your investors just backed you. The equity round is their comfort. That's also why the timing of your next round matters so much.

How do venture debt terms work?

Most venture debt offers have the same moving parts:

Draw period: how long you have to take the money.
Interest-only period: months where you pay only interest.
Amortization: after interest-only ends, principal is repaid in equal monthly amounts.
Final payment fee: a percentage of the loan paid at the end.
Warrants: a right for the lender to buy a small amount of equity.
Covenants: rules you must keep, such as a minimum cash balance or revenue targets, plus default clauses like a "material adverse change" clause.

The interest rate gets the attention. The covenants and default clauses decide what happens when things go wrong.

How much runway does venture debt really add?

Less than cash ÷ burn suggests. Interest starts on day one, and principal payments usually begin twelve months or so later, often right when you'd be raising the next round. This model shows the effect. It's simplified: fixed rate, the loan drawn on day one, flat net burn.

def runway_months(cash, net_burn, loan=0.0, rate=0.11, interest_only=12,
                  amort_months=30, final_fee=0.04):
    """Months until cash runs out, with an optional term loan drawn today."""
    cash += loan
    balance, month = loan, 0
    while True:
        month += 1
        interest = balance * rate / 12
        principal = 0 if month <= interest_only else min(balance, loan / amort_months)
        out = net_burn + interest + principal
        if loan and month == interest_only + amort_months:
            out += loan * final_fee
        if out > cash:
            return month - 1 + cash / out   # fraction of the last month
        cash -= out
        balance -= principal

print(f"No debt:   {runway_months(8_800_000, 400_000):.1f} months")
print(f"$3M loan:  {runway_months(8_800_000, 400_000, loan=3_000_000):.1f} months")

Output:

No debt:   22.0 months
$3M loan:  24.8 months

Swap in your own cash, burn and the terms on your offer. Then add a version where burn rises, because it usually does once the money lands.

What does that look like for a real SaaS company?

Here's a hypothetical example. Every number is made up to show the mechanics.

A Series A observability SaaS has $4.1 million in ARR, $8.8 million in the bank and $400,000 a month of net burn. That's 22 months of runway. A lender offers $3 million: 11% interest, 12 months interest-only, 30 months of principal repayments, a 4% final payment fee and warrants.

Naive math says $3 million is 7.5 more months. The model says 2.8.

Interest over the life of the loan comes to about $756,000.
The final payment fee is $120,000.
At month 22, when the company would have run out of cash without the loan, it still owes $2 million.

So the founders would pay about $876,000 in interest and fees, plus warrants, for under three extra months, and enter their Series B process with $100,000 a month of principal going out the door.

That doesn't make the loan a bad idea. It makes it a bad idea for buying time. It can be a good idea for buying growth.

When is venture debt a good idea?

Venture debt works best when it funds something with a known, fast payback. If every dollar of sales and marketing comes back within twelve months and customers stay for years, borrowing to spend more of those dollars sooner can be cheaper than raising equity for it.

This video isn't about venture debt. It's about the moment when holding cash back costs more than spending it, which is the same test I'd apply to borrowed money.

It's also reasonable as insurance: drawn only if a round takes longer than planned, with terms that allow that. Some lenders let you draw later in the draw period, which keeps interest down until you need the money.

When does venture debt turn dangerous?

It turns dangerous when growth slows and the loan's rules start to bite. Watch for:

Minimum cash covenants. A covenant that requires you to keep, say, a set amount of cash in the bank shrinks your usable runway by that amount.
Revenue or performance covenants. Miss a target and you're in default, even if you're paying on time.
Material adverse change clauses. Broad wording can let the lender call the loan if they decide your prospects worsened.
Repayments that start before the next round. If principal starts at month 12 and your raise slips to month 20, you're repaying debt with the cash meant to get you there.
Banking requirements. Many lenders require your operating accounts at their bank. After the 2023 bank failures, founders understand why that concentration matters.

A default doesn't mean the lender takes the company the next morning. It does mean the conversation is on their terms, at the worst possible time.

What should you do on Monday?

Run the model with your real cash, burn and offer terms. Then run it again with burn 20% higher and your next round six months late. If the loan only works in the first version, don't sign it. If you go ahead, send the covenants, default clauses and warrant terms to your lawyer before you negotiate the rate. If you're also weighing other non-dilutive options, I've written about how a line of credit and its borrowing base work.

FAQ

Is venture debt cheaper than equity?

Usually less dilutive, not always cheaper. Interest, fees and warrants are real costs, and repayments compete with growth for cash. It's cheapest when it funds growth with a fast, proven payback.

When should a startup take venture debt?

Typically soon after an equity round, while the company has plenty of cash and the lender is comfortable. Taking it when you're already low on cash usually means worse terms.

What are warrants in venture debt?

A right for the lender to buy a small amount of equity, usually at the last round's price. It's a small dilution, but it's part of the cost.

Can venture debt be repaid early?

Often, yes, but many loans charge a prepayment fee. Check the terms before you assume you can refinance or repay after your next round.

Your Stripe Payouts Are Not Your Revenue: How to Reconcile Stripe to Your Books

Micheal Slyderink — Tue, 27 Oct 2026 13:35:45 +0000

Arron Bennett, Founder of Bennett Financials

Most bootstrapped SaaS books I open have the same quiet error. Every Stripe payout landed in the bank, and someone booked each one as revenue. The bank matches. The books look clean. The revenue number is still wrong, and so is every margin built on top of it.

A Stripe payout isn't a sale. It's a bundle of sales, minus fees, minus refunds, minus disputes, sent a few days after the money came in. This post covers what a payout actually contains, how to split one apart with a short script, and the bookkeeping setup that keeps the two in step.

Key takeaways

A Stripe payout is a net number. Gross charges, Stripe fees, refunds and disputes are all inside it.
Booking payouts as revenue understates revenue, hides fees, and buries refunds.
Book gross charges as revenue and fees as an expense, then run both through a Stripe clearing account.
The balance transactions API (or the Payout reconciliation report) tells you exactly what each payout contains.

What does Stripe reconciliation actually mean?

Stripe reconciliation means proving that every payout in your bank equals the charges, fees, refunds and disputes Stripe says made it up, and that each piece is booked in the right account. Revenue goes to revenue, fees to expenses, refunds against revenue. When the clearing account nets to zero, you're reconciled.

Your bank only ever sees the net. Your books need the gross.

Why are Stripe payouts not the same as revenue?

Stripe takes its fees out before it pays you. Refunds and lost disputes come out of the same balance, and payouts arrive on a schedule, so charges from the last days of a month land in next month's bank account. Book the deposit as revenue and every one of those differences disappears into a single wrong number.

Here's a hypothetical example. A two-founder developer-docs hosting SaaS at $29,000 of MRR, all on Stripe. Every number below is made up to show the mechanics. Swap in yours.

In one month the business charges customers $31,200. It refunds $640, loses one $480 dispute plus a $15 dispute fee (an assumed figure, so check your own), and pays $1,150 in processing fees.

So the payouts total $28,915, which is $31,200 − $640 − $480 − $15 − $1,150.

If the bookkeeper records $28,915 as revenue, revenue is understated by $2,285. That's $1,165 of fees and dispute costs that never show up as an expense, and $1,120 of refunds and lost disputes that never show up as anything. The fees alone are 3.7% of gross, and they have no line on the P&L.

How do you see what's inside a Stripe payout?

Every movement in your Stripe balance is a balance transaction with a gross amount, a fee and a net, all in the smallest currency unit, so cents for USD. For automatic payouts, you can list every balance transaction that was paid out in one payout and group them by reporting_category.

Here's a minimal Python version. Use a restricted, read-only key.

import os
from collections import defaultdict
import stripe

stripe.api_key = os.environ["STRIPE_READ_KEY"]  # restricted, read-only

def explain_payout(payout_id):
    payout = stripe.Payout.retrieve(payout_id)
    totals = defaultdict(lambda: {"gross": 0, "fee": 0, "net": 0})
    txns = stripe.BalanceTransaction.list(payout=payout_id, limit=100)
    for t in txns.auto_paging_iter():
        if t.type == "payout":
            continue  # the payout itself, not what's inside it
        row = totals[t.reporting_category]
        row["gross"] += t.amount
        row["fee"] += t.fee
        row["net"] += t.net
    net_sum = sum(r["net"] for r in totals.values())
    for cat, r in sorted(totals.items()):
        print(f"{cat:<12} gross {r['gross']/100:>11,.2f}  fee {r['fee']/100:>9,.2f}  net {r['net']/100:>11,.2f}")
    print(f"payout {payout.amount/100:,.2f} | sum of nets {net_sum/100:,.2f} | match: {net_sum == payout.amount}")

explain_payout("po_...")

The last line is the check that matters. If the sum of nets equals the payout amount, you know exactly what's in that deposit. If it doesn't, the gap is something you need to find, such as an adjustment, a reserve or a manual payout. The payout filter only works for automatic payouts. If you trigger payouts by hand, use the Payout reconciliation report in the Stripe Dashboard instead.

You don't need to run this on every payout forever. Run it on one month, prove the method, then let your bookkeeping tool's Stripe integration or a monthly report do the routine work.

How should Stripe be set up in the books?

Treat Stripe like a bank account. Create a "Stripe clearing" account, record gross charges into it as revenue, take fees out of it as an expense, take refunds out of it against revenue, and record each payout as a transfer from clearing to the bank. At month end, the clearing balance should equal the Stripe balance.

For the docs-hosting example, the month books like this:

Revenue: $31,200 of gross charges.
Refunds and lost disputes: $1,120, against revenue.
Payment processing fees: $1,165, as an operating expense.
Transfers to the bank: $28,915, which revenue never touches.

The clearing account goes up by $31,200 and down by $1,120, $1,165 and $28,915, so it lands on zero. If payouts lag the month end, it won't be zero. It'll equal whatever Stripe still holds for you, and that's correct. A balance that drifts every month means something is being missed.

One more thing worth watching. If Stripe ever holds a reserve on your account, that money is yours but you can't spend it. It belongs in clearing, not in your cash forecast. I've written more on processor reserves and available cash.

This short isn't about Stripe. It's about the same gap from the other side: a profitable P&L and a bank account that can't cover payroll. That gap is the reason I want the books and the bank telling the same story.

What changes when the books are right?

Three things get honest at once. Revenue shows what customers really paid. Processing fees show up as a cost you can manage. And refunds become visible, so a product or onboarding problem stops hiding inside a smaller deposit.

That matters the first time you look at gross margin, price a plan, or talk to anyone who will read your numbers closely, such as a lender, an investor or a buyer. Diligence on a SaaS business reconciles Stripe to the bank and the books. Better that you find the gaps first.

It also makes refunds a number you can act on. If you find refunds climbing, look at failed payments and recovery in the same review. Both are revenue leaving quietly.

What should you do on Monday?

Pick last month. Pull every payout, run the script or the Payout reconciliation report, and total gross charges, fees, refunds and disputes. Compare gross charges with the revenue in your books. If the books show the payout total instead, set up a Stripe clearing account and rebook the month the right way. Then make it the rule for every month after.

It's a two-hour job. It fixes your revenue line for good.

FAQ

Should I record Stripe fees as an expense or net them against revenue?

Record them as an expense. Revenue should be what customers paid. Fees are a cost of collecting it, and you can only manage a cost you can see.

Why doesn't my Stripe payout match my sales for the month?

Because payouts are net of fees, refunds and disputes, and they arrive on a schedule. Sales from the last few days of a month often land in next month's bank deposits.

Does a Stripe payout include refunds and disputes?

Yes. Refunds and lost disputes reduce your Stripe balance, so they come out of the next payout. A payout can even come out negative if refunds outrun charges.

Do I need software to reconcile Stripe?

Not to start. The Payout reconciliation report or a short script covers one month. After that, most accounting tools' Stripe integrations can post gross, fees and refunds for you, once the clearing account is set up.

Finding a CFO for Tech Startups: A Practical Guide for Developers & Technical Founders (2025)

Micheal Slyderink — Fri, 14 Nov 2025 13:15:14 +0000

Technical founders tend to delay hiring a CFO for the same reason they delay hiring DevOps or QA: it feels faster to handle things themselves. That works in the earliest stages, but once you pass around $1M to $2M in revenue, finance becomes a scaling problem just like engineering. The moment you’re thinking about runway, hiring, pricing changes, fundraising, or subscription complexity, “DIY finance” stops being safe.

A CFO brings the same discipline to your financial system that an engineering lead brings to your codebase. They turn scattered spreadsheets into real models, translate billing data into predictable metrics, and redesign your financial processes so you can grow without breaking something critical.

Most developers realize they need a CFO when they can’t see more than a few months of cash runway. If your best forecast is a spreadsheet that collapses when one input changes, you’re working without version control. A CFO builds a rolling 13-week cash model that updates consistently and helps you understand exactly when you need to raise, slow down, or accelerate. They also take on the heavy lifting of investor prep, data rooms, due-diligence requests, and the financial side of fundraising—things that become extremely time-consuming for technical founders.

Another sign you’re ready is billing complexity. Usage-based pricing, hybrid plans, and multi-year contracts all introduce revenue recognition rules that matter for SaaS. If your revenue logic feels more like code than accounting, you need someone who understands ASC 606 and how your billing system connects to your metrics. Getting this wrong can wreck your ARR, churn reporting, and investor conversations.

For most early-stage startups, a fractional CFO makes more sense than a full-time hire. Fractional CFOs give you the forecasting, dashboards, investor support, and tax strategy of a true finance leader without the $200K–$350K salary or equity dilution. You get a senior strategist without having to build a full finance team. Once you’re past Series A and growing headcount, a full-time CFO becomes more important—but not before.

The real test when evaluating a CFO is whether they can think through your business like a system. Give them a small anonymized example of your numbers, and see how they explain what’s happening. A strong candidate will reason like an engineer: identify constraints, question assumptions, and walk through how one change affects the whole architecture. Avoid candidates who only talk in generalities or who rely exclusively on spreadsheets without understanding automation or integrations.

The first 90 days with a good CFO should feel like moving from ad-hoc scripts to stable infrastructure. Your books should close within ten days. Your cash forecast should finally be something you trust. Your metrics should be consistent across accounting, billing, and product. And you should have a clear, data-driven view of your path to the next milestone—whether that’s profitability, $10M ARR, or your next raise.

If you're a developer or technical founder, think of hiring a CFO the same way you think about hiring your first senior engineer. It’s not about giving up control—it’s about building a system that scales faster than you can. When the financial side of the business becomes too complex to “quickly patch,” that’s when a CFO becomes one of the highest-leverage hires you can make.

The Top 15 Fractional CFO Services (For Founders Who Think in Systems)

Micheal Slyderink — Tue, 11 Nov 2025 14:16:57 +0000

Bennett Financials — The Full-Stack Finance Partner

Bennett Financials isn’t an accounting firm pretending to be strategic.
We’re system thinkers who treat your finance stack like your tech stack.

Here’s how:

Architecture First: We map your entire financial infrastructure — cash flow, pricing logic, team costs, capital usage — just like a dev audits dependencies and services.

Real-Time Dashboards: Live metrics (profitability, margin, burn, velocity) built to show actual performance drift, not static reports.

Tax Strategy as Engineering Optimization: We find the equivalent of code efficiency inside your taxes — reducing cash taxes by 40–60% so your growth capital isn’t wasted on the IRS.

API Mindset: We integrate finance data across your systems (QuickBooks, Stripe, Gusto, HubSpot, etc.) so you’re not trapped in spreadsheet hell.

We help founders scale from $1M to $10M+ without breaking the backend — financially or operationally.

👉 Book a call here
to see how we’d build your financial system for scale.

Pilot

Automation-heavy bookkeeping with CFO support. Great for early-stage SaaS founders who value speed and clean dashboards.

Kruze Consulting

Fundraising and VC prep pros — perfect for seed-to-Series-B startups.

CFOshare

Excellent for scaling ops and ERP integration at mid-market level.

NOW CFO

Focuses on rolling 13-week cash flow forecasts — good for dev shops managing project-based revenue.

Preferred CFO

Senior operators with corporate finance backgrounds. Hands-on strategy and restructuring.

Acuity

Built for SaaS founders managing deferred revenue and ARR growth metrics.

…and the rest of the top 15 follow suit — all credible firms with solid offerings.
But none blend strategic finance, tax efficiency, and data intelligence quite like Bennett Financials.

Why Devs and Founders Love Working With Us

Because we think like you do.
We debug numbers the same way you debug code.

Our clients don’t want more reports — they want visibility.
They want a system that tells them, “Here’s what’s working. Here’s what’s leaking. Here’s what to fix.”

We bring clarity to chaos using tools, automation, and financial frameworks that scale.
You get proactive strategy, not reactive accounting.

The Developer’s ROI Equation

Hiring a full-time CFO? Expect $200K+ in salary before equity and benefits.

A fractional CFO through Bennett Financials delivers the same strategy at $60K–$120K annually, fully scalable based on stage and scope.

The ROI?
Every technical founder we work with learns exactly how financial decisions drive runway, hiring, pricing, and margin stability — so growth stops feeling like a guessing game.

Final Commit: Build Financial Systems That Scale

Your product has architecture.
Your infrastructure has architecture.
Your finances need one too.

That’s where we come in.
We help founders and dev teams build financial systems that don’t crash under scale.

👉 Read the full breakdown here

👉 Book a consultation
if you’re ready to scale smarter.

Why SaaS Companies Grow Faster with a Fractional CFO

Micheal Slyderink — Mon, 10 Nov 2025 13:43:52 +0000

SaaS growth is exciting until your numbers stop making sense. You’ve got rising MRR, new hires, maybe even investor interest—but somehow, cash flow still feels unpredictable. That disconnect usually isn’t about performance; it’s about forecasting.

A fractional CFO helps SaaS founders replace reactive financial management with proactive control. Instead of guessing at runway, you see it clearly. Instead of scaling based on gut feeling, you model your growth in advance.

For most SaaS companies between $1M and $10M ARR, hiring a full-time CFO doesn’t make financial sense yet. A fractional CFO gives you executive-level clarity at a fraction of the cost—building forecasts, cash models, and investor-ready reports that make scaling sustainable.

They turn data into strategy, showing how churn, pricing, CAC, and headcount all flow through to real profitability. You stop running on hope and start running on visibility.

At Bennett Financials, we work with scaling SaaS companies to connect financial strategy with product growth. Our team builds forecasting and budgeting systems that give founders what they need most—confidence in every decision.

Learn more at Bennett Financials: https://bennettfinancials.com/fractional-cfo-services-for-budgeting-and-forecasting-excellence/

Connect with Arron on LinkedIn: https://www.linkedin.com/in/arron-bennett/

Book a consultation: https://bennettfinancials.com/contact-us/