RE:CZ

CZON Product Optimization and CZONE Vision Analysis

Product Development

👤 Product developers, tech enthusiasts, readers interested in content creation tools and Web3 applications
This article documents the author's optimization work on the CZON product on January 28, 2026, including adding HTTP Proxy support for GB users to resolve OpenAI API call issues. The author reflects that CZON's closed-loop process is somewhat rigid and considers using GitHub Actions to achieve automated operation to lower the user barrier. Meanwhile, the article details the comparison with CZONE's vision—a completely barrier-free content creation platform where users only need GitHub login to create, edit, and publish content, with data based on Markdown and Git, aligning with the Web3 spirit. The author plans to continue testing CZON's implementation and debates whether to further optimize it to balance usability and technical complexity.
  • ✨ Added HTTP Proxy support to CZON to resolve user issues with calling the OpenAI API
  • ✨ CZON already has two early users, and the author plans to test the product's implementation
  • ✨ Considering using GitHub Actions to achieve automated closed-loop for CZON to lower the usage barrier
  • ✨ CZONE is positioned as a completely barrier-free content creation platform, based on GitHub OAuth login
  • ✨ CZONE data is based on Markdown and Git, allowing users to export autonomously, aligning with the Web3 spirit
📅 2026-01-28 · 377 words · ~2 min read
  • CZON
  • CZONE
  • HTTP Proxy
  • GitHub Actions
  • Product Optimization
  • User Experience
  • Web3
  • Content Creation

It is Wednesday, January 28, 2026, evening.

Yesterday, I pitched CZON to GB, who expressed interest. However, he encountered an issue with needing an HTTP Proxy to call the OpenAI API, but CZON previously did not support HTTP Proxy. So today, I spent some time adding HTTP Proxy support to CZON. I am now waiting for further feedback from GB.

GB is the second CZON user after C1. I plan to test the implementation of CZON. At this stage, it’s important not to rush; we must proceed steadily and focus on delivering a good experience for early users. Once we have a solid user base, we can consider large-scale promotion.

Currently, the workflow of CZON is still a bit rigid. I am considering fully implementing CZON’s workflow using GitHub Actions. That is, after users submit content source files to the main branch, GitHub Actions will automatically trigger CZON to run and then push the results directly back to the main branch (or create a PR). However, this requires configuring GitHub Secrets to store the OpenAI API Key and other credentials. This approach would eliminate the need for users to run CZON locally, lowering the barrier to entry. (Of course, this still doesn’t achieve the completely seamless experience of CZONE, so I’m debating whether to proceed with these optimizations.)

CZONE is positioned as a completely seamless product. Users only need to register a GitHub account, log in to CZONE via GitHub OAuth, and they can directly create content sites, write, and publish static sites—all without needing to navigate elsewhere. The mobile editing experience is as simple and straightforward as posting on social media or tweeting. The desktop editing experience is similar to using a WYSIWYG editor like Notion or Typora. Users can focus solely on content creation, while CZONE handles everything else. The advantage of CZONE is that it is built on Markdown and Git, ensuring users fully own their data. They can export their data at any time or migrate it to other platforms. This aligns with the spirit of Web3.

If GB were using CZONE instead of CZON today, he wouldn’t have to worry about HTTP Proxy issues at all.

I think I should also onboard a few more users to test the implementation of CZON.

See Also

Referenced By