Willet
Willet
Willet
A nonprofit I know was unhappy with their conference app. That's the whole origin. No market analysis, no opportunity sizing. Someone I respected was frustrated with their software, and I got curious about why.
The answer turned out to be more interesting than the complaint. Their conference isn't a trade show. It's the one week a year their community is physically in the same place, and for a lot of the people who come, it is the only week they spend around others who understand what their life is actually like. They were running it on a platform built for corporate summits, rented annually, wiped clean every year.
So every year their community showed up and the software met them as strangers. That's not a feature gap. That's the product misunderstanding what it's for.
The event software market is horizontal by design. Build one platform, sell it to conferences, and a conference is a conference. That logic works fine until the room is something other than a business function.
Three things follow from it, and all three are structural rather than accidental:
Memory doesn't persist. Instances reset annually. Profiles, connections, and history vanish between events, so a community that has been gathering for a decade starts over every single year.
The brand is rented. Attendees download an app with the vendor's name on it. The most emotionally significant week of an organization's year arrives wearing someone else's logo.
The pricing is indifferent to you. Flat annual fees run in the thousands whether your event grows or shrinks. A hard year for a nonprofit costs the same as a good one. The platform is insulated from the outcome it's supposedly supporting.
None of that is a bug to be fixed by a vendor who serves everyone. It's what serving everyone produces.
If the reset is the core injury, persistence can't be bolted on. Profiles, connections, and attendance history are permanent by default and accumulate across years, so year two is materially richer than year one and year five is a record of a community rather than a guest list.
Every deployment is a fully white-labeled native app: the client's name in the store, their colors on every screen, runtime theming rather than a rebuild per client. Attendees never see the word Willet. The product is deliberately invisible at the moment it matters most.
A percentage of registration revenue instead of a flat fee, with the tier set by organization size. A smaller year costs less. It aligns the incentive honestly and removes the conversation where software becomes a board agenda item.
Conference software fails on exactly one day, and the failure is public. Check-in works offline through local persistence because venue wifi is a rumor. Payments run through Stripe Connect so funds land in the org's account, not mine. Then I stress-tested it against live security rules rather than trusting that it worked.
This is the argument the whole product rests on, and it's easier to show than explain. Same app, same build, four different organizations. The client's name in the store, their color on every screen, their community inside. Nobody downloads something called Willet.
--brand and the app re-themes itself at runtime. No per-client rebuild, no forked codebase.The hardest constraint on this project was that the best version of my work is the version nobody notices. An attendee opens their organization's app, finds their session, sees who else is in the room, and never once wonders who built it. Every screen has to feel like it was made by the people whose logo is on it.
Which is also why the marketing site is nearly colorless. If the product's whole promise is that the color belongs to the client, then spending color on myself would contradict the pitch in the first second of looking at it.
Registration with capacity enforcement and waitlists, promo codes, comped and manual entries. Stripe Checkout and Connect with refund handling. QR check-in that keeps working without a connection. Agenda, sessions, speakers, sponsors, exhibitors. An opt-in attendee directory with connections, a social wall, community boards, and buddy and ambassador programs. Announcements and push. Surveys. Consent-gated email with unsubscribe and suppression handling. Self-serve data export, and erasure for GDPR and CCPA.
Six fundraising and marketing platforms are wired in natively, into the tools nonprofits already run on: DonorDrive, Classy, Qgiv, Givebutter, Mailchimp, and Salesforce NPSP.
Underneath: 44 Cloud Functions, a multi-tenant Firestore ruleset enforcing path-based isolation between clients, and a Flutter client of 53 screens that re-themes itself at runtime.
Nobody was going to catch me cutting a corner on this one, which is exactly why the constraints had to be written down. These are the four I held to, including the ones that cost me something.
Attendees should never hear the name Willet. The product's job is to disappear into someone else's brand at the moment that brand matters most. This is why the marketing site is deliberately quiet, nearly colorless: the color isn't mine to spend.
Willet is for in-person conferences. It isn't a virtual-events or streaming platform, and if that's what an organization needs most, the right move is to say so on the first call. Naming the boundary costs a few leads and buys the ability to be believed about everything else.
A for-profit company taking money from mission-driven organizations is a real tension, and pretending otherwise would be worse than the tension itself. So a portion of every platform fee funds registrations for people who couldn't otherwise attend. Not a discretionary act of goodwill. A line in the pricing. The client chooses who receives them, always.
These communities include vulnerable people. So the rule I wrote for myself is that no event runs with the social wall, boards, or messaging enabled until report-and-remove exists. A bad post handled slowly isn't a support ticket. It's a harm event, and shipping without the tooling would be choosing a launch date over a person.
Willet is a conference platform built exclusively for nonprofits whose annual gathering isn't a line item but the emotional center of their year.
Not a rented instance that resets every twelve months, but a permanent, branded asset a community grows into. The generic platforms aren't badly built; they're built for someone else, and adapted for nonprofits as an afterthought. That's why they feel borrowed. A patient advocacy conference is not a corporate summit. The stakes in that room are different, and software that flattens the difference treats a homecoming like foot traffic. Willet exists because that isn't acceptable for the one week a year these people get to be understood.
Screens built alone, from strategy through engineering.
A multi-tenant, white-label conference platform in Flutter and Firebase, with fundraising wired in natively.
Product strategy, brand, UX, and the build itself, all by one person. The need was immediate, so an MVP went up quickly to prove the model. What exists now is the fuller version, built out for what a conference year actually asks of it rather than what a demo needs.
Mostly that I default to building whatever part I find interesting, and then act surprised at the shape of what's left over. The engineering is stress-tested at a thousand registrations because that was the part I wanted to solve. Nobody made that trade for me; I made it over and over, every time I chose another system to build over another process to write down. Seeing the pattern laid out was more instructive than any of the code.
The other lesson was about pricing, and it came from being told no. The original model returned cash to the client as a sponsor-back. It was clean, it was generous, and it was economically identical to a discount for a tax-exempt recipient, which risked being recharacterized as a rebate. So it died, and Will It Forward replaced it: the money doesn't go back to the organization, it funds seats for people in that organization's community who couldn't otherwise attend. The constraint produced a better idea than the one I started with. That happens more often than I'd like to admit.
Mostly this project is the answer to a question I get asked in interviews, which is whether a designer who can talk about brand can also ship. A working platform, 44 Cloud Functions, and a multi-tenant security model I wrote and then tried to break. I'd rather show that than assert it.
Uptern
Sixty percent of a site audit is mechanical. The other forty is why anyone hires me.
Read the case study →
St. Baldrick's
Sixteen years as a shavee before I ever worked on the brand. Then the joy started draining out of the marketing.
Read the case study →