/// Compare / Distribution

Standalone product vs embedded

Same capability, two ways to ship it. A standalone product is your own app that users come to; an embedded one is a widget or SDK that lives inside a product they already use. One owns the relationship and does the acquiring; the other borrows an audience and gives up the surface. Neither is a lesser version of the other — they're different bets on where your users already are.

Talk to us See the Ramp widget

/// Two ways to ship

Where the tradeoff actually lives

Dimension

Standalone product

Embedded / whitelabel

Where the user is

You bring them to you. A standalone app is a destination — you own the front door and the whole session, and you pay to fill it.

You meet them where they already are. An embedded widget or SDK rides inside a product with the audience already assembled.

Who owns the experience

You, entirely. Every screen, flow, and moment of the journey is yours to design and change.

Shared. You own the component; the host owns the frame around it, and your surface stops at the edges they give you.

Integration cost

Build and ship an app: stores, updates, auth, the lot. Higher up front, but nothing depends on a host's constraints.

A widget or SDK drop-in — days to weeks — but bounded by the host's platform, review, and release cycle.

Brand

Front and centre. Users know whose product they're in, and the relationship is direct.

Dialled to taste — from co-branded to fully whitelabel, where the capability looks like the host's own and yours stays invisible.

Distribution & acquisition

Yours to earn. Growth is your marketing, your funnel, your cost of acquisition — slower to start, compounding when it works.

Borrowed. You inherit the host's traffic and context, so a feature can reach users on day one — but on the host's terms.

Revenue & relationship

Direct. You own pricing, the customer, and the data — and carry the full cost of serving them.

Mediated. Economics are shared with the host, and the end-customer relationship is theirs first, yours through them.

/// 01

When standalone wins

Ship your own product when the relationship is the asset. If you need to own the customer, the data, and the roadmap — because the product is the business, not a feature of someone else's — a standalone app is the only shape that gives you all three. It wins when the experience is the differentiator and can't survive being squeezed into a host's frame, and when you're willing to earn distribution rather than borrow it. The cost is real: you build the whole app and you pay to acquire every user. The payoff is that nothing about your product depends on a host's permission.

[ 01 ]The customer relationship and data have to be yours, directly
[ 02 ]The experience is the differentiator and needs the whole screen
[ 03 ]You're prepared to build and market a destination, not a feature
[ 04 ]You want to own pricing, roadmap, and the funnel end to end

Protocore Pay — whitelabel apps PDS design system

/// 02

When embedded / whitelabel wins

Embed when the users are already somewhere else. If the capability is more valuable as a feature of an existing product than as a destination of its own — an on/off-ramp inside a wallet, a payment step inside a marketplace, a wallet inside a game — then a widget or SDK gets it in front of an assembled audience in days, without asking anyone to download another app. It wins when speed and reach matter more than owning the frame, and when 'invisible, and it just works' beats 'branded, and they had to come find it.' The trade is the surface and a share of the economics — you're a guest in someone else's product.

[ 01 ]The capability is a feature of another product, not a destination
[ 02 ]The audience is already assembled somewhere you can integrate
[ 03 ]Reach and time-to-users beat owning the whole experience
[ 04 ]Whitelabel or co-brand — being invisible is a feature, not a loss

Ramp — embeddable widget Wallets — embedded SDK

/// 03

Where Protocore fits

You don't have to pick once and forever. Protocore ships the same capabilities both ways: Ramp is an on/off-ramp you can run as a standalone flow or embed as a widget inside your product; Wallets is an SDK that lives inside your app; and Pay is a whole app you run standalone under your brand. The same core sits under all of them, so a capability you embed today and a product you stand up tomorrow share one ledger and one operator console. Start embedded to borrow an audience, go standalone when the relationship is worth owning — or run both, without rebuilding the thing underneath.

[ 01 ]Ramp runs standalone or embeds as a widget — same core either way
[ 02 ]Wallets is an SDK that lives inside your app, keys never leaving the device
[ 03 ]Pay is a full standalone app under your brand on the same ledger
[ 04 ]Embed now, stand up your own product later, without a rebuild

Ramp Wallets PDS

Standalone, embedded, or both?

Tell us where your users already are and what you need to own. We'll help you pick the shape — a destination, a widget, or a bit of each.

Talk to us