Design-partner program · Core donor operations in active build
See the roadmapBlog
Each piece comes from a design-partner session or a decision we had to make in the product. No thought leadership, no gated downloads.
Start here
Set as a publication opening, not a row of product cards: the image is cropped by its column and the headline lives in HTML beside it.
Legal donor governs the receipt, payer governs the payment method, recognition governs the public credit, and household governs the mailing. Merging any two of them produces a wrong document.
Model the chain as gift → transaction → payout → deposit → allocation → journal → close, and every discrepancy becomes an object with an owner instead of a difference in a spreadsheet.
The distance between a donation and a defensible impact statement is nine objects long. Most stacks store three of them.
Categories
5 articles
Two categories of software own opposite halves of the same event, and neither owns the seam between them. That seam is your month-end.
How to structure allocation and fulfillment so an impact claim survives a funder's question.
Why declined recurring payments become lapses, and the operating model that prevents it.
The data-model decision that quietly determines whether your acknowledgments and receipts are correct.
Five structural reasons the two numbers differ, and which of them are supposed to.
Design-partner program
We are working with a small number of US and Canadian nonprofits who feel the reconciliation and donor-data pain most acutely. Partners shape the sequence, see the honest status of every module, and are never charged for a capability that is still a prototype.
