Order of Operations

Every nonprofit has years of material scattered across a shared drive, a staff member’s inbox and the memory of whoever has been there longest. Program descriptions, eligibility criteria, intake scripts, grant boilerplate, the standard answers to the standard questions, the policies, the reporting language that worked last time. Consolidating that into something retrievable is pillar two’s obvious half, and it pays off immediately in grant writing alone.

The half that gets skipped is the outcome data. Not what you did — what changed. Not meals served, but what happened to the families who received them. Not attendance, but where a participant was six and twelve months later. That is the asset with real value, and it exists nowhere until you decide to capture it, because no system you own was designed to record it.

The payoff here is more direct than it is for a law firm. Every serious funder asks for outcomes, most organizations answer with activity because it is what they can produce, and the ones that can answer properly are the ones who get renewed. The outcome layer is not a reporting chore. It is the difference between a grant and a relationship.

Governance goes in at the foundation

Not bolted on later. Beneficiary data is frequently more sensitive than donor data, and if you serve minors, people in crisis, or anyone whose circumstances could harm them if disclosed, assume a higher bar than your sector peers apply. Before the first record lands: who can retrieve what, what leaves the building and under whose terms, how long it is kept, what gets verified before it reaches a funder or a board packet, and what your grant agreements already say about where data may be processed. Read those clauses. Most people have not.

Search is becoming a conversation held without you in the room. Someone describes their situation — behind on rent, caring for a parent, looking for an after-school place — and an assistant answers. Whether your organization is in that answer is now a more important question than where you rank for your own name.

Findable is table stakes: consistent information everywhere, structured data, clean profiles, and programmes described in the words people actually use. Someone types “help paying rent”, not “emergency financial assistance programme”. The gap between your language and theirs is the single most common reason a nonprofit is invisible to the people it exists to serve.

Citable is the real work, and nonprofits are sitting on more of it than they realise. You have programme knowledge, population expertise and outcome data that nobody outside your sector has written down in a form anything can cite. Most of it is locked in annual report PDFs that nothing links to. An annual outcomes report, published as a page rather than a download, cites harder than almost anything else you could write.

Callable matters more here than it does for law firms, and this is where pillar two pays off twice. Eligibility checkers. Service finders. Document-readiness tools. Application status lookups. “Am I eligible” is the most common question you get and the most expensive one to answer by phone, and it is exactly the kind of thing an assistant can be given the ability to answer on your behalf.

You should not build your CRM, your accounting, your email, or your donation processing. Those are solved, the solved versions are better than yours will be, and most of them have nonprofit pricing.

The sector-specific trap is different from a law firm’s. It is the donated or deeply discounted enterprise platform that arrives free and costs you a staff member. A system you cannot configure without a consultant is not free; it has a salary attached, paid in someone’s time rather than in licence fees. Count that cost before you accept the grant of software, not after it has become the thing nobody can leave.

What is worth building is the narrow thing that is genuinely yours and absent from every vendor’s roadmap: eligibility screening against your specific programme rules, a volunteer matching flow that reflects how you actually schedule, a document-collection process for the particular paperwork your participants struggle with. These are thin — a few screens over the data you started capturing in pillar two — and the thinness is the point.

Here is the part nobody writes down. Most internal software dies. Not some of it, most. And it dies faster in this sector, because the champion is usually one staff member, and when that person leaves, the thing they built becomes an unmaintained dependency nobody understands. That is not an argument against building. It is an argument for writing the kill criteria before the first line of code, and for never building anything that only one person can run.