We have no budget for technology, and who maintains it afterward?

Almost every conversation we have with foundations ends up, sooner or later, at the same point. This wasn't in the budget. No grant pays for this. We can't pay a monthly fee forever. These are reasonable concerns, and we've heard them from more than eight organizations this past year.

At Sumadots we'd rather answer them head-on, before talking about any tool. These are the questions we get asked most, and what we say.

Where do we start if the budget doesn't cover everything?

With something small that people will notice. A first stage that solves a specific problem and shows, within a few months, what it gave back: hours saved, more people finishing a program, faster fundraising. That result is the best argument for getting the next stage.

A good order is to build the shared foundation once (where the data lives, how people come in) and then grow in parts, adding what you need when there's money for it.

One warning: don't start with the most urgent thing on the calendar. If the tool has to be ready for next month's campaign, any stumble lands at the worst possible moment. It's the biggest operational risk we see. Better to start with something important that doesn't have a deadline hanging over it, and reach the campaign with the tool already tested.

Who pays for this if no grant covers it?

It's true that few funders pay for “technology” as a separate line item. But many do fund programs, and a program that works better with a tool can include it in its budget. The question changes: it's no longer how to pay for technology, but which already-funded program needs it.

Will we be stuck with a monthly fee forever?

It shouldn't be that way. The concern is fair: many organizations have paid for tools that, when the contract ends, take the data with them or stop working. That's why, before signing with anyone, check these conditions.

• The code and the data stay in the organization's name.
• The tool lives in the organization's own accounts, not the vendor's.
• Minor adjustments don't require paying a fixed monthly maintenance fee.
• The team can run the tool on its own, without calling anyone for day-to-day work.

That last condition is the most important, and the one most often forgotten. If every text change or every new user depends on an outsider, the tool becomes fragile. That's why part of every project is making sure the team learns to run it.

What if it's still not enough?

Then the answer is smaller, not cheaper. Sometimes the best first step isn't building anything, but sorting out a process, choosing an existing tool well, or teaching the team to use what it already has. If you need to build later, you build on something that already works.

If you want to see which solutions are already proven and where your organization could start, take a look at SumaKit.