Happly AI
Senior Product Designer · Feb 2025 to present · Product design, design systems, UX writing · B2B SaaS and AI
What Happly is
Happly is a funding platform with two sides. On one side, Canadian business owners look for grants and funding programs they qualify for, assemble applications, and track what they win. On the other, the organizations that hand out that funding run their programs, review applications, and manage their members on a white-label version of the same platform.
I joined as the first and only product designer. The platform had grown feature by feature for a few years, which meant three visual styles, several half-finished flows, and a product that could tell you a program existed but could not tell you what to do about it.
2
sides of a marketplace, one codebase
41
document types in the library
2
languages, English and French, on every surface
What I owned
I am the design owner for the whole platform, working directly with the PM, the CEO and the engineering team.
The Seeker journey end to end: onboarding, dashboard, opportunity discovery and matching, the Funding Journey pipeline, the Document Library, outcomes
HapplyOS, the white-label platform for funding organizations: members, applications and review, roles and permissions, the Education Center, events and bookings, reporting
GrantGPT, a Chrome extension that drafts and fills grant applications on external sites, and an AI Business Plan Builder
The design system, from three legacy styles to one component library, including the QA pass across every surface
happly.ai, the marketing site, designed and built in Framer
Product writing across all of it: empty states, locked states, match explanations, onboarding questions, error and recovery copy
I also wrote the product requirements for the Funding Journey and for the HapplyOS platform, then designed and shipped against them.
Discovery was never the hard part
When I started, the assumption inside the product was that founders needed to find more programs. That is not what was happening. A founder would open the platform, see a long list of opportunities with match percentages next to them, and either believe a number they had no reason to trust or ignore the whole thing.
The real problem was that the product treated every state the same. A program someone glanced at once and a program they were three days into writing looked identical. Money was displayed as a program’s advertised maximum, which is almost never what anyone receives. Deadlines sat months apart, so reminders were either constant or absent.
“Show me grants I can actually win, tell me what to do next, and do not let me miss a deadline.”
Our founder persona, from the product requirements I wrote for the Funding Journey.
Decision one: the badge, never the number
The problem
Every opportunity showed an AI-generated match percentage. Eighty-one percent. Sixty-four percent. Two things went wrong. People over-trusted a precise-looking number that came out of a language model, or they dismissed the whole feature the first time a high percentage turned out to be a bad fit. Neither reaction was wrong. The number was performing a confidence the system did not actually have.
It was also slow. Running model reasoning for every card in a grid is expensive and inconsistent, and results shifted between loads.
The decision
I split matching into two stages that do different jobs.
Stage one is a database rule. Hard filters on the things that are simply true or not true: province, sector, business stage, revenue band, incorporation status. It produces a tier, High, Medium or Low, instantly and identically every time. That is what a card shows.
Stage two is the AI reasoning, and it only runs inside an opportunity’s detail page, where there is room to explain itself in sentences and where a person has already chosen to look closer. It can refine the tier, and it always says why.
Why
The badge has to be instant across a whole grid, consistent between loads, and explainable when someone asks. That is a database rule’s job, not a model’s. The model earns its place where there is space for a paragraph and a reason.
The wider principle I kept applying after this: the AI advises, it never decides.
Before: old opportunity card with a percentage
After: current card with a High or Medium badge
Before and after. The percentage implied a precision the system did not have.
Opportunity detail view with the AI eligibility explanation visible
Stage two runs here, where there is room to say why.
Decision two: stay quiet until someone commits
The problem
A founder researching funding might save twelve programs in an afternoon. If the product treats each of those as an active commitment, it sends twelve deadline reminders, and the person turns off notifications, which means they also miss the one deadline that mattered.
The decision
The Funding Journey has five stages: Interested, Drafting, Submitted, Won, Not selected. The product is silent through Interested. No reminders, no deadline pressure, no nudges. The moment someone moves an item to Drafting, they have told us this is real, and from there the product becomes proactive: deadlines, missing documents, next steps.
Every route into the pipeline, from the opportunity list, from search, from a dashboard suggestion, opens the same capture modal, with exactly one required field.
Why
Respect attention first, then earn the right to interrupt. A founder who bookmarks twelve programs should not get twelve deadline emails.
One shared modal matters for the same reason. If there are three ways in and three different forms, people learn the product three times and abandon it twice.
Funding Journey Kanban with the five stages visible
Five stages. The product is silent for the first one.
The capture modal
Every entry point opens this, with one required field.
Table view
Calendar view
The same pipeline as a table and a calendar, for people who plan differently.
Decision three: show money only when it is real
The problem
Grant programs advertise a ceiling. A program that says “up to $500,000” might typically award $40,000. When a platform adds those ceilings up and shows a founder their total funding potential, it produces a number that feels like a plan and is closer to a fantasy. And when someone actually wins, filling their win with the program maximum would be worse still.
The decision
The funding-potential total on the opportunity list is capped per opportunity, so a single outlier program cannot inflate a headline number that someone is making decisions against.
When an item moves to Won, the card records the actual award amount, entered by the person who won it. If they do not enter one, the card shows nothing. It never falls back to the program maximum.
And when an item moves to Not selected, we capture the reason, with an explicit “no reason given” option, because that is often the truth. Then we offer to create a linked item for the next cycle.
Why
A made-up figure on a real win would be worse than no figure at all.
The rejection rule is the one I care most about. A rejection is the highest-risk moment for someone giving up on funding entirely. Turning it into a specific, linked next attempt is the difference between a product that logs an outcome and one that keeps someone in the process.
Won card with a real award value, and the Not selected flow with reason capture
A win records what was actually awarded. A loss becomes a linked retry.
Identity beats filename
Applications fail on paperwork. The obvious solution is a folder where people upload files, and it does not work, because a folder can only tell you what you put in it.
I designed the Document Library as a typed inventory instead. Every document has an identity: articles of incorporation, a T2125, a financial statement, proof of revenue. Forty-one types across six areas: Legal, Financial, Tax, People, Strategy, Operations. A file named final_FINAL_v3.pdf satisfies nothing until it has a type.
Once documents have identity, the library can do the thing a folder cannot: show you what you do not have. Missing types appear next to the files you own, labelled with how many of your active applications need them. Documents also go stale, so each type carries a freshness window, shown as a flag rather than a notification, because nobody needs to be told off by their document manager.
“The library shows what you do not have.”
Document Library with present and missing types visible
Missing types sit alongside the files you have, counted against the applications that need them.
The other half: HapplyOS
Everything above is the founder’s side. The same platform runs white-label for the organizations that fund them, and I designed that too. It is the less visible half and the more operationally complex one.
Members and groups
Bulk import that previews the first rows and lets an admin decide whether to email now or stay silent. Groups drive content access, permissions and reporting, so the platform does not become a spreadsheet with extra steps.
Programs, applications and review
Program creation, one-click apply, and a review queue where an AI fit score is advisory only. The reviewer decides. The model never does.
Education Center
Courses, lessons, quizzes, assignments and certificates. Creation is progressive, so nobody is forced to complete everything before saving anything. Notifications only for things a person can act on.
Events, bookings and reporting
Free and paid ticketing, mentor meetings, room bookings, and dashboards where every number is computed from the same source lists as the views underneath, so counts cannot drift apart.
HapplyOS admin: member management or review queue
The white-label side. Each organization gets its own branding, domain, onboarding questions, roles and content access, on one codebase.
Three styles into one
The platform had accumulated three visual languages. I unified them into a single component library, built on Radix primitives, that themes per tenant, so a funding organization gets its own brand without anyone forking the interface.
The part that actually mattered was the boring part. I ran the QA pass across the member portal, the back office and the prototype myself, in both languages, and fixed the places where a tenant’s brand colour was not reaching a component. A design system is only real once someone has checked every state of it.
Components sheet or tenant theming comparison, two brand colours on the same screen
One library, themed per organization.
happly.ai
I redesigned and built the marketing site in Framer, with its own design system and motion. Engagement went up 170 percent.
happly.ai, desktop and mobile
Designed and built in Framer.
What I would do differently
I would have pushed harder, earlier, for instrumentation. Most of the decisions on this page were argued from user conversations and product logic, and they hold up, but I had to make the case for several of them more times than I should have because I could not point at a number. That is a design responsibility, not just an analytics one.
I would also have written things down sooner. The decisions that stuck are the ones I wrote as rules before anyone drew a screen, and the two documents I wrote that way, the Funding Journey and the HapplyOS overview, are still the reference the team works from.
Design systems and AI matching are the parts people notice. The rules underneath are the parts that made it work.