paywall-gallery: 1410 paywalls as Markdown files, and two different revenue figures for the same app

The same app carries two monthly revenue figures in one document

The data format example and the featured table disagree about the same company. The example frontmatter block is for YouTube and reads:

---
app_name: "YouTube"
app_id: 544007664
developer: "Google"
category: "Photo & Video"
paywall_type: "Free Trial - Soft Paywall"
pricing_model: "2 offer sets across month"
mrr: "$55.84M"
rating: 4.68
versions_count: 1
offers:
  - period: "month"
    prices: ["$18.99", "$18.99/$29.99"]
onboarding_count: 1
walkthrough_count: 0
app_detail_url: "https://www.paywallpro.app/apps/YouTube-us?id=PAYWALLPRO_INFO_ID"
---

The featured table further down lists YouTube with an estimated monthly revenue of just over three million, and the column header there says estimated while the frontmatter field does not. Both figures appear in the same readme, with no note reconciling them. There is a plausible innocent explanation, such as one number covering all revenue and the other covering subscriptions only, but the document does not say so, and a reader copying the frontmatter schema has no way to know which definition they are getting. For a dataset whose stated purpose includes analysing revenue signals, that is the field you would most want to be unambiguous about.

The example entry ships a literal placeholder where an identifier should be

The frontmatter example includes a link field whose value ends in an identifier placeholder rather than an actual value, so anyone copying the schema produces a link that does not resolve. It is a small thing and it is the kind of detail that survives because the schema is correct everywhere else. The rest of the example is well built and worth reading as a specification: an app name, a numeric app identifier, the developer, a category, a paywall type, a pricing model described in words, the revenue figure, a rating, a version count, a nested offers list pairing a billing period with an array of prices, counts of onboarding and walkthrough screens, and the link back to the product. Field definitions live in a separate data dictionary document in a docs directory. The file naming convention is a lowercased app name plus the identifier, which is what the featured table's links use as well.

Every visible row of the featured table carries the same paywall pattern

The featured table shows twenty apps, and the pattern column is almost entirely one value. Rows read as no free trial with a soft paywall, or free trial with a soft paywall, with one row carrying both labels joined by a comma. Not one visible row names a hard paywall, a pre-paywall survey or any other pattern, which is an odd thing for a gallery whose stated purpose includes showing how patterns differ by category. The comma-joined row also reveals the shape of the field: it is a free-text list rather than a controlled vocabulary, so a pattern cannot be counted reliably without parsing, and two labels separated by a comma in one cell means the same app can be two patterns with no way to say which is primary. If your use case is comparing patterns across apps, this column will not support it without cleaning.

The revenue signals are listed as the thing you pay for

The readme is unusually explicit about the boundary between the free dataset and the product, and it is worth reading as a pricing page in reverse. What the repository includes: representative screenshots, onboarding previews where available, compact app pages, pricing model summaries, pattern classification, selected public-facing monetization signals, category indexes, and links onward. What the full product includes: full screenshot sets, complete onboarding flows, every historical version, version-by-version changes, before and after comparisons, historical pricing experiments, split-test reference material, revenue and ranking signals, and advanced filters by category, region, pricing model and app type. Note the phrase selected public-facing in the first list. The historical dimension is the one the public set drops almost entirely, which is the part a competitive analyst actually wants.

Fifty apps a week is the growth promise, and there is no snapshot mechanism

The dataset states a current public release of 1410 apps and a plan to keep adding fifty new apps every week, and the readme asks readers to star the repository for weekly updates. Fifty a week is roughly two thousand six hundred a year against a base of fourteen hundred, so the corpus roughly triples in eighteen months if the cadence holds. That is fine for browsing and awkward for analysis: nothing in the visible text offers a dated release, a manifest of which apps were present when, or any way to pin a version, and the repository has no releases at all. If you are going to use these files as a reference set, take a copy and record the date, because the index you cite today will not be the index that exists in three months. The request mechanism is a separate matter and is handled through an issue form rather than a queue in the repository.

Two contributing documents, two request documents, all in two languages

The repository root holds a contributing guide in English and in Chinese, and a separate requests document in both languages, alongside two readmes in both languages. The requests file at the root is the unusual part, since the readme's own path for asking for an app to be added points at an issue form rather than at that file, so a newcomer finds two ways to make a request and no statement of which one is read. The bilingual approach is genuinely thorough for a dataset aimed at an international developer audience, and it extends beyond the readme into the contributing and request documents, which is more than most open datasets manage. The root also carries assets, categories, data and documentation directories alongside the apps directory, which is the shape you would expect from a generated dataset rather than a hand-maintained one, and there is no visible script that generates it.

Two rule lines in a row, and no method behind the estimates

The readme has a small formatting artefact: two horizontal rules appear one after the other with nothing between them, which suggests a section was removed or a template was assembled in pieces. Minor, but it is the kind of thing that tells you the document is edited by hand around generated sections. The larger gap is methodological. The featured table column is labelled as estimated monthly revenue, and the product description claims to track monthly recurring revenue, revenue per download, average revenue per user and subscription benchmarks. No part of the visible text says how any of these are estimated, from what source, with what error, or refreshed how often. For a dataset whose selling point is that it replaces guesswork with real numbers, the numbers are the part that would need a methodology note, and it is the part that is missing.

Editorial conclusion

Use it as a reference set and not as a benchmark, because that is the difference between what it publishes and what it sells. The public files are a curated preview: one app page each, with structured frontmatter you can parse and a screenshot, and the historical versions, complete flows, split-test references and the revenue signal series sit behind the paid product. For design research that is genuinely useful, since 1410 real paywalls with frontmatter beats a folder of inspiration screenshots. Three cautions before you build on it. The revenue figures are labelled as estimates and no method is given, and the document contradicts itself on one app, so treat the number as a hint about relative scale rather than a fact. The pattern field is a free-text list rather than a controlled vocabulary, so any counting you do over it will be approximate. And the growth promise is a weekly cadence of fifty new apps, which means the dataset is a moving target and your snapshot needs dating.

Frequently asked questions

Official sources

1. Issues
2. paywallpro/paywall-gallery on GitHub
3. Project website
4. README