“Future Silicon World Episode 16” Interview: tw93’s Open Source Story and Experience

One person, with a full-time job, a family, and a young daughter.

Yet in 13 years, relying on long holidays, early mornings, and a laptop by the swimming pool, he created six open source tools used by Silicon Valley CTOs, Pinterest, and YC founders.

This person’s X handle is HiTw93, and his GitHub ID is tw93.

https://x.com/HiTw93

https://github.com/tw93/

Six Products, Six “I Got Annoyed by It First” Stories

The origin of tw93’s first product, MiaoYan, was simple: he couldn’t find a Markdown editor he liked.

As a frontend engineer by trade, he hated heavyweight frameworks like Electron, so he decided to learn Swift and build one himself.

He learned by doing, and by the time he finished, he had mastered Swift and gotten a deep understanding of Apple’s underlying rendering performance.

For example, syntax highlighting for Markdown headings was implemented directly with regex, performing far better than web-rendered editors.

MiaoYan is now almost 6 years old.

Pake also came about by chance.

He has a habit of sharing the useful tools on his computer once a year.

That year, he liked using WeRead (a reading app), but it had no desktop client, so he packaged a UI framework version.

After sharing it, people noticed that nearly a third of the software he shared was written by himself, and they kept asking how he packaged the WeRead version.

The code was only a few hundred lines, so he open-sourced it casually.

He didn’t expect Pake to be more popular abroad than in China.

Foreigners love packaging web apps as Mac clients, but using Electron makes them too heavy. Pake solved that problem.

Many friends in Taiwan helped promote it because they particularly liked the packaging aspect.

The Trend Weekly started even earlier, about seven years ago when he began leading a team. He felt the team’s technical atmosphere was lacking, so he set a goal: every morning, read some open source tools and tech news, organize them into an internal weekly, and post it on the company’s Yuque.

Later, many people left the company and asked if they could access it from outside. He casually put it in a GitHub README.

After six months, during National Day while at his hometown, he spent two days building a website and just released it.

Mole started as a Shell script he ran locally for a year — nearly 1000 lines — specifically for cleaning up junk cache on programmers’ computers.

He used to buy many paid cleaning tools like iStatistica and CleanMyMac every year, but found them too heavy.

Last National Day, while taking his baby to Sanya for vacation, he had a laptop by the swimming pool. Taking breaks between swims, he wrote the first version of Mole.

Kaku was forked from a terminal tool. He modified it locally for six months and released it during the Chinese New Year.

He initially used a very lightweight terminal that looked great, but when the AI era arrived and multi-window support became necessary, that tool didn’t support it.

After searching, only one project was modifiable, so he did it himself.

Kami originated from his investments. He started investing in US stocks about seven or eight years ago and built a multi-agent investment analysis system locally. But the AI-generated reports were too ugly, so he customized the design according to his taste.

Later, when he saw reports posted by others on Twitter that weren’t great either, he open-sourced it.

By the way, he’s also working on his own font, about one-third complete. The font he usually uses (TsangerJinKai) is commercial. Open source products can use it, but it becomes problematic for business collaborations.

Waza is an engineering skill base distilled from nearly a year’s worth of Claude conversations — about 5-6GB of data.

He used AI to analyze all conversations, breaking them down by project and time dimensions, extracting best practices: how to respond to overseas user needs, which PRs to merge, which features to build.

This logic runs through all his products: He doesn’t start by thinking “what should I build?” Instead, he first encounters a problem that annoys him, and solves it on the fly.

Why Does Mole Have 70% Users Overseas?

After releasing Mole, over 70% of users came from overseas, for several reasons:

First, foreigners are actually more frugal.

European and American users keep their Macs for many years, and they get slow over time.

When Mole cleans up 60GB or 100GB of junk, they get very excited and promote it wildly.

Tw93 says foreigners tend to exaggerate — they’ll say “I want to kneel to you, you’re a genius.”

Second, it’s a cleaning tool that understands programmers.

Traditional cleaning software doesn’t care about various development tool caches. Tools like CleanMyMac, for safety reasons, won’t touch deep development caches.

But Mole is written by a programmer for programmers — it knows what can be safely cleaned.

Third, open source itself is the best product iteration mechanism.

Mole has 300 PRs and 100 contributors, all overseas users.

Each person has a different computer environment, country, and technical role. These contributions allow Mole to clean more and more things — something no company product can achieve.

Of course, there were pitfalls. In the first release, because tw93’s environment was frontend-focused with no database-related configurations, he accidentally cleared the account passwords stored in the cache directory of a user’s JetBrains database tool.

That user was very angry, and he was very sorry.

This experience made him realize that file path conventions in many client products are extremely chaotic. Regular users don’t care, but cleaning tools must.

Mole later added whitelists for all JetBrains products, and this lesson made him increasingly rigorous.

One more detail illustrates Mole’s popularity.

He put two images on Vercel’s CDN for acceleration. Within a week, Vercel sent an urgent notification that he owed $80.

He thought it impossible, but after checking, found those two images alone used 80TB of traffic in just a few minutes.

He immediately realized that the README was being heavily visited.

First Paid Product: Payment Every 10 Seconds

When Mole launched its desktop version, tw93 released it at 10 PM on a Monday (because he works during the day).

After posting, his phone buzzed with payment notifications every 10 seconds. Eventually, his iPhone started overheating.

Before bed, he had to turn off all Google notifications to sleep.

Priced at $9 for a lifetime license, many said he was underpricing it.

Of course, there were critics saying, “You just wrapped a CLI, didn’t you?”

He didn’t care. He wasn’t doing this for the money.

What made him happiest was that people voluntarily donated after using it. When something free gets voluntary payment, it means the work is meaningful.

When his phone showed a WeChat notification saying “So-and-so just donated to you,” he said it truly made him happy.

For payments, he used Dodo Payment, a platform founded by an Indian guy and registered in the US.

He had tried Stripe before, but at the last step, they demanded a Hong Kong ID, which blocked him.

Lemon Squeezy also required company information, not available for individuals.

Then someone on Twitter recommended Dodo. He spent an afternoon setting it up and launched.

However, the payment platform takes 16-17% tax. Later, someone from Dodo’s CEO office proactively found him on Twitter, invited him to a dedicated support group, and gave him some fee reductions.

A practical tip he shared: Once you exceed $10,000, many people will immediately come to audit you — very troublesome. Try to hold funds on a Hong Kong or Singapore card, not directly remit to China.

He went through this hassle a few times himself, eventually having to refund and find another way. But he praised China Merchants Bank’s service staff for being customer-oriented.

Waza: Turning Engineering Experience into AI Instinct

Tw93 has a habit: every week, spend an hour letting AI analyze his past week’s pitfalls, then update Waza.

Waza is his Claude Code skill set, but unlike most people’s Skills, his is 70% code and only 30% Markdown documents.

The reason: MD only tells AI how to work; code lets AI extend based on it.

He dislikes frameworks that tie AI’s hands and feet, like Superpower or Spec programming — too heavy and they drag down model capabilities.

He prefers treating AI as a friend, not an outsourcer or subordinate.

He says, “With Claude 4.6 and 4.7 out, models are getting more capable. The more you constrain them, the more you hold them back.”

Waza contains 8 Skills, covering not just coding but also how to push projects forward, make technical plans, write reader-friendly documentation, and create design drafts.

In his view, an engineer spends only 30% of their time writing code; the rest of the skills are equally important.

Waza itself is self-iterating.

It knows how to iterate itself, so tw93 just needs to periodically feed it new pitfall records, and it updates itself.

Now Waza also supports Codex, because he started using Codex himself, so it analyzes Codex conversation records too.

He also has a private agent based on Waza locally, specifically handling open source project issues and PRs.

This agent knows his requirements for Mole’s style, which features must never be merged, which PRs have problems but can be fixed, and which are outright unsuitable.

He freed himself from the most time-consuming tasks, focusing on building new features.

Why Are His Things So Beautiful?

Many people’s first reaction after using tw93’s tools: “Why is this so beautiful?”

He gave several reasons.

In college, after being recommended for graduate school without exams, he had lots of free time and read every frontend and design book in the library.

Design thinking, minimalism, Japanese design principles — the aesthetic foundation laid during that stage only emerged later in his career.

After joining the workforce, he loved hanging out with designers, often discussing design details together, deeply influenced by their aesthetic.

Later, when responsible for an entire department’s B2B products, he found that using documents to align with people led to different interpretations.

He eventually found the most effective method: directly draw a high-fidelity Sketch mockup, share it in a group chat, call a meeting — everyone got it immediately.

To avoid endless discussions, he forced himself to learn drawing.

There’s a deeper reason: he’s a perfectionist.

He says when he first joined a company, QA testers couldn’t find bugs in his pages; his code could go straight to production without testing.

This habit carried over to open source products. Achieving 75% without bugs isn’t enough; he needs 95%.

Not for showing off, but because he can’t stand ugly things, and he doesn’t want users to keep asking him questions.

He’s recently been reading ancient Chinese paintings from the Yuan to Qing dynasties and books on Japanese design principles.

He says many classical paintings are hard to grasp in terms of artistic conception, but by observing how painters draw horses or compose scenes, he can still pick up something.

The Most Truthful Thing He Said About Long-Termism

“Long-termism helps you be lazier — in a good way.”

He has worked at the same company for 11 years.

He bought Tesla stock at around $100 and NVIDIA stock at around $80. He never sells, only trades two or three times a year.

He says he hates making decisions — once there are multiple options, he gets very torn and feels uncomfortable for days.

So he tries to decide as many things as possible in advance, before decisions even need to be made, so he doesn’t have to agonize repeatedly.

Long-termism for him isn’t a slogan; it’s a lifestyle that reduces decision fatigue.

His GitHub only has 6 pin slots — all filled — and he won’t start any new projects.

He believes that doing 100 products simultaneously means all 100 will be mediocre. Maintaining a few and improving them leads to compounding returns.

Mole, released just six months ago, has already iterated nearly 40 versions. More and more people are using it, more people know about it — that’s real accumulation.

He also mentioned a counterintuitive observation: MiaoYan had been iterating for over six months before being publicly announced, with very few users.

Once he promoted it, the data went from flat to a steep curve.

Good wine also needs a good sign — you still need to tell your story effectively at the right time.

Advice for Non-Tech People Using Vibe Coding

He says the biggest risk for non-tech people building products isn’t not being able to write code — it’s not having general knowledge. After six months, the code stops running, and they don’t even know what went wrong.

He gave an example: AI can easily get a product to 80%, but going from 80% to 100% might take 80% of the time.

Many people don’t understand this. They think frontend is just that, backend is just that, and they can write an app without knowing anything.

But to take that app from “usable by you” to “usable by 100 people,” there are countless bugs you can’t discover because you don’t have the ability to find them.

He recommended several books:

• The Mythical Man-Month: Understand why software projects can’t be solved by just adding people — still applicable in the AI era

• Inspired: Understand product trade-offs, defining minimal loops, planning milestones

• Left Ear to Listen to the Wind (Haoci’s blog and book): Understand how a senior engineer sees problems

• The Unix Philosophy: A thin book about atomic capabilities, pipes, and the low-level logic of system design. He says after reading it in college, he felt like his “power level went up significantly”

His core point: You don’t need to know how to write React, but you need to know when to use React and when you just need a static server.

This kind of judgment is the true moat in the vibe coding era.

One Opinion Worth Saving Forever

He says, in the AI era, the real barrier isn’t the tool you built — it’s your chat history with the AI.

Others can distill your product, but they can’t distill the pits you’ve fallen into, your judgment logic, and the failed paths you and the AI have honed over time.

He emphasized: Recording failures is more important than recording successes.

People only care about the results of success; failure paths tell you how to avoid them next time.

Just like when an online system goes down, you’ll definitely check where it failed, but when it runs fine, no one studies why it’s good.

Regarding memory system design, he has an interesting framework: Design according to human memory patterns.

Large language models are trained on human language, so memory systems should also be like humans: project context memory (what’s currently being done), short-term memory (recent bottlenecks), and long-term memory (historical accumulation).

He doesn’t recommend directly dumping knowledge bases into AI because knowledge expires, and the person feeding it might not know what’s already outdated.

Protect all your conversation records with the AI. Save both the successes and the failures that AI helped you achieve.

These are things others can’t learn.

Several Practical Details for Going Global Commercially

If you plan to launch an overseas product, here’s his experience:

As an individual, you’re naturally at a disadvantage when dealing with commercial resources.

He recommends registering a small US company — the cost is low. Just remember to file taxes annually.

With a US company entity, you can register App Store accounts, payment platforms, and cloud services under the company name, bypassing restrictions on Chinese individuals and getting lower tax rates.

Don’t build your own payment system, and don’t use the big-name platforms.

Stripe imposes many restrictions on Chinese individuals and blocks you at the last step. He recommends Dodo Payment: created by an Indian guy, registered in the US, fast response, handles global payments and tax compliance in various countries, including the EU’s 14-day no-questions-asked refund policy.

Don’t build a customer service system too early.

In the early stages, focus on the main product. When user numbers are small, hand-replying to emails and processing refunds manually is enough.

Many programmers want to automate everything, but at this stage, all energy should go into the product itself.

Throughout this conversation, tw93 repeatedly said one thing: All his products started by solving his own problem first. Then he discovered others had the same problem, and only then did he open source them.

This logic sounds simple, but for 13 years and six tools that people actually use, what lies behind it is extreme restraint about “what not to build” and intense focus on “doing one thing well.”

If you’re thinking about building something now, his advice is: First find the problem that annoys you the most, and solve it.

Don’t overthink. Just solve your own problem.