GrantHub is sunsetting Jan 31, 2026.GrantHub sunset:We'll migrate you free.
Read the migration guideOur principles
We say we're a human-centered tool. That phrase has been worn smooth by overuse — so we wrote down what we actually mean by it, and how you can hold us to it.
The full reasoning lives in our white paper: Human-Centered Design for Mission-Driven Software . The principles below are the short, public version.
Every feature should be traceable to a real observation of a real person doing the work. Not "users probably want X." Not "wouldn't it be cool if." If we can't name the worker whose conversation motivated a feature, the feature doesn't ship.
How to hold us to it
Ask us, about any feature: "who told you this was a problem?" We should be able to name three people. If we can't, the feature shouldn't be there.
If a feature can be removed and you can still accomplish your goal, we remove it. Every feature added is a learning burden for you and a maintenance burden for us. When we're considering something new, the first question is: "what existing thing does this let the user delete?"
How to hold us to it
If a release of ours adds three new things without retiring or simplifying anything, we're drifting. Tell us.
Not the buyer. Not the executive director who signs the invoice. The grants manager who opens the tool at 11pm on a Sunday to log a thank-you note. Their week getting better is the metric. If we have to choose between a feature that's pretty for an ED demo and a feature that saves a grants manager 20 minutes, we choose the 20 minutes.
How to hold us to it
Read our marketing imagining you're the grants manager. If it talks about your week or it talks about the ED's dashboard looking good, you'll know which one we got right.
A feature is "shipped" when at least three real customers have used it for at least two weeks and we've watched them use it. Until then it's a prototype. Marketing claims live behind that gate. If we put a benefit on the website, three customers can vouch for it.
How to hold us to it
Any benefit claim we make is fair game to ask: "can you name the three customers this came from?" We should be able to.
We don't get to say "but we meant well" if the product makes someone's job worse. Every release ships with a measurable claim ("this should save X minutes/week" or "this should reduce time-to-first-task by Y"). We measure whether the claim held. Failed claims trigger a rebuild, not a re-marketing.
How to hold us to it
Ask for the impact data. We'll show you. When we get it wrong, we publish the correction.
Stating principles is easy. The harder thing is naming the ways well-intentioned teams violate them. Here are the eight anti-patterns we're actively watching for in ourselves. If you spot us doing any of these, we want to know.
#1Research theater
Conducting interviews and observation, then making decisions that don't reflect what was heard. Research becomes a ritual that validates pre-existing intentions.
#2Persona fossilization
Personas created at the beginning of a project that get treated as ground truth two years later — even though we've talked to 200 more customers since.
#3Testing with the wrong users
Showing a feature to a colleague or another founder and calling it user feedback. Internal feedback is design review, not user research.
#4Leading questions
"Wouldn't it be useful if you could do X?" reliably gets "yes" because people are polite. That isn't research; it's confirmation-seeking.
#5Sample size of one
A single passionate customer says X and we build X. But X may not generalize. Three independent customers have to surface the same pain.
#6Buyer-user substitution
The buyer (the ED) is not the user (the grants manager). Designing for the buyer is customer-centered. Designing for the user is human-centered.
#7Inhuman pace
Burnt-out designers can't build burnout-relieving products. Building this product at a pace that mirrors the burnout we're trying to solve is a contradiction the customer will eventually feel.
#8Marketing faster than product
Writing claims about features that aren't shipped yet, or benefits we haven't measured. The fastest way to lose authenticity.
Quarterly, we run a self-audit of our product and our marketing against the principles + anti-patterns on this page. We publish the result — including what we failed.
The first audit (May 2026) found five anti-pattern violations in our own product. We told on ourselves. The plan to fix each one is in the audit document.
The closing test
If our pilot users — the people whose actual work we're building for — read everything on our website and every feature in our product, would they recognize themselves and their work?
Or would they recognize a vendor's idea of what their work is like?
If the first, we're doing it. If the second, we rewrite. That's the bar.