Affiliate Portal

The Affiliate Portal is Fuul's self-service product for end-user affiliates. It gives affiliates a dedicated place to apply to programs, track earnings, manage referral links, understand multi-level commissions, inspect referred users, and claim rewards without needing access to project-admin tooling.

I bootstrapped the product from an empty Next.js application and have been its near-sole frontend owner since the first commit. The work spans application architecture, product UX, visual systems, data fetching, SDK integration, feature-scoped backend contracts, onboarding forms, CRM sync, and Web3 claim flows.

This project is one of the clearest examples of the kind of work I like to own: a complex product surface where design craft, frontend architecture, and business-critical workflows have to work together.

Why this project matters

Fuul helps projects run referral and incentive programs. But the people who drive those programs — affiliates, creators, partners, and referrers — need a different experience than project admins.

An affiliate does not want to configure an incentive campaign. They want to answer practical questions quickly: What have I earned? Who did I refer? Which commissions are active? What is my link? Can I claim now?

Before this portal, many of those answers lived in the wrong place: inside admin dashboards, across earlier experiments, or behind manual support from project teams. That created operational drag for clients and a less transparent experience for the affiliates whose activity the protocol depends on.

The Affiliate Portal turns that into a dedicated, branded, self-service product surface.

My role

I owned the portal as the sole frontend owner and design engineer.

My work included:

• Bootstrapping the Next.js application from an empty repository.
• Defining the dashboard architecture, view navigation, component structure, and data-fetching strategy.
• Designing and implementing the main affiliate experience across dashboard, links, claims, commission activity, referred users, resources, and master-affiliate views.
• Building the affiliate application and onboarding flow, including wallet gating, dynamic form sections, validation, edit/prefill behavior, and submitted states.
• Implementing the server-side submit path for the onboarding form, including CRM sync, rollback behavior, rate limiting, and field-level error mapping.
• Creating reusable UI primitives, branded themes, tables, charts, cards, dialogs, empty states, loading states, and error states.
• Authoring the SDK data layer consumed by the portal.
• Contributing feature-scoped backend endpoints when the frontend required new data contracts.
• Building cross-chain reward claiming flows across EVM and Solana contexts.
• Creating a fixture-backed demo mode so the product could be shown without exposing live customer data.

This was not just a set of UI tickets. It was a product build: frontend architecture, design system, data contract, product UX, and production behavior.

Product problem

The portal had to solve several problems at once.

First, affiliates needed a self-service home. They needed to apply to programs, access referral links, monitor earnings, understand commissions, and claim rewards without going through project admins.

Second, the data was hierarchical. Some programs support multi-level structures, where an affiliate earns from direct referrals and from sub-affiliates beneath them. That meant the UI had to make R1–R4 levels, paid volumes, commission breakdowns, referral trees, and sub-affiliate performance understandable.

Third, rewards are claimable on-chain. The product had to guide users through wallet connection, claim eligibility, network switching, transaction submission, optimistic UI states, and backend reconciliation.

Fourth, this had to work for multiple partner brands. The portal could not be a one-off dashboard. It needed a reusable product foundation that could support different identities without forking the app per client.

Approach

I treated the portal as a multi-tenant product from the beginning.

The app is structured around a focused dashboard experience with lightweight view-based navigation. Moving between stats, links, claims, commission activity, referred users, resources, and bonus-related surfaces feels immediate, while the overall experience remains cohesive.

For state management, I intentionally kept the product centered on TanStack Query. Most of the portal is server state: stats, links, claim checks, payouts, referral trees, audiences, eligibility, and program data. Modeling that through query keys, caching, mutations, and invalidation kept the state model honest and reduced the risk of a separate client store drifting away from backend truth.

For onboarding, I treated the affiliate application as more than a form. The hard part was the submit path: keeping credentials off the client, creating related records in a CRM, rolling back partial failures, and mapping server-side validation errors back to the exact fields the user needed to fix.

For claims, I built the flow around trust. Users needed to understand what was claimable, what wallet or network was required, what was already claimed, and what changed after a transaction. The UI had to feel reliable because the action involves real rewards.

For theming, I separated product structure from brand expression. The same app foundation can support distinct branded experiences — including a glassmorphic Fuul design and partner-specific identities — without changing the core data model or user journey.

Selected contributions

Product architecture from zero

I started the portal from an empty Next.js application and shaped the foundation around a clear dashboard model, reusable UI primitives, typed API hooks, shared layout patterns, and brand-aware styling.

That gave Fuul a dedicated affiliate-facing product instead of stretching admin tooling into an end-user experience.

Affiliate application and onboarding

I built the affiliate application flow: the front door for affiliates applying to join a program.

The form is wallet-gated and organized into clear sections for contact details, social channels, recommendations, and agreement. It includes inline validation, conditionally revealed fields, dynamic add/remove social-channel rows, a prefilled edit path for existing applicants, and a persistent submitted state.

The frontend uses react-hook-form and Zod to keep validation predictable, while the submit path runs through a server-side route so sensitive CRM credentials never reach the browser.

Reliable CRM sync behind the form

The onboarding form looks simple from the outside, but the backend contract matters.

On submit, the server-side flow creates several related records in a CRM as one coordinated operation. If part of the process fails, the route rolls back the partial work instead of leaving a half-created applicant state behind.

I also handled endpoint rate limiting, server-side validation, prefill/edit behavior, and field-level error mapping so users see actionable feedback instead of a generic failure.

Affiliate dashboard

I built the main dashboard with earnings summaries, claimable rewards, performance indicators, referral activity, and contextual empty/loading/error states.

The goal was to make the first screen answer the affiliate's most important questions immediately: what is happening, what have I earned, and what can I do next?

Multi-level commission analytics

I built analytics surfaces for multi-level affiliate programs, including R1–R4 commission breakdowns, paid-volume views, active trader stats, and referral-tree data.

The design challenge was to make hierarchical performance data readable. Affiliates needed to understand not only their direct results, but also how activity flows through the network beneath them.

Master-affiliate views

I built a master-affiliate experience that lets a top-level affiliate inspect performance through a selected sub-affiliate context.

This changed the portal from a personal stats page into a management surface for affiliates operating larger networks.

Referral links and codes manager

I built the referral links and codes manager, including create, manage, and disable flows, confirmation dialogs, and clear split-versus-actual percentage information.

This gave affiliates control over how they share and manage referral access while keeping destructive actions explicit and safe.

Cross-chain reward claiming

I implemented claim flows across EVM and Solana-based rewards.

The claim experience includes open claim checks, wallet connection states, backend-signed claim data, batched claim execution, network-switch guidance, optimistic UI updates, already-claimed guards, and reconciliation against backend state.

This was one of the most trust-critical parts of the product because the UI had to guide users through real wallet and transaction behavior without making the experience feel fragile.

Multi-brand theming

I delivered multiple branded versions from the same application foundation, including a glassmorphic Fuul experience and partner-specific themes.

The important part was not only changing colors. Each brand needed to feel intentional while still relying on the same product architecture, component model, and data flows.

Demo mode

I built a fixture-backed demo mode so the portal could be shown end to end without using live customer data.

This made the product easier to present to partners, review internally, and capture safely for sales or portfolio material.

SDK and backend contract ownership

I authored the SDK service layer used by the portal and contributed feature-scoped backend endpoints for the views I was building.

That allowed me to shape the contract from server response to SDK method to UI hook, making new analytics and claiming surfaces faster to build and easier to keep consistent.

Outcome

The result is a self-service affiliate portal that gives end users a dedicated place to manage their referral work: applications, earnings, links, referred users, commission breakdowns, and reward claims.

It also created a reusable foundation for Fuul and partner brands. Instead of building separate affiliate dashboards per client, the portal can support multiple visual identities and program configurations from the same codebase.

From a product perspective, the portal reduces the need for project teams to answer routine affiliate questions manually. From a technical perspective, it gives Fuul a focused, extensible product surface for affiliate-facing workflows.

I do not include quantitative metrics here because I do not have public, validated usage, conversion, or claim-volume numbers to share. The impact is framed qualitatively and based on shipped product capabilities.

Links

• Live demo — demo-affiliates.fuul.xyz
• Nado — nado.fuul.xyz — a live partner-branded deployment of the portal
• Fuul — fuul.xyz
• Company — kuyen.xyz