On 2026-07-04, I shipped three more small JERICCO digital products. The structure stayed simple: one free file, two paid starter products, public preview pages, and a live catalog tying the batch together.
This build is best read as a catalog-design exercise. The products were not isolated files thrown onto the internet. They sat inside a repeatable pattern: daily product path, preview page, PDF-first asset, ZIP-oriented packaging logic, and a public catalog that could help someone navigate the collection.
The live catalog was here: https://heishk.github.io/ophelia-reset-systems/
For a contextual comparison, Cold Client OS is another example of a product surface where the page has to do navigation work: explain the product, reduce ambiguity, and point the reader toward the next action. A catalog has to do that across multiple products at once.
What shipped
The July 4 batch included:
- Tiny Social Proof Collector Kit priced at $7. It was a printable PDF kit for collecting honest buyer quotes, screenshots, and launch notes without making the ask awkward.
- Notion Template Seller Launch Map priced at $9. It was a PDF-first launch map for packaging, previewing, and selling a Notion-style template without losing the buyer in setup steps.
- Creator Content Calendar Swipe Sheet marked free. It was a one-page PDF for turning one small digital product into a week of useful posts.
The source log listed preview pages for all three. The two paid products were marked as preview only, with protected checkout delivery pending Stripe setup. The free product had a public PDF link.
The catalog job
A small catalog has a different job from a single landing page. A landing page sells or explains one thing. A catalog helps people compare, navigate, and understand the relationship between products.
For this batch, the catalog needed to answer basic questions quickly:
- What is the product called?
- Is it free or paid?
- What problem does it solve?
- Is there a preview?
- Is the file public or protected?
- How does this product relate to the rest of the batch?
The July 4 source log used the same batch format as the prior days. That consistency is what makes a small catalog maintainable. Product pages can vary in topic, but the navigation pattern should not be reinvented every time.
Packaging reusable files
Reusable file products benefit from predictable packaging. The source log says PDFs are easier for buyers to trust and print, and ZIP bundles let the creator include the source, README, listings, and promo copy.
That is a useful division of labor:
- The PDF is the finished artifact.
- The ZIP is the portable package.
- The README explains how to use what is inside.
- The listing copy helps the product be published elsewhere.
- The promo copy helps the product be announced without rewriting from zero.
Even when a paid PDF is not publicly delivered yet, the catalog can still maintain the product record: title, price, preview state, and delivery status.
Navigation and maintenance
The maintenance problem appears as soon as there is more than one batch. July 2, July 3, and July 4 each had three products. That is already nine product records.
A catalog should make that manageable by keeping a consistent product card or page structure. The fields should stay stable even when the product topic changes:
- product name
- short description
- batch date
- price state
- preview link
- file or protected-delivery status
- package type
- maintenance notes
The catalog should also avoid hiding important limitations. If Stripe setup is pending, say that. If a public page is preview only, say that. If a free PDF is available, make that clear.
Practical checklist
For a small reusable-file catalog:
- Use the same fields for every product.
- Separate previews from protected delivery.
- Mark free products clearly.
- Keep paid products from looking downloadable if checkout is pending.
- Use dates to make batches easy to trace.
- Keep packaging rules consistent across products.
- Store source, README, listing, and promo materials together when using ZIPs.
- Link the catalog to product pages, not random file names.
- Review old catalog entries after each new batch.
Mistakes to avoid
The first mistake is letting the catalog become a dumping ground. A catalog is not just a list of links. It is a navigation system.
The second mistake is mixing product states. A paid preview page, a free PDF, and a protected checkout note should not look identical.
The third mistake is over-claiming the catalog. A public catalog proves organization and availability of pages. It does not prove audience demand, sales, downloads, or customer outcomes.
FAQ
Was every July 4 product directly downloadable?
No. The source log listed a public PDF for the free Creator Content Calendar Swipe Sheet. The two paid products were marked preview only, with protected checkout delivery pending Stripe setup.
Why keep using PDFs?
The source log says PDFs are easier for buyers to trust and print.
Why use ZIP bundles?
The source log says ZIP bundles can include the source, README, listings, and promo copy.
What are the next useful tests?
Useful next tests would be link checks, package checks, catalog navigation checks, and traffic-signal review before deciding which product becomes a larger bundle. The source log mentions using traffic signals for that decision, but it does not provide the signals.
Educational note: no results claim
This article is about catalog structure and file packaging. The source supports the shipped batch, product names, prices, preview states, free PDF availability, and the stated next intention to use traffic signals. It does not support claims about sales, revenue, downloads, customers, or marketplace performance.
Top comments (0)