Explainers · 2026-06-20 · ~3,800 words

Patreon for technology creators: complete 2026 guide — debugging sequences, code review tier mechanics, architecture decision records, tech reviewer frameworks, and the Apple Tax

Technology Patreons fail when they replicate what YouTube already delivers well: clean walkthroughs, polished explanations, finished demonstrations. They work when they deliver what YouTube actively penalizes: the debugging sequence the editor removed, the architectural reasoning the repository cannot show, the evaluation framework the review condensed into a verdict. The highest-retention technology Patreon content is not more of what the public channel produces — it is the process behind what the channel produces, documented at the level of resolution that only a patron relationship can justify.

Why YouTube removes the most retentive content

The YouTube algorithm optimizes for watch time and click-through rate. Both metrics reward videos that feel clean, confident, and paced — which means the editing process systematically removes content that is slow, uncertain, or requires the viewer to sit with ambiguity before resolution arrives. Debugging sequences fail on every dimension the algorithm rewards. They are slow. They show the creator being wrong. They require patience before the fix appears. They are cut.

What they contain is exactly what makes them the highest-retention content a coding tutorial creator can publish as a Patreon exclusive. The debugging sequence is not just more content — it is a qualitatively different type of content that the public channel's format makes structurally impossible to deliver. A patron who understands this is not paying for access to extended runtime. They are paying for access to a mode of documentation that YouTube cannot host without paying an algorithmic penalty.

The same structural logic applies across all three technology creator types. For coding tutorial creators, it is the debugging sequence. For developer and open-source creators, it is the architecture decision record — the reasoning process behind each significant technical decision, which is invisible in the repository and impossible to explain in a watchable YouTube video. For tech reviewers, it is the evaluation framework documentation — the criteria and methodology behind each verdict, which a seven-minute review can only gesture at. In each case, the Patreon exclusive is the process the channel compresses. The channel delivers the output of the process. The Patreon delivers the process itself.

The debugging sequence: what it contains and why it teaches

A debugging sequence is not a recreation of what went wrong — it is a documentation of how the creator reasoned toward what was right. These are different documents. A recreation might show the error message, skip to a hypothesis, and then show the fix. A documentation shows the error message, explains why it is confusing (not just what it says), documents the first hypothesis and the evidence that made it plausible, follows the specific diagnostic steps taken to test that hypothesis, then explains what observation eliminated the first hypothesis and pointed to the correct fix, and finally explains why the fix works at the mechanism level rather than just demonstrating that it resolves the symptom.

These six elements are the structural content of a debugging sequence post:

The actual error encountered and why it is confusing. Not just the error message — which is in the public video anyway, framed as a problem that was solved — but the analysis of why the error message misdirects a developer reading it for the first time. Error messages often point at the symptom, not the cause. A null reference exception in the calling function may trace to an uninitialized dependency injected two layers back. A timeout exception may trace to a synchronous operation blocking an async context. The error message names where the problem manifested, not where it originated. A patron reading the debugging sequence learns to read error messages diagnostically — as data about symptoms that require interpretation rather than as literal descriptions of the problem location.

The first hypothesis and what made it seem right. The creator's initial interpretation based on visible symptoms — and specifically the evidence that made that interpretation plausible. This is the part of debugging that most documentation skips: the reasoning that led to the wrong place. Documenting it serves two purposes. First, it is honest — most debugging involves at least one wrong hypothesis, and presenting only the correct path misrepresents how debugging actually proceeds. Second, understanding why a wrong hypothesis seemed right is often more instructive than understanding why the correct one was correct. A patron who recognizes the pattern that led the creator astray — miscorrelated symptoms, a familiar-looking error in an unfamiliar context, a surface similarity to a previously solved problem — has learned something about their own diagnostic reasoning that a clean walkthrough cannot teach.

The specific diagnostic steps taken to test the hypothesis. Not "I checked the docs" — which specific docs, which section, what the creator was looking for and what they found. Not "I added some logging" — which values were logged, where, what they showed, and what that indicated about the hypothesis. The specificity matters because the diagnostic approach is what transfers across languages and frameworks. A patron learning "when I'm uncertain whether a value is what I expect at this point in the execution, I add an assertion with a specific error message rather than a print statement" has acquired a technique. A patron learning "the creator checked the docs" has acquired nothing transferable.

Why the hypothesis was wrong. The specific observation that eliminated the first hypothesis — not just "it didn't work" but what the result of the diagnostic steps revealed that contradicted the hypothesis. This is the moment where the investigation pivots, and documenting it teaches pivoting: how to recognize when the evidence is telling you that your mental model is wrong rather than that your implementation is imprecise.

What observation pointed to the correct fix. The specific detail or behavior that broke the false pattern and redirected the investigation. Often this is something the creator noticed at the periphery — a value that was off by a factor of two, a timestamp that didn't align with the expected call sequence, a stack trace that went one frame deeper than expected. Teaching patrons to notice peripheral observations trains debugging attention in a way that no amount of correct-path walkthrough can produce.

Why the fix works at the mechanism level. Not just that it resolves the error — but why, at the level of how the system actually operates, applying this fix produces a different execution path. A patron who understands why the fix works can apply the same reasoning to a structurally similar problem in a different codebase. A patron who only knows that the fix worked has acquired a specific solution, not a generalizable understanding.

The retention value of debugging sequences is cumulative. A patron who has watched five debugging sequences from the same developer has learned how that developer reads error messages, what diagnostic approaches they reach for first, what their mental model of the relevant system looks like, and how they reason about systems they partially understand. This is a profile of a developer's thinking that no polished tutorial can produce — because polished tutorials, by design, present the thinking after it has been refined. Debugging sequences present the thinking as it happens. That is what makes them the highest-value exclusive a coding tutorial Patreon can offer.

Developer tier versus Code Review tier: what patrons at each level actually need

The Developer tier and the Code Review tier are not different quantities of the same thing. They are different types of relationship between the creator and the patron.

The Developer tier is one-directional. The creator produces — annotated source files, debugging sequences, extended tutorial cuts, monthly tech stack posts — and the patron consumes. The patron receives finished artifacts: more complete, more annotated, more extended than what the public channel delivers, but still artifacts that the creator produced independently and the patron receives. The patron's specific situation, their specific code, their specific decisions, are not part of the exchange.

The Code Review tier is bidirectional and personal. The patron submits their own work and the creator responds to it specifically. A Code Review patron is not getting "more code from the creator." They are getting the creator's expert evaluation of their specific architectural choices — a qualitatively different product. The creator is not producing something for a general audience and delivering it to the patron. The creator is reading something the patron built and providing a response calibrated to what that patron specifically decided.

The submission protocol that makes Code Review workable

Without a structured submission protocol, the Code Review tier degrades quickly. Open-ended submissions — "here is my repository, let me know what you think" — require the creator to spend the first 20 minutes of the review just orienting: what is being built, what is the domain, what maturity level is the code, what is the patron actually uncertain about. The review becomes primarily orientation time with 10 minutes of actual evaluation at the end. This is not useful for the patron and is exhausting for the creator.

The submission protocol that makes code review workable requires three things in addition to the code itself: (a) what the patron is building, in one to two sentences — the domain and the purpose, not the implementation; (b) the specific decision they made that they are uncertain about — not "can you review my code" but "I chose to handle authentication by storing the session token in Redis with a 24-hour TTL rather than using JWTs, and I'm not sure whether this creates problems I haven't anticipated"; (c) what they want to know — the specific question they are bringing to the creator rather than a general request for feedback.

With this protocol, the creator can give a focused, useful response in 30 to 45 minutes. The first ten minutes are reading the code with the specific decision in mind. The next twenty minutes are evaluating that decision against the context the patron provided — what the protocol is optimizing for, what it trades away, what problems it creates at scale, what alternatives exist and why the patron's choice is or isn't the right one for this situation. The final ten to fifteen minutes are drafting the response: what the patron got right, what they may not have considered, what the creator would do differently and why.

The cap rationale: time math, not demand management

The Code Review tier is capped because the cap is determined by what leaves enough time per review to do it well, not by how many patrons want the tier. The time math is explicit: at fifteen reviews per month at forty-five minutes average, the creator commits approximately eleven hours of focused evaluation work monthly. That is a realistic number — it is approximately two and a half hours per week, concentrated enough to do well without requiring daily scheduling. At twenty reviews per month, the math produces roughly fifteen hours — past the threshold where review quality degrades because the creator is rushing through submissions to meet the volume.

Pricing the tier at $35 to $50 per month reflects what is being delivered: expert architectural evaluation of the patron's specific code, not generic instruction. At those price points, a fifteen-patron cap generates $525 to $750 per month from the tier — a meaningful revenue contribution that is commensurate with the eleven hours of work it requires. If the demand for the tier exceeds the cap, the right response is a waiting list, not an expanded cap. The waiting list demonstrates demand; an expanded cap dilutes the quality that created the demand.

The cap also creates self-selection. A patron who pays $50 per month for a code review tier and does not submit for two months is not getting value from the tier. Patrons at a capped, priced tier are more likely to actually use the tier — which means the creator's review time is directed toward active learners rather than passive subscribers who signed up for the potential access.

Architecture decision records: the format in operational detail

Architecture decision records — ADRs — are the highest-value content a developer or open-source creator can produce for a Collaborator tier patron. They document not what was built but why each significant technical decision was made. A patron reading the repository can see what was decided. A patron reading the ADR can see the reasoning: the constraints, the alternatives, the evaluation criteria, and the conditions under which the decision would be revisited.

The six-component ADR format

Title. The title describes the decision, not the conclusion. "How we handle authentication" rather than "We chose JWT." The title describes the architectural domain being decided — the question being addressed — rather than the answer. This matters for archival purposes: a patron searching ADRs for how the creator approached a specific problem should be able to find the relevant record from its title without already knowing the conclusion. "We chose JWT" tells a searcher the outcome; "How we handle authentication" tells them the domain.

Status. Proposed, accepted, or superseded. A proposed ADR is one the creator is actively working through and has not finalized — publishing proposed ADRs is itself valuable patron content because it makes the reasoning process visible before the decision is locked. An accepted ADR is the current operative decision. A superseded ADR documents a decision that was made and later changed, with a link to the ADR that replaced it. The superseded status is not a failure — it is documentation of the project's evolution. A patron who reads a superseded ADR and the record that replaced it understands more about the system's development than a patron who only has access to the current state.

Context. The constraints, requirements, and forces that created this decision. Not "we needed authentication" — that is a requirement, not context. Context is the specific constraints that shaped the option space: the system is stateless by design because it runs across multiple regions without shared session storage; the team has existing operational expertise in Redis but not in key management infrastructure; the expected token lifetime is short (four hours) because the primary threat model is session theft, not token forgery; the API is consumed by both browser clients and server-to-server services. These constraints determine which options are viable and how to evaluate the ones that are. A patron reading only the decision sees a choice; a patron reading the context sees why the option space had the shape it did.

Decision. A brief statement of what was decided. Two to four sentences. The decision section does not need to be long because the context explains the constraints and the alternatives section explains why this option was preferred. The decision is the conclusion the ADR reached — not the argument for it.

Consequences. Three sub-elements: what becomes easier because of this decision, what becomes harder, and what new decisions this decision creates. The "what becomes harder" and "new decisions created" elements are what distinguish an honest ADR from a post-hoc rationalization. Every architectural decision makes some things harder — it closes options, creates dependencies, or requires downstream decisions about related systems. Documenting these consequences acknowledges that the decision is a tradeoff, not a correct answer. Patrons reading the consequences section learn to evaluate architectural decisions as tradeoffs rather than solutions — which is a more sophisticated way to think about architecture than most tutorial content teaches.

Alternatives considered. This is the section that makes ADRs valuable as patron content rather than merely as documentation. For each rejected option: what it offers, the specific reason it was rejected for this context, and — most importantly — what would have to be true for it to be the right choice.

The "what would have to be true" element is the most instructive component of the alternatives section. A patron reading "we rejected database session storage because it requires a round-trip for every authenticated request" has learned that the option exists and why it was rejected here. A patron reading "database session storage would be the right choice if revocation latency were a hard requirement — if we needed to guarantee that a revoked token stops working within seconds rather than waiting for expiry, database lookups would be necessary despite the round-trip cost" has learned the evaluation criterion that distinguishes contexts where the option is wrong from contexts where it is right. That is a generalizable engineering insight, not a specific implementation fact.

A patron who has read ten ADRs with fully documented alternatives sections has learned how the creator evaluates options across ten different decision domains. They have seen what evaluation criteria the creator reaches for, how they weigh competing concerns, what conditions change their conclusions. This is the content that makes a developer Patreon valuable for senior engineers who are not learning fundamentals but are studying how an experienced practitioner thinks — which is information the repository cannot communicate and tutorials do not produce.

Reversal conditions: making decisions feel like engineering, not ideology

The seventh element — reversal conditions — is optional but high-value. For each accepted decision, the creator states explicitly: under what circumstances would this decision be revisited? What would have to change — in the system, in the constraints, in the environment — for the current decision to become wrong?

This element converts the ADR from a record of a past decision into a forward-looking engineering document. A patron reading "we would revisit this if the service needed to support revocation with sub-second latency — that requirement doesn't exist today, but if it emerges, the token storage approach would need to change" understands that the current decision is conditional on the current constraints. The decision is not doctrine — it is the right answer to this question given these constraints. When the constraints change, the answer changes. Documenting this explicitly models how mature engineers think about their own past decisions: as rational responses to conditions that may change, not as commitments to maintain regardless of new evidence.

For patron content, reversal conditions have an additional value: they generate forward-looking discussion. When a patron reads a reversal condition and recognizes that one of the trigger conditions is approaching — the user base is growing toward the scale where the decision trades off poorly, or a new requirement has emerged that resembles the stated trigger — they can bring this to the Advisor tier session or the Discord and ask whether the reversal is near. This makes ADRs living documents rather than historical records, and it makes the creator's reasoning visible in the present rather than only about the past.

Tech reviewer evaluation framework documentation versus verdict delivery

Tech review Patreons fail when they treat the exclusive content as "more review." A patron who wants an extended version of the published review — more benchmarks, more comparison data, a longer take on the product's weaknesses — is a patron who will churn when they have consumed the extended content. They subscribed for more of what they could have gotten for free, which means the subscription competes with the free tier. As the free content improves and the creator's audience grows, the value proposition of "more of the same" weakens.

The tech reviewer whose Patreon retains long-term is not the one who delivers more verdicts. It is the one who documents the methodology behind the verdicts — who teaches patrons not what to think about a product but how to evaluate it. This distinction determines whether the patron needs the creator for each new product (verdict delivery) or whether each new framework document expands the patron's capacity to evaluate products the creator has never reviewed (methodology documentation).

What a framework document contains

Take laptop thermal management as an example. A verdict-delivery post about a specific laptop's thermal management says: "Under sustained load, this laptop throttles to 2.8 GHz after twelve minutes, dropping single-core performance by approximately 18%. The fan noise at that workload is acceptable for a home office environment but intrusive in a quiet public space."

A framework document on laptop thermal management says something different: "Sustained performance means maintaining at least 85% of peak single-core performance for a minimum of thirty minutes under a continuous compile workload — not peak performance, not average performance, not performance in a synthetic benchmark that alternates load and rest. The benchmark I use is a full clean build of a specific open-source project that I maintain consistently across test cycles. Temperature thresholds: above 95°C package temperature is actual thermal throttling; between 85°C and 95°C is the thermal management zone where the chip may begin reducing frequency preemptively depending on the OEM's power management settings. Below 85°C sustained, performance is constrained by other factors. For acoustic profile: at the 30-minute mark of the sustained workload, I note fan RPM and the subjective acoustic signature at 30cm distance from the display. A hum is acceptable at any workload. A whine is acceptable at sustained load in a personal workspace. A whine at idle is a manufacturing defect, not a design characteristic."

The framework document defines "sustained performance" in specific measurable terms, names the benchmark and why it was chosen, establishes temperature thresholds with their distinct meanings, and articulates an acoustic standard that distinguishes workload-appropriate noise from noise that signals a problem. A patron who has read this document can now evaluate the thermal management of a laptop the reviewer has never touched — they have a methodology, not just a conclusion.

Why framework patrons don't need the creator for individual verdicts

This is the structural difference between a verdict-delivery Patreon and a methodology-documentation Patreon: the patron relationship in a verdict-delivery model ends when the patron no longer needs a specific verdict. If the creator reviews fourteen laptops and the patron buys one, they cancel — they have what they came for. If a new laptop emerges that the creator hasn't reviewed, the patron waits for the review or finds another source.

In a methodology-documentation model, each framework document a patron receives expands their capacity to evaluate independently. After reading five framework documents — laptop thermal management, audio DAC quality, display color accuracy, build quality and hinge durability, software bloatware and battery impact — the patron can sit down with a laptop they found at a retailer and conduct their own evaluation. They are not waiting for the creator's verdict. They have internalized the creator's methodology.

The patron relationship in this model does not end when the patron doesn't need a specific verdict — because the patron never needs the creator for a specific verdict. They need the creator because each new framework document expands their evaluative capacity. The relationship deepens with each post rather than concluding with each purchase decision. This is the highest-value patron relationship in review content, and it is only available to creators who document methodology rather than deliver verdicts.

Framework documentation for software and developer tooling

For tech reviewers who cover developer tooling — IDEs, CI/CD platforms, observability tools, API design tools, database management interfaces — the framework document has additional dimensions that hardware reviews don't require. Evaluating whether a CI/CD platform is good for a specific team requires a framework that addresses: what the performance measurement captures (build time at what scale? Queue latency at what concurrency?), what the developer experience criteria are and how to assess them, what the total cost of ownership calculation should include beyond the subscription price, and what "works for teams of N" actually means in behavioral terms rather than marketing terms.

A software tooling evaluation framework that answers these questions is the type of patron content that gets saved, shared internally at companies, and returned to at every evaluation cycle. It is reference material with a lifespan of eighteen to thirty-six months — much longer than a hardware review framework, which depreciates as product generations change the benchmark landscape. Developer tooling evaluation frameworks retain relevance because the criteria for evaluating these tools are more stable than the hardware specifications they capture. What "good" CI/CD performance looks like at a 50-developer team changes less year-over-year than what thermal management benchmarks apply to the current chip generation.

iOS rates and the Apple Tax for technology creators

Technology content creators have among the lowest iOS subscriber rates of any YouTube category. The reason is structural: developer and programmer audiences use computers as their primary work devices. Tutorial content is reference material — it is watched on a second monitor while the development environment is active on the primary display. A phone is not a practical viewing device for a coding tutorial because the code is not legible at phone scale and the workflow requires switching between the video and the IDE. The audience that cannot efficiently consume the content on a phone does not subscribe to the Patreon through a phone.

iOS rates by technology content subtype:

• Coding tutorial YouTube: 25–40% iOS. The lowest iOS rate of any educational category. Desktop-primary by use-case requirement: coding tutorial content is reference material, not passive entertainment. Patrons are watching alongside a development environment. The demographic is developers and developers-in-training, who are desktop-primary by profession.
• Tech review YouTube: 45–55% iOS. More casually consumed than tutorial content — tech enthusiast content is watched during commutes and leisure rather than alongside active work. The tech-enthusiast demographic includes younger audiences with more mobile-mixed consumption patterns alongside the professional developer demographic.
• Developer and open-source YouTube: 30–45% iOS. Architecture and development documentation content is reference material for developers, viewed on the device where work happens. Closer to coding tutorial iOS rates than entertainment rates because the use case is equivalent.
• Tech podcasts: 55–65% iOS. Podcast consumption is overwhelmingly mobile across all genres. Tech podcasts are mobile-heavy despite the same demographic as tech YouTube — the content format, not the audience, drives the platform shift.

The Apple Tax math for representative technology creators:

The tech podcast result illustrates an important point: a tech podcast with $800/month and 60% iOS pays the same dollar amount in Apple fees as a tech review channel with $1,200/month and 40% iOS. The lower income, higher iOS rate combination can produce the same or worse dollar impact than a higher income, lower iOS rate combination. Knowing your specific iOS rate matters more than knowing your category average.

What to do before October 31, 2026

Enable Patreon's web-only billing toggle before October 31, 2026. This is the mechanism that prevents new iOS subscriptions from being processed through Apple — it does not retroactively switch existing iOS-billed patrons, but it stops the exposure from growing after the toggle is enabled.

For existing iOS-billed patrons, the creator must communicate the switch. Patreon does not notify iOS-billed patrons that a web billing option exists or that it avoids the Apple fee. The communication that works is specific and patron-facing: the exact dollar amount the patron saves by switching billing to the web, and the two steps to make the switch (go to Patreon.com in a browser, navigate to manage membership, switch payment method). Technology audiences respond to this communication well — they are accustomed to billing preference management and understand platform fee structures. A creator who explains "Patreon is applying a 30% Apple fee to iOS subscriptions starting November 1; if you subscribed through the iOS app, switching to web billing takes two minutes and costs Apple nothing — here is how" is not asking for a favor. They are giving their audience information that saves patrons money.

Update all Patreon CTAs in YouTube video descriptions to the direct web URL rather than "subscribe on Patreon." A link that says "patreon.com/yourchannel" opens in the browser on desktop and generates web-billed subscriptions. The same link opened in the Patreon mobile app on iOS generates iOS-billed subscriptions. The format of the CTA link determines which billing path new patrons enter. Creators who use the video description CTA to drive Patreon traffic should audit their pinned videos and their most recent twenty videos to ensure the link format generates web billing rather than app billing.

Tech podcasters who produce both YouTube video content and a podcast feed face a compound exposure. The YouTube audience is 30–45% iOS; the podcast audience is 55–65% iOS. If the podcast is the larger audience, the effective blended iOS rate for the Patreon may be higher than the YouTube rate alone suggests. Podcast show notes should include a direct web URL for Patreon subscriptions, and an episode mention — "subscribe at [URL] on the web rather than through the Patreon app; web billing avoids the Apple fee that applies starting November" — is worth adding to one or two episodes before the October deadline.

FAQ

What should technology creators offer at each Patreon tier?

Tier structure depends on creator type. Coding tutorial creators use three tiers: Learner ($5–8/month, early video access, patron-only setup and configuration notes, Discord organized by language and framework), Developer ($12–18/month, annotated source files, debugging sequences the creator edited out of the polished tutorial, monthly tech stack posts), and Code Review ($35–50/month, capped 10–15, monthly review of patron-submitted code using the structured submission protocol). Tech review creators: Subscriber ($5–8/month, early access and Discord), Analyst ($12–18/month, evaluation framework documentation per product category, first-look posts on product arrival), Advisory ($35–50/month capped 15–20, monthly tech Q&A). Developer and open-source creators: Observer ($5–8/month, development logs and architecture overview posts), Collaborator ($12–18/month, architecture decision records with alternatives and reversal conditions), Advisor ($35–50/month capped 10–15, monthly group architecture review session where the creator's reasoning is visible in real time).

What should a debugging sequence Patreon post contain?

A debugging sequence post should document six specific elements: (1) the actual error and why it is confusing — not just what the message says, but why it misdirects a first-time reader; (2) the creator's first hypothesis and the evidence that made it seem plausible; (3) the specific diagnostic steps taken to test the hypothesis — which docs, which values were logged, what was checked; (4) why the hypothesis was wrong — the specific observation that eliminated it; (5) what observation pointed to the correct fix; (6) why the fix works at the mechanism level, not just syntactically. A patron who watches five debugging sequences from the same creator learns that developer's diagnostic process — what they reach for first, how they read error messages, how they reason about unfamiliar systems. These transferable heuristics cannot be acquired from clean walkthroughs, which is what makes debugging sequences the highest-retention exclusive a coding tutorial Patreon can offer.

What is the architecture decision record format for a Patreon Collaborator tier?

An ADR has six core components and an optional seventh. Title: describes the decision, not the conclusion ("How we handle authentication" not "We chose JWT"). Status: proposed, accepted, or superseded. Context: the specific constraints and forces that created this decision — not what was needed but what constrained the option space. Decision: a brief statement of what was decided. Consequences: what becomes easier, what becomes harder, what new decisions this creates. Alternatives considered: for each rejected option, what it offers, the specific reason it was rejected here, and what would have to be true for it to be the right choice — this last element is what makes the section instructive rather than merely comprehensive. Optional seventh: reversal conditions — under what circumstances would this decision be revisited. The alternatives section is what separates an ADR from a decision log: a patron reading only the decision sees the output of reasoning; a patron reading the alternatives section sees the reasoning itself.

How does the Code Review tier submission protocol work?

The submission protocol requires three things beyond the code: (a) what the patron is building in one to two sentences; (b) the specific decision they made that they are uncertain about — not "review my code" but "I chose X over Y because of Z, and I'm not sure if this creates problems I haven't anticipated"; (c) what they want to know. With this protocol, a focused, useful review takes 30 to 45 minutes. Without it, the creator spends the first 20 minutes orienting. The tier cap follows from the time math: at 15 reviews × 45 minutes, that is approximately 11 hours of review work monthly — enough to do each one well. The cap is set by what preserves review quality, not by demand. A waiting list handles overflow demand without diluting quality.

How does the Apple Tax affect technology creator Patreons?

Technology content creators have among the lowest iOS rates of any YouTube category. Coding tutorial YouTube: 25–40% iOS (tutorial content is desktop reference material; you cannot code on a phone). Tech review YouTube: 45–55% iOS (more casually consumed across devices). Developer and open-source YouTube: 30–45% iOS (developer audiences are desktop-primary by profession). Tech podcasts: 55–65% iOS (podcast listening skews mobile regardless of audience demographics). At 35% iOS and $500/month gross: Apple's fee is approximately $52.50/month ($630/year). At 40% iOS and $1,200/month: approximately $144/month ($1,728/year). Enable web-only Patreon billing before October 31, 2026. Update all YouTube description Patreon CTAs to direct web URLs. Tech podcasters should add a verbal subscription mention in episode audio directing listeners to the web URL specifically.

Filed under: technology creators on Patreon · educators on Patreon · the Apple Tax explained · all explainers