Most first-time founders build projections backwards. They pick a revenue figure that feels ambitious yet reachable, say Rs 5 crore in year two, then work down to a profit. Investors have seen this a thousand times and distrust it instantly, because the top line is a wish, not a calculation. A driver-based model does the opposite. You define the small set of operational levers that actually produce revenue and cost, you state one assumption for each, and you let the numbers add up. The output is not accurate by luck. It is defensible, because every figure traces back to something you can argue about.
What a driver actually is
A driver is an operational input that, when multiplied out, generates a line in your financials. For a B2B SaaS company, monthly revenue is not an assumption. It is the result of paying accounts multiplied by average revenue per account. Paying accounts, in turn, come from leads multiplied by a conversion rate, minus churn. Each of those is a driver. When an investor asks how you reach a number, you should be able to point at a driver and its assumption, never at the answer itself.
Build the revenue engine first
Lay out the chain that produces revenue, and put an assumption against each link:
- New leads per month, from your channels or from marketing spend divided by cost per lead.
- Lead to paid conversion rate.
- Average revenue per account, by plan or segment.
- Monthly churn, applied to your existing base.
Revenue then becomes opening accounts plus new accounts minus churned accounts, multiplied by average revenue per account. One India-specific discipline here: model revenue net of GST. On SaaS and IT services GST is 18%, but that is collected from your customer and remitted to the government, so it never belongs in your revenue line. If you sell to clients outside India, export of services is zero-rated under an LUT, which changes cash but not your recognised revenue.
Drive costs from the same reality
Costs should move when drivers move, not when you retype a cell. Payroll is usually the largest line, so model it as headcount by role multiplied by a fully loaded cost per role. Fully loaded means more than the offer-letter CTC: add the employer EPF contribution of 12% of basic and dearness allowance, a gratuity accrual, and ESI where an employee earns up to Rs 21,000 a month. If your plan hires four engineers in the third quarter, the cost appears automatically because headcount is a driver, not a hand-typed guess. Do the same for infrastructure, which should scale with usage, and for sales, which should scale with pipeline.
Be honest about tax and cash
Two India-specific traps sink otherwise clean models.
Tax: a DPIIT-recognised eligible startup incorporated before 1 April 2030 can claim a 100% deduction on profits under Section 80-IAC for any three consecutive years out of its first ten. So your model's tax line may legitimately sit near zero in an early profitable year. Do not forget the benefit exists, and do not assume the holiday lasts forever.
Cash: profit is not cash. GST is paid to the government monthly, business customers may deduct TDS from your invoices that you reclaim only later, and receivables often arrive weeks after the sale. A driver-based model keeps the profit and loss view separate from a cash view, so you can read your actual runway, which is the number that decides whether you survive.
Pressure-test, then present
The payoff of drivers is that you can flex them. Drop conversion from 3% to 2% and watch runway shorten. Investors will do exactly this in the room, so do it first. Present the three or four assumptions that matter most, show the base case, and defend each driver with a reason: a published benchmark, a pilot result, or your own trailing data. A model an investor can interrogate, and that still holds up, is worth far more than a bigger number they cannot believe.