1. Why "Paid Experience"
In the software world, free trials are standard. Fourteen days, thirty days, feature-limited. Users try casually and leave if it does not fit. TokiQR's encoder is the same—anyone can create voice QR codes in a browser. Free, with no limitations.
But the essential experience of TokiQR lies in multi-QR. With a free single QR, you can only record what fits on one code. Purchase credits, and that constraint is lifted. Record long audio without sacrificing quality, split it across multiple QR codes—without going through that experience, you never touch the core of the product.
Free trial feedback is an impression of "trying it out." Paid experience feedback is a fact of "having used it."
The monitor program was designed to obtain this "having used it" feedback. Monitors purchase credits through the same flow as regular customers, use every feature of TokiQR, and then provide feedback.
For monitor participants, taking on financial risk for a paid product upfront is a psychological barrier. Wanting to try for free before deciding, or wanting a refund if dissatisfied—these are natural reactions. In the monitor program, participants go through the real payment flow, but the same amount is returned via Wise. The experience is effectively free, allowing monitors to focus purely on the product without financial anxiety.
This structure echoes the principles of a gift economy. In a conventional market transaction, you pay and receive a service in return. In the monitor program, money circulates back, and the real exchange occurs between “experience” and “feedback.” Monitors experience the product and return its value as public comments. TokiStorage receives trust signals and insights for improvement. Voluntary reciprocity, not obligation—that is what underlies this program.
Similar models exist. Mystery shoppers go through the real purchase flow, are fully reimbursed, and submit reports. Structurally, this is the closest parallel. However, their feedback remains private, confined to internal documents. Product testing programs like Amazon Vine involve public reviews, but products are provided for free—no purchase flow is involved. The impression of “having tried it” and the fact of “having bought it” are fundamentally different. Cashback programs return a portion of the purchase price, but they are marketing tactics, not feedback mechanisms.
The TokiQR monitor program recombines these elements. Participants go through the real purchase flow, the full amount is returned, and feedback is published linked to a Wisetag—the account name used for payment. Unlike anonymous reviews, a third party can verify that “this person actually purchased.” Furthermore, content created by monitors remains in their hands. If they like the product, they simply keep using it—there is no “free to paid” conversion step.
There is a common pattern when startups begin building a product. Founders reach out to a limited circle of acquaintances, offering it for free or making individual accommodations to gather feedback. It is a goodwill-dependent, ad-hoc approach. By designing a monitor program in advance, participation is not limited to personal connections. With conditions and flows explicitly defined, anyone can join as a monitor on equal terms. The requirements are creating a Wise account, installing the PWA, and publishing feedback—all explicitly stated on the page. Meet the conditions, and it is open to anyone. Wise can be set up by any individual today. Funding is equally straightforward—debit cards, bank transfers, Apple Pay, and more are supported. In Japan, smartphone household penetration exceeds 90%, reaching 94% among people in their 60s and 84% among those in their 70s (2025, NTT DOCOMO Mobile Society Research Institute). Globally, roughly 90% of the world’s population owns a smartphone. The condition of “having a smartphone” is, in practice, already met by the vast majority of people. This means you can invite anyone to become a monitor: family, relatives, neighbors, acquaintances, anyone you meet.
2. Quests as Experience Design
When monitors open the monitor page, five quests appear. "Record audio and create a QR code." "Print it and scan it." "Purchase 100 multi-QR credits." "Generate multiple pages in bulk mode." Each quest corresponds to a core feature of TokiQR.
The quest format was adopted because an open-ended "try anything you like" approach produces scattered feedback. "What should I try?" "How far should I go?"—such uncertainty ultimately degrades feedback quality. Quests make explicit what monitors should experience and define completion conditions.
Riding the Existing Purchase Flow
The credit purchase quest requires no monitor-specific payment logic. Monitors select 100 credits through the same credit.html flow as any regular customer and pay via Wise. The moment the credits are activated, the quest completion condition is met. No amount matching or payment purpose identification is needed. The existing credit activation event serves directly as the achievement signal.
The monitor’s experience becomes an asset for TokiStorage as well. We gain feedback on the usability of featured newsletters and create connections with people who may recommend the service. Content created by monitors is included in newsletters and accumulated as archives. There is no additional burden on the monitor—deliverables created with purchased credits remain in their hands, and if they like the service, they can simply continue using it.
Building a monitor-specific payment flow would create divergence from the standard flow. If "buying as a monitor" and "buying normally" are different experiences, the feedback loses value. By going through the same flow, monitors have an experience identical to that of actual customers.
Not Gamification
The name "quest" sounds game-like, but the purpose is not gamification. There are no points, badges, or rankings. A quest is simply a guide saying "please try things in this order"—the shortest path to comprehensively experiencing the product's features. By having the provider take responsibility for experience design, the monitor's burden is minimized.
3. Wisetag as Public Identity
Monitors register a Wisetag when they apply. A Wisetag is a Wise (international money transfer service) account name. Since TokiStorage payments are processed through Wise, a Wisetag inherently proves that "this person actually paid."
Feedback is published publicly, linked to the Wisetag. It is not an anonymous review. It is verifiable feedback tied to a payment account. This functions as a trust signal. "This voice belongs to someone who actually purchased"—a third party can confirm this.
Anonymous reviews compete on volume. Wisetag reviews compete on verifiability.
4. Feedback Inscribed on GitHub
Monitor feedback is stored not in a database but as JSON files in a GitHub repository. One JSON file per year—monitor/voices/2026.json—is created, and new feedback is prepended to the top.
Why JSON instead of a database? TokiQR is a PWA (Progressive Web App) with no backend server. It is a static site served from GitHub Pages. Using a database would require server operations, authentication, backups, and scaling. With JSON files, a simple browser fetch is all that is needed.
Exclusive Locking and Commits
Feedback writing is handled by Google Apps Script. It acquires an exclusive lock via LockService, reads the year file through the GitHub API, prepends the new entry, and commits directly to the main branch. Not a branch-and-pull-request approach, but a direct commit under exclusive lock.
This design decision eliminates the risk of auto-merge conflicts. If two monitors submit feedback nearly simultaneously, the pull request approach could produce file conflicts. LockService serializes concurrent execution, and direct commits to the GitHub API eliminate conflicts by design.
5. Archive Rotation
What happens when a year file exceeds 1,000 entries? The answer is to retire the excess into numbered files.
The threshold is 1,000 entries; the retirement size is 500. When a year file exceeds 1,000 entries, the trailing 500 (the oldest entries) are extracted into 2026-001.json. The next time it overflows, 2026-002.json is created. The year file always holds only the most recent 500 to 1,000 entries.
The client side handles this with pagination. Click a year and the active year file is displayed first. If archived files exist, a page navigator appears, allowing users to browse older feedback.
To prevent file bloat from breaking the system a thousand years from now, the retirement logic is built in from the start. Retrofitting is far harder.
6. Newsletter-Style Navigation
The feedback browsing interface adopts the same century-volume-year navigation structure as TokiQR's newsletter. A simple year list suffices at first, but after ten or a hundred years, that list becomes unwieldy. Century-level collapsing, twenty-year volumes—this hierarchy provides a path to feedback from any era.
The default view shows the ten most recent entries. Click a year to see all feedback for that year. It might look like over-engineering, but changing the navigation structure later would affect existing URLs and display logic. Design for a thousand years from the start, and after that, entries simply accumulate.
7. The Trust Design Pattern
The monitor program builds trust through three layers.
- Experience layer: Going through the paid purchase flow guarantees the foundation of feedback
- Public layer: Wisetag-linked public voices provide verifiability that anonymous reviews lack
- Persistence layer: GitHub static JSON eliminates the risk of data loss from database failures or service shutdown
Every layer stands on existing infrastructure—Wise, GitHub, the browser. No authentication server or user management system exists specifically for the monitor program. Designing trust through combinations of standard technology, without adding external dependencies. TokiStorage's consistent design philosophy manifests here as well.
Paid experience, public Wisetag, GitHub persistence.
Three layers of trust turn a monitor's voice into the product's foundation.
For Wise as a payment method, see "Payment Methods." For the persistence design of storage, see "Storage Strategy." For the policy of not adding external dependencies, see "No More External Dependencies."