How to write a tech budget into a grant proposal - and get it approved

The proposal is due Friday. The programmes section is strong. Staff costs are clear. Travel is fine. And then you reach the line where technology should be - the laptops that keep failing, the registers that eat your field team's evenings, the reporting that costs a week every quarter - and you hesitate. Is this the moment to ask for it? Will the funder see it as overhead? You type "IT expenses: ₹40,000" under office costs, and hope nobody asks.

Everyone who has written a grant proposal for an education or sports-for-development organisation knows this moment. This post is about winning it: why technology line items get cut, how to write one that survives, and the exact language that makes a funder lean in instead of reaching for the red pen.

Why tech budgets get rejected

Sit on the other side of the table for a minute. A CSR or foundation reviewer sees dozens of proposals a month, and the technology lines in them fail for four predictable reasons - none of which is "the funder doesn't believe in tech":

• It reads as overhead, not delivery. A line that looks like office equipment competes with a line that looks like more children served. Overhead loses that fight every time - especially under CSR norms, where funders are mindful of how much of the grant reaches the programme.
• It's vague. "IT expenses: ₹50,000" tells the reviewer nothing - what it is, what it does, or what happens if it isn't funded. Vague lines read as padding, and padding gets cut.
• It only asks for the build. Experienced funders have seen the graveyard: systems funded once, abandoned within a year because nobody budgeted for training, maintenance, or support. A proposal that asks only for build cost signals - accurately - that the tool has a 50/50 chance of being dead by the next report.
• It's disconnected from this proposal's outcomes. If your proposal promises learning outcomes and the tech line never mentions learning, the reviewer concludes the technology is someone's wish, not the programme's need.

The reframe: technology is the mechanism, not the request

Here is the single shift that changes how a tech line is read. You are not asking the funder to buy technology. You are showing them the mechanism that delivers what you've already promised - and asking them to fund the mechanism. Every tech line should be written in this pattern: outcome, then mechanism, then number, then payback.

Compare:

Same amount. Completely different proposal. The second version tells the reviewer three things they need to sign: what it does, what it replaces, and what it gives back.

Copy-ready language

Adapt these to your programme. Notice each one names the outcome first:

For attendance & participation data

"A simple field data system so session records from the field reach the office the same day - moving dropout detection from weeks to days, and giving [Funder] real-time participation data in every quarterly report."

For reporting & M&E

"One reporting database, so that every number [Funder] receives is traceable to a named participant record - and our team spends its time on programmes, not on assembling spreadsheets."

For a first-time tech ask

"A technology readiness assessment (₹35,000): an independent, costed plan for which systems to build, buy, or skip - so that every future technology rupee, from any funder, is spent against a plan rather than a guess."

That last one matters more than it appears. If your organisation isn't ready to justify a build, the roadmap is the easiest tech ask in the world to get approved - it's small, fixed-fee, and it makes every future ask credible, to this funder and the next three.

What the budget line should actually look like

Not one blob. Break the ask into named, defensible sub-lines - and include the running costs, because that's what separates a fundable budget from an optimistic one:

Two placement notes for the Indian funding context. First, sub-lines like these usually belong under programme delivery or capacity building - because they are - but budget categories and overhead caps vary by funder, so confirm the funder's own structure with their programme officer. Asking that question early reads as competence, not naivety. Second, never bury tech inside "office expenses" to dodge the conversation. If it's discovered there, you haven't avoided scrutiny - you've failed the honesty test that CSR due-diligence teams are increasingly applying.

When the funder pushes back

Three objections cover most of what you'll hear. Prepare the answers before the call:

When you should not ask - this year

Honesty cuts both ways, and a proposal is the wrong place to learn this:

• Your records aren't standardised yet. Funding software that digitises messy registers funds faster mess. Ask for the assessment instead - or spend a quarter on the basics: one participant list, one attendance format, one source for reports.
• There's no owner for maintenance. A system with nobody responsible for it is a future awkward conversation with this same funder. Budget the support line, or wait.
• The tech isn't tied to this proposal's outcomes. Funders fund the proposal in front of them. A website for donors belongs in a different conversation than a classroom attendance system - don't smuggle one into the other.

You're not asking a funder to buy technology. You're asking them to fund what they already said they wanted - delivered, measured, and provable.

The bottom line

The tech line gets cut when it looks like a wish. It gets funded when it reads like the delivery mechanism for the outcomes the funder is already buying - with running costs named and the payback in staff-days. Write it that way and you're no longer the organisation asking for laptops. You're the organisation that knows exactly what its systems cost, what they return, and why - which, not coincidentally, is also what due-diligence teams screen for.

If you want a structured read on where your organisation stands, our Tech Readiness Checklist scores you on seventeen questions in this spirit - five minutes, an honest result either way. Including, sometimes, the result that says: stay put a little longer.