Building technology that sticks

Good technology exists. Salesforce, Zoho, HubSpot, and a long tail of tools for case management, volunteers and donors. Yet year after year, nonprofit leaders tell us the same thing. The stack feels fragmented, adoption stalls, and the systems don't fit the work.

The gap is structural. Most software assumes clear processes, a dedicated IT team and budget for consultants. Most nonprofits run on institutional memory, uneven digital maturity across teams, reporting shaped by funders rather than frontline staff, and one person who handles technology on top of three other jobs. So the gap shows up at three points.

When adoption fails, leaders often blame their teams. That's usually unfair. A programme manager who has tracked field visits over email for five years doesn't embrace a database because leadership bought one. She experiences it as extra work, designed by people who don't do her job. Without a clear link to better outcomes, her resistance is rational.

Over time, organisations stop expecting technology to help. They expect it to complicate.

Every system encodes choices about who gets served, what gets measured and which work is worth preserving. So we start from a simple position. Technology in this sector should serve the underserved and widen access. Efficiency matters, but it's the smaller goal.

Automation for efficiency asks how to do the same work faster. It assumes the current work is the right work. Widening access asks something harder. What could this organisation do with better systems? Which communities are out of reach because the team is buried in manual process?

That position has practical consequences. It shapes which projects we take on, how we price and what we'll refuse to build. We won't build systems that exist mainly to extract data for funder reports. We won't add admin load to frontline staff. And we scope around real capacity: a nonprofit with a part-time operations manager can't absorb a rollout designed for one with an IT team.

It also means being clear-eyed. Technology amplifies human effort. A better data system won't fix a broken strategy, and an AI tool won't fix a culture problem. We say that early, especially when someone hopes technology will be the shortcut.

Across our work, technology earns its place in three roles. They build on each other, and most of the failed investments we've inherited got the order wrong.

Skip the first job and the second one backfires. Automate a confused workflow and you get a confused workflow at scale. A database is only useful if someone owns data quality. A workflow tool only saves time if the workflow is written down and followed. Technology accelerates discipline. It can't create it.

The third job is where AI lives, and it's where we're most careful. A model that predicts which students are likely to drop out is useful only if someone is ready and able to act on the prediction. Insight without action is noise.

What technology can't do

• Rescue an organisation that hasn't decided who it serves or what it measures.
• Replace judgement. The best tools let the user override, adapt and apply sense.
• Justify its own complexity. A custom platform that needs a full-time administrator is a liability.

That's why our first recommendation is often smaller than people expect. Start with forms, sheets and simple automations. Build the habit of consistent data entry. Once the team is using it and can say what's missing, then look at something more sophisticated.

Platform choice should follow fitness for purpose. We know Zoho deeply, and it sits in a useful middle ground for nonprofits: flexible, affordable and modular. Some problems still need something else. Staying loyal to a vendor at the expense of a partner's actual problem is a quiet form of dishonesty.

Readiness usually gets treated as a box you tick before a project starts. In our experience it's built during the work, through discovery, clear requirements, peer learning and support that sticks around after launch. When technology lands well, five conditions are present.

None of these is technical, and none is optional. We've also found that four questions predict success better than any feature checklist.

Launch is where adoption starts

The first 90 days after launch are when the real questions show up. Workflows that looked fine on paper hit friction. Staff who were excited in the training room get unsure once they're working with real data. That's when office hours, peer cohorts and documentation that admits things are confusing do the most good. A system that needs reconfiguring in month six is a sign the organisation is learning.

Peer learning is underrated here. When a consultant tells a team what to do, adoption feels like compliance.

Nonprofits buy slowly, and they're right to. A new system touches several teams, there's rarely an IT department to catch problems, and the money comes from a pool that could otherwise fund programmes. So the real evaluation happens before any feature comparison. Do these people understand how we work? Do they believe what we believe? Will they tell us what their tool can't do?

What earns that trust, in our experience:

• Honest qualification. We ask hard questions early. Is the budget realistic? Is there internal ownership? Are the requirements clear enough to scope? When a team hasn't aligned internally, we say so and suggest that conversation happens first.
• Naming our limits. Saying what we don't do well, and pointing to someone who does, builds more credibility than any case study.
• Treating vagueness as a warning. "We just need to go digital" is a signal to slow down.
• Phasing the work. A first phase lets both sides see working results before committing further.
• Removing friction. A direct number, a calendar link in the first reply, same-day confirmation, a call instead of a week of email.

Friction is also a diagnostic. If you make the next step easy and a prospect still doesn't take it, that tells you something about fit or internal alignment. And the way you run sales is a preview of how you'll run delivery. Prospects notice.

Requirements move. A funder shifts priorities, a programme finds its population has changed, two organisations merge. Development, programme and finance teams use different words for the same data. The data in an inherited system is worse than anyone expected. And there's rarely budget for a second pass.

We've seen dashboards where every number was correct and nobody used them. We've seen an elegant system automate the procedure manual, five years out of date, while the real process ran on three emails and a phone call. The code worked in both cases. The delivery didn't. We now work from five instincts.

Week one sets the tone

A kickoff that confirms the problem statement. A planning call against an estimated task list. One shared tracker as the source of truth. A cadence already on everyone's calendar. When week three brings a hard problem, the partner remembers week one and solves it with you.

Our blocker protocol

None of those instincts hold without a team culture that rewards them. A few habits carry most of the weight.

• Direction comes with reasons. People who know why a piece of work exists can solve problems the instruction didn't anticipate.
• Autonomy needs a frame. Clear success criteria and a shared tracker give people room to move. Without them, "own this" feels like abandonment.
• We ask before we tell. What do you think? What's blocking you? What would you propose?
• Accountability sounds like planning. "What's the update on the three tasks, so we can focus next week?" gets a very different answer from "Why did you miss the deadline?"
• Failures are planning problems. The first question is which assumption broke.
• Rough drafts are invitations. Work shared at 60% gets feedback while it's still cheap to change.

Warmth and high standards turn out to be the same practice. Explain the context, make work visible and catch problems early, and people feel cared for because the bar is clear. The founder learns in the open too, trying new tools with the team and changing his mind when someone knows better.

A girls' education programme in one city and a literacy programme a thousand kilometres away face the same workflow problems. Both usually solve them from scratch, and what they learn stays locked inside one organisation's database.

That's moved our own work from custom builds towards shared infrastructure: reusable templates, standard data models, open playbooks, peer cohorts and office hours. We've also learnt that open source and shared tools only help when documentation and support come with them. A free tool nobody knows how to use isn't free.

AI fits the same logic. For field teams in low-connectivity areas, qualitative notes piling up, and fewer staff than the work needs, it's practical infrastructure. Less manual processing, more time for judgement. It belongs on top of a working operating system. Plenty of organisations need better data practices before they need an AI model.