From one-off tips to recurring revenue

Portaly is a personal page and monetisation tool for creators. Its existing support feature centred on one-off support: a fan lands on a creator's page, enters an amount, leaves a message, pays — and the relationship is over. That model hits a ceiling on three fronts:

Competitive analysis (added later)Landscape · three assumptions · positioning matrix

This project came out of a decision-maker's request in an internal development meeting, with no supporting data at the time. I did the competitive analysis afterwards, against the market as it then stood, to understand the commercial reasoning behind the decision.

How I grouped them: by job-to-be-done, not product category

The two groups threaten us in completely different ways and are defended against differently, so I looked at them separately.

Group A | Solving the same problem: giving creators predictable recurring income

Only three dimensions actually affect the decision:

Competitor	Eligibility bar	Relationship is tied to	Taiwan payments / e-invoice
YouTube channel memberships	YPP threshold (1,000 subscribers + 4,000 hours, or 10M Shorts views)	YouTube account	✕
Twitch subscriptions	Affiliate / Partner threshold	Twitch account	Requires bolting on OPay / ECPay
vocus subscriptions	None	On-site content library	✅
Patreon	None	Patreon account	✕
Ko-fi / Buy Me a Coffee	None	Each platform's own page	✕
Linktree Subscriptions	None	The creator's own page	✕
Portaly (at the time)	None	The creator's own page	✅

Revenue share for reference: YouTube 30% / Twitch 50% (top partners can negotiate 70/30) / Linktree 9–12% / Patreon 5–12% plus payment fees / Ko-fi and BMC 5% / Portaly 12% (free plan) and 6% (top plan).

→ Taken together, the only true direct competitor in group A is Linktree. The rest are either built into a content platform or are pure membership platforms, and their entry logic differs from link-in-bio.

Group B | Alternatives that could replace us

• Competing for the same monthly budget from fans (zero-sum): PressPlay (courses and content subscriptions), Firstory (podcast support), Substack (newsletter subscriptions). There is a ceiling on what a fan can reliably give away each month.
• Creators achieving predictable income another way: long-term sponsorship contracts, group buys and affiliate revenue, repeat sales of digital products, online courses — including our own one-off support. "Someone tips every month anyway" also reads as predictable income to a creator, so a new feature first has to compete with the old one for attention.

Three assumptions

Shared assumption	The question nobody asks
① Recurring support only works if it is tied to perks YouTube gives badges and custom emoji, Patreon's whole product philosophy is tiers plus perks, vocus ties it to paid content, Ko-fi is tiered content too	When a fan pays every month, is it for those things, or to let the creator know they are still there? Perks may be the explanation the product invented rather than the real motive for the behaviour. Accept the premise and you have to build a content wall and access control, while raising the bar for creators — who now need exclusive content before they can even turn the feature on.
② Recurring support is a one-way automatic charge from the fan, with the creator a passive recipient Every platform runs on "fan sets it up → system charges → creator reads the report"	If a subscription is most fragile at the moment a fan forgets why they are still paying, shouldn't the product be giving the creator the means to sustain the relationship rather than making the charge smoother?
③ This mechanism belongs wherever the creator's content lives You collect subscriptions where you publish	Small and mid-sized creators already work across platforms (Instagram, YouTube, podcasts, newsletters). Their audience is spread out while the support relationship is locked to a single platform — which means rebuilding the list of paying supporters every time they change their main stage.

The assumption most worth breaking: ① tying support to perks

Assumption ③ is already broken by the nature of link-in-bio, but not by us alone — Linktree is in the same position, so it is a qualification, not a differentiator. Assumption ② is worth doing but comes second: before you can nurture supporters, you need supporters. Assumption ① is the only one whose breaking lowers the barrier on both sides at once.

Breaking it opens three layers of opportunity:

1. The creator's setup barrier drops to almost nothing — no need to design three tiers and decide what each one gets. That is precisely why so many Patreon accounts get created and never launch. It speaks directly to small and mid-sized creators below the YouTube threshold whose main presence is Instagram or a podcast.
2. The product's centre of gravity moves from the content wall to the visibility of the relationship — if a subscription is fundamentally an identity rather than a product, the thing to build is not access control but ways of making support visible: a supporter list, consecutive months of support, one-tap thanks, a recognisable badge. Far less engineering complexity than a perks system, and closer to the real motive.
3. It unlocks assumption ② in reverse — once the relationship is not tied to content, the creator ends up holding a portable list of long-term supporters they can build on.

Whether this opportunity holds depends on whether "fans pay for identity, not perks" is actually true. It should be treated as a hypothesis to test, not a conclusion. Testable indicators: the second-renewal rate and month-2 retention on a version with no perks, and how fans themselves attribute why they support.

Positioning matrix

How I chose the axes: they had to separate the existing players and be structural — hard for a competitor to move on in the short term. ("One-off vs recurring" stops distinguishing anything the moment someone ships the feature; "revenue-share percentage" can be copied in a price war. Neither was used.)

• X axis | Where the support relationship lives: to the left it is bound into a platform account; to the right it leans towards the creator holding it themselves. Membership mechanisms like YouTube's and Twitch's are part of those platforms' ecosystems by design, and are unlikely to move the other way.
• Y axis | Why people keep supporting: towards the top, paying for content, membership status or exclusive perks; towards the bottom, wanting to keep supporting this particular creator and maintain a long-term connection.

What the chart shows is that few products currently manage all of this at once: a low setup barrier, the support relationship in the creator's hands, no need to produce members-only content, and support for Taiwanese payments and e-invoicing.

There is room in that position for more than just the fact that nobody is there yet:

1. YouTube and Twitch are unlikely to move this way: their membership features exist precisely to keep creators and supporters inside the platform, so handing that relationship back to the creator runs against their interests.
2. Overseas products like Patreon and Ko-fi face a real cost to enter Taiwan: beyond the interface language, they would need to handle Taiwanese payments, e-invoicing and other local requirements, which they may not prioritise for this market.
3. Linktree is the closest competitor: its product direction is already near "the creator's own support entry point", and if it fills in Taiwanese payments and local requirements it becomes the one to watch.

→ This exercise confirmed two things for me. First, one-off and recurring support generally coexist in the market rather than replacing one another, so v1 kept one-off support. Second, Portaly still had differentiated room in the position of "the creator holds the support relationship, with local Taiwanese payments" at that time.

References

• Portaly pricing
• YouTube Partner Program overview & eligibility
• Get started with YouTube channel memberships
• Analyse & manage YouTube channel membership levels
• vocus revenue share & payout guide (Chinese)
• A Letter from Twitch President Dan Clancy on Subscription Revenue Shares
• Patreon vs Ko-fi vs Buy Me a Coffee 2026 fee comparison
• Linktree Pricing: All Plans, Fees & True Cost (2026)
• OPay recurring credit card API documentation (Chinese)

→ The core premise: once payment goes from once to every month, the transaction stops being an event and becomes a relationship. What needs defining is not just a payment screen but a state system that both parties act on separately and that has to stay consistent across systems.

The request started as "add a monthly option to the support page", but in reality it touches payment, subscription state, list management and notifications. So I mapped the full service flow and everything affected first, then defined the behaviour and states for each situation.

System architecture

Working through the architecture and the flows on each side, two things became clear that also had to go into the spec:

Subscription lifecycle & state transitions

Monthly recurring support is not a one-shot flow. Renewals, cancellations, failed payments and refunds keep changing the subscription's state, and each change ripples through the public page, back office, payments and notifications. So I defined the states and transition rules up front, which made them easy to discuss with the team, and wrote the rule table into the PRD.

Business rules

With the flow and rules settled, I narrowed the scope for v1. One-off support stayed as it was, and recurring support prioritised completing the basic subscription flow, avoiding too much payment and membership machinery in the first release.

Of these, self-service cancellation was treated as essential for v1. A recurring payment has to be stoppable as well as startable: supporters need to know the state of their subscription and be able to end future charges themselves. More advanced management like changing cards or tiered perks could wait for a later release.

Two further calls

• High-risk actions do not belong on the list page: the list is what creators browse most, with a button on every row, so the cost of a misclick is highest there. The irreversible refund was therefore moved to the payments page — where the context is already "I am dealing with a payment".
• Asynchronous payments belong in the copy: refund status takes around 3–5 minutes to update, so the delay is stated in the confirmation dialog itself, stopping creators from assuming the system failed and repeating the action.

→ "Money" and "relationship" are two different states, and how reversible an action is should determine where it lives.

Those rules landed in three core scenarios: supporter payment, the subscription lifecycle, and creator management. What follows is a representative walk through each, rather than every screen.

01 | The core transaction experience

Supporter payment flow — Choose monthly → fill in the details → 3-D Secure card verification → receive the confirmation email

• One-off and monthly sit side by side as tabs, and switching tabs preserves what has already been typed — switching is an act of comparison, not of giving up
• Preset amounts lower the cost of the decision; a custom amount catches the highly motivated supporter
• Supporters can complete a recurring payment without registering, so the confirmation email is both the receipt and the entry point for managing it afterwards

02 | Subscription lifecycle & edge cases

The real complexity in recurring support is not the first payment but everything after it: renewals, cancellations and refunds each change the state in four places at once — public page, back office, payments and email. Below is the state transition for cancellation and refund, then two representative paths: the supporter cancelling themselves, and the creator issuing a refund.

Path 1: The supporter cancels

• The entry point is in the transaction email rather than an on-site account area — supporters never registered for Portaly, so the management page has to be reachable straight from the email
• The management page always shows the support status and the next charge date, so supporters know at any moment what state they are in and what happens next
• Cancellation is reversible, so a standard confirmation dialog is enough; once done, the state updates immediately and both sides are notified

Path 2: The creator issues a recurring refund (irreversible)

• A recurring refund = refunding the current transaction + ending the future subscription. It is a different thing from cancelling, so it does not share an entry point
• High-risk and irreversible, so the entry point sits on the payments page, not the supporter list where every row has a button
• Asynchronous payments: the 3–5 minute processing delay is written into the confirmation dialog, so creators do not assume failure and repeat the action

03 | Managing long-term supporters

The list shows the most recent support date, the supporter, subscription status, amount, number of payments made, cumulative amount, message, email and cancellation reason, and can be exported. Active subscriptions always sort above cancelled ones, then by date.

• Cumulative amount and payment count turn a "long-term supporter" from a series of transactions into someone identifiable a creator can build a relationship with
• Creators can also cancel a subscription from the list (stopping the next charge only, with no refund), kept clearly separate from the refund on the payments page

04 | Other product touchpoints

• Creator settings: one-off and recurring toggle independently, and the result shows immediately in the public-page preview, dropping the cost of checking to zero. A restriction notice appears only when recurring is on and PayPal is enabled; turning both kinds of support off warns first that the support block will disappear from the public page
• Transaction emails: successful support, cancellation and e-invoice issuance each have their own email, forming a second layer of state synchronisation outside the product
• Launch communication: a back-office dialog announcing the feature, with the CTA going straight to the settings page

Product communication

Monthly support is a new model layered on top of existing one-off support, so once the feature was done I planned three main surfaces to shorten the distance between a creator knowing about it and starting to set it up:

• In-product dialog: surfaces the new feature in the back office, with the CTA going to the settings page.
• Feature announcement email: a concise explanation of how to use it.
• Help-centre article: focused on what it is, what it gives you and how to turn it on, communicating the value as "let your fans support your work consistently".

The copy is written from the creator's revenue perspective throughout: "let your fans support your work consistently", rather than "we added monthly subscription payments". Same feature — the first is income, the second is a support ticket.

After launch, the team's first questions were whether the feature was actually being used, and how much revenue monthly support added to the existing support business.

In a revenue mix that had only ever had one-off support in it, the newly launched recurring model contributed more than a third of support revenue in the very first month of observation — a sign that creators and supporters were genuinely adopting this way of giving.

While writing the PRD I also broke down the feature's metrics. The goal here was not just to collect more money but to turn one-off support into ongoing support, so I did not think revenue alone was enough: a handful of large supporters can push revenue up without telling you whether a recurring relationship has actually formed.

So I split impact into two levels:

The first tells me whether the result is good; the second helps judge whether it can last, and where to optimise next.

I moved on to other projects afterwards and did not keep getting complete renewal and retention data, so this covers an initial read on the business result only — long-term retention has not been validated.

The full metric breakdownSuccess · execution · trade-off · ecosystem metrics

Success metric | Is this feature working

Recurring support relationships successfully renewed that month
The number of creator × supporter pairs charged successfully at least once during the month and still active at month end.

Not revenue as the success metric: a few large supporters can inflate the number while relationships are quietly draining away. This one factors into a product:

Recurring relationships this month = new relationships × renewal success rate

Execution metrics | The three things we can push on directly

Metric	Calculation	Which side of the product it moves
① Creator adoption rate	Active creators with recurring on ÷ active creators with a support block	New relationships
② First-purchase conversion	Completed first recurring payments ÷ visitors to the support page	New relationships
★ ③ Second-renewal success rate	Successful second-period charges ÷ successful first payments	Renewal success rate

③ matters most: it is what tells you whether monthly support actually makes a creator's cash flow steadier month to month.

Trade-off metric | What this launch might affect

• One-off support revenue and volume: whether monthly support cannibalised the one-off support that already existed.

Ecosystem metrics | What the company was actually watching

• Fixed monthly recurring support revenue (how much recurring support comes in per month)
• Cumulative recurring support revenue
• Share of creators who have enabled monthly recurring support

How the market responded

After launch, public examples showed creators treating monthly recurring support as more than a source of ongoing income, extending it into different ways of working: subscriber-only rewards, incentives for continuous support, or a permanent support link in podcast and social content.

These cases suggest users did not see the feature as simply an automatic monthly charge, but went on to use it to build long-term support relationships and a way of nurturing their fans. Portaly's founder has since publicly mentioned that some creators have built monthly subscription revenue in the six figures through the feature.

1. How should the management area work when someone supports several creators

• v1 did consider managing subscriptions to multiple creators, but to validate quickly I chose to reuse the existing email-based management rather than build a central hub. That cut development cost and time, and it also added friction to cancelling — which happens to favour renewals, but at the expense of convenience for anyone with several subscriptions.

→ It made me realise there is no standard answer to the trade-off between user experience, business goals and technical cost. An MVP can accept a degree of friction for the sake of validating quickly, but that friction should come from a conscious product decision, and should be checked after launch against cancellation rates, renewal rates and how people actually use it.

2. Launching a feature is more than finishing the design

• My earlier project experience focused fairly narrowly on the feature itself. Working on the in-product dialog and the announcement email here, I started to see that finishing the product is only the first step; whether users know about it, understand it and are willing to start using it is equally part of the product experience.

→ Planning it again, I would fold launch communication into the impact tracking, building a complete funnel from email opens and CTA clicks through to activation, and from dialog impressions and clicks through to activation.

3. A metric framework has to be agreed with decision-makers, not designed behind a closed door

• The PRD defined feature metrics like renewal and retention, but what the company actually tracked was fixed support revenue, cumulative revenue and adoption rate. The two frameworks were never reconciled in advance, so some metrics simply stopped being tracked.

→ Next time I will agree the success metrics with decision-makers before launch, so the data genuinely becomes the basis for what gets decided next.