On 2026-07-02, I shipped three small JERICCO digital products: one free file and two paid starter products. The stack was intentionally plain. Each product had a public preview page, a PDF, and a ZIP. The products were listed through a live catalog, not a custom app, membership portal, or complicated checkout flow.
That made this a useful MVP pattern: publish useful files, package them clearly, expose enough of the product to understand it, and keep the rest of the system easy to inspect.
The live catalog for the batch was here: https://heishk.github.io/ophelia-reset-systems/
A separate example of a focused product page, outside this catalog, is Cold Client OS. The useful comparison is not the subject matter. It is the idea that a small product needs a clear promise, a clear artifact, and a clear path for the reader to understand what they get.
What shipped
The July 2 batch had three products:
- Tiny Product Idea Validator was free. It was a one-page worksheet for deciding if a digital product idea is worth making today.
- Subscription Leak Finder Mini Kit was priced at $5. It was a printable mini kit for finding recurring charges, downgrades, and forgotten subscriptions.
- Micro Product Launch Board was priced at $7. It was a compact launch planner for shipping a small digital product without a full project management system.
The source log listed preview, PDF, and ZIP links for all three. That matters because the MVP was not just a paragraph saying a product existed. It included files that could be opened, downloaded, and checked.
Why plain files worked for this stage
A file-based MVP is boring in the right way. The product can be tested without building accounts, permissions, dashboards, onboarding screens, or database tables.
The format in the source log had three simple pieces:
- A preview page so someone could understand the product before downloading or buying.
- A PDF because printable worksheets are easy to open, save, and trust.
- A ZIP bundle because a bundle can carry the source, README, listing copy, and promo copy around the finished file.
That structure also made the work easier to debug. If a preview page was wrong, it could be fixed as a page problem. If the PDF was wrong, it could be regenerated. If the ZIP was incomplete, the bundle could be replaced. The moving parts were visible.
The basic QA pass
The minimum QA for this kind of build is not glamorous, but it is necessary:
- Open every preview page.
- Download every PDF.
- Download every ZIP.
- Confirm the free product is clearly marked as free.
- Confirm paid products are clearly marked with their prices.
- Check that the product name in the page, PDF, and ZIP match.
- Check that the ZIP contains the intended supporting files.
- Check that the catalog points to the correct daily batch.
The source log supports a link-level QA pass because it listed the preview, PDF, and ZIP assets for each product. It does not prove deeper QA, such as customer testing, conversion tracking, or long-term maintenance.
Practical checklist
Use this pattern when the product is small enough to exist as a file:
- Define one narrow job for the file.
- Write the product title before building the asset.
- Make the preview page explain the use case, not just the file name.
- Export the final PDF.
- Package a ZIP with the PDF plus source or support materials.
- Keep product names consistent across the page, file, and catalog.
- Publish the free item first if it helps people start.
- Treat the paid items as demand tests, not proof of demand.
- Keep a dated folder or release path so the batch can be found later.
Mistakes to avoid
The first mistake is treating a file product like a software platform. A worksheet does not need auth, roles, billing events, and a custom admin panel on day one.
The second mistake is skipping the preview. A public preview page helps the product feel inspectable. It also makes it easier to share the artifact without attaching files everywhere.
The third mistake is calling a price a result. A $5 or $7 listing is only a listed price. It is not revenue, sales, or buyer validation unless the build log includes that evidence.
FAQ
Was this a SaaS build?
No. The useful part of the July 2 log is that the MVP avoided a complex stack. It shipped as pages, PDFs, and ZIPs.
Were the products proven by sales?
The source log does not include sales, downloads, revenue, traffic, or customer counts.
Why include ZIPs if there is already a PDF?
The source log says ZIP bundles let the creator include the source, README, listings, and promo copy.
What would make the next version stronger?
A stronger release would add a manifest, file hashes, clearer version labels, and a repeatable rollback path. Those are next-system improvements, not claims made by the July 2 source log.
Educational note: no results claim
This is a build-structure article, not a success story. The truthful claim is narrow: three small products were shipped as preview pages, PDFs, and ZIPs through a public catalog on 2026-07-02. Anything about sales, downloads, traffic, or customers would need separate evidence.
Top comments (0)