I Built a Charitable Giving Startup Before Realizing the Industry Already Solved the Problem
How a sketchy nonprofit donation form led me to prototype a product, interview friends, discover donor-advised funds, and ultimately shut the project down.
--
Last week, a local educational nonprofit sent me a donation letter.
I wanted to support them.
The problem was their donation infrastructure.
Here were my options:
- Visit their website and enter my credit card into a form running on HTTP instead of HTTPS.
- Write my credit card number on a paper form and mail it.
- Send a check.
I don’t write checks. Credit cards give me the protection and spending information I desire. I’m not entering payment information into an unsecured web form in 2026. And I’m definitely not mailing my credit card number through the postal system.
So I didn’t donate.
That stuck with me.
This wasn’t some tiny edge-case organization operating out of a garage. It represented a broader problem I’d seen repeatedly with small and midsize nonprofits: limited technical resources, outdated donation systems, inconsistent donor experiences, and security practices that often lag years behind modern expectations.
The nonprofit lost a donation from someone who actively wanted to give.
That felt like a solvable problem.
So I started building.
The Original Idea: One Trusted Checkout
The initial concept was straightforward.
What if donors could use one trusted, modern donation flow for any verified 501(c)(3)?
Instead of every nonprofit maintaining its own payment stack, the donor would interact with a single secure checkout experience. The platform would then route the money to the nonprofit however they accepted funds:
- ACH
- Direct deposit
- Paper check
- Whatever worked for them
The donor wouldn’t need to evaluate whether each nonprofit’s website looked legitimate or secure.
I called the idea DirectStep.
The positioning was simple:
One trusted checkout for charitable giving.
I built a working prototype.
Not a Figma mockup. Not a pitch deck. Actual deployed software.
You could:
- Search for a nonprofit
- Walk through the donation flow
- Simulate a contribution
- See how the distribution process would work
The only thing missing was live payment processing.
Once the prototype existed, I sent it to ten friends.
The message was intentionally lightweight:
“If you’ve ever wanted to donate to a charity but backed out because the donation page looked sketchy, this might be interesting. I built a secure donation flow that can route gifts to any verified 501(c)(3). Payments aren’t live yet — I’m mostly testing whether people would use it.”
I thought I was validating an idea.
What I was actually doing was beginning customer discovery.
Those are not the same thing.
The Dangerous Ambiguity of “I Might Use This”
The friend test produced what initially looked like encouraging feedback.
Out of ten people:
- Five said they might use it
- Two didn’t donate to charities much at all
- Two thought it was interesting but wouldn’t personally use it
- One friend, Gary, said he and his wife handled giving through QCDs from their IRA
At the time, I mentally categorized the results as “mostly positive.”
But there’s a huge difference between:
- “Interesting idea”
- “I might use this”
- “How soon can I start using this?”
Nobody asked when payments would go live.
Nobody tried to return to the prototype.
Nobody forwarded it to someone else.
Nobody expressed pain intense enough to demand a solution.
That distinction matters.
A polite maybe is not validation.
Especially from friends.
Friends tend to encourage builders because they want to be supportive. They are usually not representative of actual market urgency.
The most valuable feedback came from Gary.
At the time, I barely noticed it.
Later, I realized his comment effectively collapsed the entire business case.
The Product Pivot: From Nonprofit-Centric to Donor-Centric
As I reflected on the prototype, three problems became obvious.
1. Transaction Fees Were Brutal
If I absorbed payment processing costs, I lost money.
If I passed the fees to donors, the experience felt extractive.
If I passed the fees to nonprofits, I became another payment processor taking a cut of donations.
The economics were ugly.
2. Donors Had No Ongoing Control
Suppose I set up recurring donations to multiple organizations.
What happened when I wanted to:
- Pause one?
- Increase another?
- Cancel a third?
In practice, most nonprofits still require emailing or calling someone manually.
I checked my own recurring giving.
Out of roughly 20 organizations I supported, only one had a modern self-service donor portal.
That surprised me.
The actual pain point wasn’t merely payment security.
It was donor management fragmentation.
3. The Nonprofit Wasn’t the Customer
I’d designed the system around nonprofits.
But the person experiencing the friction was the donor.
The donor was the one:
- Evaluating sketchy forms
- Managing recurring charges
- Tracking tax records
- Handling privacy concerns
- Navigating inconsistent donor systems
So I redesigned the concept entirely.
The new version became donor-centric.
The donor would create a wallet, fund it once, and manage all charitable giving from a single interface.
Inside the wallet they could:
- Donate to any 501(c)(3)
- Create recurring grants
- Pause or cancel donations instantly
- Receive consolidated annual tax records
- Control privacy settings
That version became GivingWallet.
And structurally, it started looking less like a payment platform and more like a charitable intermediary.
Which led directly to the next discovery.
The Thing I Accidentally Reinvented
As I researched how GivingWallet would need to operate legally and financially, two concepts surfaced repeatedly:
- QCDs (Qualified Charitable Distributions)
- DAFs (Donor-Advised Funds)
Gary had already pointed me toward the first one.
QCDs
For people over 70½ with IRAs, QCDs allow direct charitable distributions from retirement accounts.
The distribution avoids taxable income treatment.
For retirees already managing required minimum distributions, it’s an extremely efficient mechanism.
In other words:
For some donors, the problem I was trying to solve had already been solved by tax law.
But the larger discovery was donor-advised funds.
Donor-Advised Funds
A donor-advised fund works like this:
- You contribute money into a sponsoring charitable organization.
- You receive the tax deduction immediately.
- You later recommend grants to nonprofits from that fund.
That was almost exactly what I had redesigned GivingWallet to become.
Except donor-advised funds weren’t new.
They’ve existed in some form since 1931.
And modern platforms had already refined the experience.
I started evaluating products in the category:
Daffy was the closest match to what I’d envisioned.
Low monthly pricing. Modern UX. Privacy controls. Recurring contributions. Consolidated tax documentation.
The experience felt uncomfortably familiar.
Because it was.
GivingWallet was effectively a less mature version of an already-established product category.
That realization forced a decision.
Shelving the Project
I tested the existing solutions against my own real-world workflow.
I donate monthly to around twenty organizations.
One of them — Oregon Public Broadcasting — I intentionally support directly because I want the streaming membership benefits.
But the other nineteen?
I mostly wanted:
- Simpler management
- Fewer recurring charges
- Better privacy
- Reduced fundraising mail
- Consolidated tax documentation
A donor-advised fund solved nearly all of that immediately.
I opened a Daffy account.
Every nonprofit I supported already existed in the system.
Some required searching by EIN instead of name, but they were there.
The solution already existed.
And importantly:
It already had trust, scale, compliance infrastructure, operational maturity, and distribution.
So I shelved GivingWallet.
Not because the problem was fake,
Because the market already had competent solutions.
What the Project Actually Taught Me
I don’t consider the project wasted effort.
It clarified several things about product development that are easy to intellectually understand but harder to emotionally accept.
1. The Most Valuable Feedback Often Sounds Casual
Gary mentioning QCDs during an offhand conversation was more important than all the “cool idea” feedback combined.
Builders tend to overvalue enthusiasm and undervalue friction, alternatives, and substitution behaviors.
The skeptical comment is often where the real learning lives.
2. Existing Solutions Can Be Surprisingly Invisible
Before this project, I had never heard of donor-advised funds.
A category that had existed for nearly a century was functionally invisible to me until I started digging deeply into the mechanics.
That happens more often than founders want to admit.
3. Killing a Product Early Is a Success Condition
There’s a romantic mythology around persistence.
But persistence only matters if the underlying opportunity remains compelling.
The real failure mode is spending years building a worse version of something the market already has.
Customer discovery worked.
It simply delivered an answer I didn’t initially want.
The Weirdly Positive Ending
The funny part is that the project still changed my behavior.
I ended up adopting the exact category I discovered during the process.
Today, my charitable giving is cleaner, simpler, and easier to manage than before.
And the original insight still holds:
A surprising amount of nonprofit donation infrastructure is outdated.
That pain is real.
I just wasn’t the first person to notice it.
Sometimes the right entrepreneurial outcome isn’t building the company.
Sometimes it’s discovering the market already solved your problem — and learning enough to recognize it before you spend the next year reinventing it.
Originally adapted from a six-part LinkedIn series documenting the evolution and eventual shelving of the GivingWallet concept.
Months later, I realized his comment effectively collapsed the entire business case.
