Gustavo Polin
B2B SaaSMarketplace

AgencyHub

A two-sided marketplace where digital agencies buy white-label services from vetted providers and resell them to their own clients.

Role

UX/UI Designer

Period

3 months

Scope

Marketplace, checkout, orders, provider tools

Project overview board with the marketplace summary, role, and duration

01/14·Overview

Project at a glance

The challenge

Agencies wanted to offer more services without hiring. But finding reliable vendors was slow, and a bad vendor costs an agency its client.

My role

Product design end to end: research, flows, information architecture, UI, and the component system, for both sides of the marketplace.

The outcome

A marketplace where an agency can find a vetted provider, buy a service, charge its own client, and manage delivery, all in one system.

Context

Digital agencies grow by saying yes. When a client asks for SEO and the agency only does ads, the agency either hires, refuses, or finds a white-label partner. Most choose partners, and most find them by trial and error. Every failed partnership costs money twice: the wasted spend, and the client who leaves.

AgencyHub's bet was that vetting could be a platform feature instead of a private struggle. For that to work, the product had to serve two sides with opposite needs: providers want to list fast, agencies want to trust what they find.

Two sides, three parties

On paper this is a standard two-sided marketplace: providers list and fulfill services, agencies browse and buy. The flows looked normal until one detail changed everything: the agency is not the end customer. It buys a service, marks it up, and delivers it to its own client.

That third party never logs in. But they pay, they provide requirements, and they judge the result. Most of the hardest design decisions came from this triangle, not from the marketplace itself.

AgencyHub provider and agency user flows
The two-sided system map: a provider path that ends in an approval gate, and an agency path where checkout can detour through the client before fulfillment begins.

Constraints

Trust is the product

The entire value proposition is that agencies stop vetting vendors themselves. Every catalog and listing decision had to defend that promise, even at the cost of growth.

Three parties, one transaction

Payment can come from someone who isn't the buyer and never logs in. Orders, notifications, and checkout all inherit that complexity.

One designer, three months

Marketplace, cart, orders, and provider tools had to ship together, which made a shared component system a necessity, not a preference.

Key decisions

Decision 01 · Who pays at checkout?

Checkout can end with a payment link instead of a payment.

A normal checkout assumes the buyer pays. Here, the agency often needs its client to pay first. So checkout offers two endings: pay now, or create a payment link and send it to the client. The order starts when the client pays, and the agency never fronts money for work it has already sold.

Trade-off accepted: An order can now exist in a "waiting for client" state. That made status logic more complex for every other part of the system: orders, notifications, and fulfillment all had to understand a purchase that isn't paid yet.

AgencyHub checkout with card, payment link, and account balance options
The decision in one screen: card, balance, or a payment link sent to the client. Selecting Payment Link turns the primary action into "Create A Payment Link".

Decision 02 · How does trust get into the catalog?

No service goes live without approval.

Providers can create a listing in minutes, but publishing requires review. This is slower for providers and adds operational work for the platform. We accepted both costs, because a marketplace that lists everyone is just another search problem, and the one thing agencies were promised is that what they find is already vetted.

Trade-off accepted: Slower catalog growth, accepted in exchange for the one claim competitors couldn't make.

AgencyHub marketplace with curated service listings
What an agency browses is already approved: curated categories with scope and starting prices up front, because the vetting happened before the listing went live.

Decision 03 · Where does the client fit in delivery?

Communication lives inside the order, with room for three parties.

Requirements, revisions, and updates flow through a shared space attached to the order, shared by agency, provider, and the client when needed, instead of email threads the platform can't see. The platform can only resolve disputes about work it can observe, and the order is the only object all three parties share.

Trade-off accepted: Building communication into the product is expensive, and asking users to leave email is a real adoption risk. The bet was that order-anchored context is worth the switching cost.

AgencyHub cart with order details and totals
The order as the shared object: plan, setup fee, quantity, and totals carried from cart through fulfillment, so every conversation has the same source of truth.

System & workflows

Marketplace, cart, orders, and the provider's store were built from one set of components and layout rules. For a solo designer on a three-month timeline this wasn't aesthetic discipline; it was the only way to ship four coherent surfaces at once.

The same system absorbed the project's odd states, like orders waiting on a client and listings waiting on approval, without inventing new patterns for each.

Outcome & reflection

The design made a new behavior possible: an agency can sell a service it doesn't deliver, with payment, requirements, and fulfillment handled by the platform instead of spreadsheets and email.

Vetting moved from a private, per-agency struggle to a platform feature. The approval gate is the product's trust claim, enforced by design.

Four surfaces shipped in three months from one component system, by one designer.

Reflection

If I continued this work, I would instrument the two riskiest decisions: how many checkouts end in a payment link, which shows whether the third-party flow is real demand, and how long provider approval takes, because trust is only a feature if it doesn't strangle supply.

View Full Case Study (PDF) →