← Back to all work
Two Willet app screens on a soft beige field: a conference agenda with a session happening now, and a searchable attendee directory. Willet

A conference platform for the room that matters most

Project
Self-directed product
Role
Everything: strategy, brand, design, build
Timeline
2026, MVP first then built out
Status
In active development
Disciplines Product Strategy Brand UX Engineering Pricing
Stack Flutter Firebase Cloud Functions Stripe Connect
Scope Solo build Multi-tenant White-label
summarize Overview

The Opening

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 Challenge

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.

My Role

All of it. Product strategy, positioning, brand, UX, the pricing model, the marketing site, and the code: the Flutter client, the Firebase backend, the security rules, the payment infrastructure. This is the project where nobody handed me a brief, so every decision on the page is one I had to make and can account for.

The Approach

01

Make memory the architecture, not a feature

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.

02

Give the brand back

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.

03

Tie the price to the outcome

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.

04

Build it to survive a real day

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.

One App, Any Brand

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.

Four phone mockups side by side showing the identical Willet conference app rendered in four different nonprofit brands, each with its own name and accent color.
Brands shown are illustrative. Under the hood each one is a single CSS custom property: set --brand and the app re-themes itself at runtime. No per-client rebuild, no forked codebase.

Designed to Disappear

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.

Three sets of Willet interface components shown outside a phone frame, each rendered in a different nonprofit's brand: a header, a session card, an attendee row with a role tag, and a confirmation pill.
The same components under three brands: header, session card, attendee row, role tag, confirmation pill. Brands shown are illustrative.

What It Does

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.

palette Product Foundation

The Principles

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.

The color belongs to the client

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.

Say what it isn't

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.

Structural, not charitable

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.

Harm is a launch blocker

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.

Solo build
53

Screens built alone, from strategy through engineering.

A multi-tenant, white-label conference platform in Flutter and Firebase, with fundraising wired in natively.

The Will It Forward fund on a registration dashboard, with live notifications showing a contribution added at checkout and a new registration crediting the fund.
A completed check-in screen with a QR ticket, alongside a floating count of 542 registered attendees.
A conference agenda in a client's own brand, listing a caregiver workshop, a youth hangout, and a parents and partners circle.
An annual platform renewal notice showing a flat fee due in full, noting registrations came in under projection while the price did not change.

Built Fast,
Then Built Out

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.

53Screens
44Cloud functions
6Platforms wired
lightbulb Takeaways

What This Taught Me

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.

grid_view More Work
Uptern

Automating the Audit, Keeping the Judgment

Product · Self-Directed

Sixty percent of a site audit is mechanical. The other forty is why anyone hires me.

Read the case study →
St. Baldrick's

Turning Search Traffic Into Childhood Cancer Research Funding

Nonprofit · Brand & Growth

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 →