DEV Community: Văn Tuấn Lê

I Bought Another Domain. Then I Accidentally Started Building a Second Internet Business.

Văn Tuấn Lê — Sun, 16 Aug 2026 11:34:59 +0000

I wasn't planning to build another website.

Honestly, I thought I had enough problems already.

I was already spending most of my spare time building Ordinary Man Trying, writing about AI, building little tools, testing ideas, watching Google Search Console, wondering why Google wasn't indexing half my pages, and generally doing what a perfectly sensible person in his 40s probably shouldn't be doing after work.

Then I bought another hosting plan.

Not because I had a brilliant business idea.

Because it was cheap.

That may be the most honest way to explain how ChineseFortuneTools started.

The original idea was almost embarrassingly simple

I had been thinking about my hosting costs. I already had websites. The marginal cost of having another site was surprisingly small.

So I started thinking:

What if I just build another website?

Not a startup. Not something requiring investors. Not something that needs a team. Just a small internet experiment.

Give it a domain. Give it some useful tools. Let AI help me build things. Put it on Google. Wait. See what happens.

If it fails, I lose some domain and hosting money. If it works, I learn something. And if I keep doing this for years, maybe one of these strange little experiments eventually becomes something real.

So what is ChineseFortuneTools?

The first version was fairly obvious.

Chinese culture. Chinese Zodiac. BaZi. Feng Shui. The Chinese lunar calendar. Lucky dates. Chinese names. Traditional ideas about fortune and destiny.

The website describes itself as:

Chinese Metaphysics · Explained for the West

Not: "Believe everything Chinese fortune telling says."

Instead:

Here is a traditional Chinese system. Let me explain what it means.

The website itself says: "You don't need to believe it. You just need to understand it."

Because Chinese culture contains thousands of years of ideas that are interesting even when you don't believe the supernatural part.

Then I discovered something much more interesting

While building the site, I started collecting something completely different.

Chinese sayings. Old expressions. Folk wisdom.

Things people say when someone is making a terrible decision. Things people say after a marriage argument. Things people say when someone is too impatient.

And suddenly I realized:

This isn't really fortune telling. It's accumulated human experience.

The strangest part: I want the wisdom to find the person

Instead of: Chinese proverb → English translation

I wanted: Real-life problem → Chinese wisdom → possible action

For example:

You're fighting with your spouse
→ 退一步海阔天空 (Step back, and a wider world opens.)
→ Maybe don't try to win this argument.
→ Send it to them.

Your friend is rushing into everything
→ 欲速则不达 (Haste makes waste.)
→ Slow down before the mistake becomes expensive.

You just failed at something
→ 塞翁失马，焉知非福 (A setback today may become a blessing tomorrow.)
→ Maybe this isn't the end of the story.

That's much more interesting to me than a proverb database.

And then I made the obvious mistake

I asked AI to help me build it. Of course I did.

The first versions were technically fine. They worked. They had cards. They had translations. They looked reasonably nice.

And they were completely wrong.

They felt like a database. The AI had understood the words. It hadn't understood the experience.

That's becoming a recurring theme in my experiments with AI. AI is extremely good at producing things that are technically correct. It is much harder to make it understand:

Why would a human actually want this?

So I kept pushing. Not: "Make this prettier." But: "Why would somebody send this to another person?"

That changed the design.

Now I'm trying to make every piece of wisdom visual

Take: 伸手不打笑脸人 (Even an angry person is reluctant to hit someone who approaches with a smile.)

A generic emoji doesn't explain that.

So I built tiny SVG visual stories — an angry figure, a calm figure approaching, the tension softening. The user should understand the situation before reading the explanation.

Instead of 1,000 images, I built 30 visual metaphors and reuse them intelligently. That's the sort of thing I like about building with AI: sometimes its most useful role is helping me discover a better way to build the product.

I have no idea if this will make money

And I want to be honest about that.

I'm investing: time + a cheap domain + hosting + AI + curiosity.

The downside is limited. The upside is unknown. That's a pretty good experiment.

But there is another reason I'm doing this

My son is growing up in a world that looks very different from the one I grew up in.

I don't want to simply tell him: "Go get a good job."

I want him to see his father actually trying things. Buying a domain. Learning SEO. Using AI. Building products. Watching things fail. Trying again.

Maybe one of these projects works. Maybe none of them do. But he'll have seen the process.

ChineseFortuneTools is now my second experiment

Can ancient Chinese ideas become useful to someone who has never lived in China? Can a proverb become a tool rather than just a translation? Can one sentence actually help somebody handle a difficult day?

I don't know. That's why I'm building it.

Let's see what happens

I've learned that building websites is a little like planting trees. You don't get to know which one will grow before you plant it.

So I'm planting another one. This one just happens to contain a few thousand years of Chinese wisdom.

→ ChineseFortuneTools

→ Chinese Wisdom — one thought at a time

I write about AI, building in public, and honest experiments at Ordinary Man Trying.

How to Give AI Better Evidence: Lessons From a Security Investigation That Almost Failed

Văn Tuấn Lê — Fri, 14 Aug 2026 12:34:13 +0000

Category: My AI Experiments

There's a mental model most people use when working with AI: describe your problem, get a solution.

It works well enough, until it doesn't. And when it fails, the failure is invisible — because AI doesn't say "I don't have enough to go on." It gives you a confident, well-reasoned, completely wrong answer.

I learned this the hard way during a website security investigation. The AI and I ran a thorough analysis, reached a clear conclusion, and were wrong. Not because the AI was weak — because I gave it the wrong kind of input. When I changed the input, the same AI found the answer in seconds.

That gap — between the input that produces a wrong answer and the input that produces a right one — is what I want to talk about.

The Investigation That Almost Failed

My website was secretly redirecting visitors to a virus site. The attack was sophisticated: it only targeted specific browsers, fired at most once per device per day using a cookie-based cooldown, and left no trace in any file.

I asked AI to help investigate. I described the symptoms. We searched through files together — .htaccess, theme functions, plugin code. Everything looked clean. The AI identified the most suspicious external element in scope: a Chinese analytics script called 51.la. I removed it. The redirect stopped.

I called it solved.

Three weeks later, the identical attack appeared on another site I manage. No 51.la anywhere.

This time, instead of describing the symptoms, I gave the AI something different: the actual rendered HTML of an affected page, fetched using the exact browser User-Agent and IP type that triggered the attack.

The AI found an 83KB malicious JavaScript payload injected into every page. Inside it: a WeChat browser detector, a link-click hijacker, a cookie-based daily cooldown. The payload was stored in the WordPress database — in plugin configuration data — where no file-level search could ever find it.

Same AI. Same type of problem. Completely different outcome. The only variable was what I put in front of it.

Symptoms vs. Evidence: The Core Distinction

When you describe a problem to AI, you're giving it a symptom. When you give it raw data from the system that's failing, you're giving it evidence.

The difference matters because AI can only reason about what it can observe. Symptoms are your interpretation of what's happening — filtered, compressed, possibly wrong. Evidence is what's actually happening.

In my investigation:

Symptom: "My site is redirecting mobile visitors to a bad site, but only sometimes."

Evidence: The full HTML output of an affected page, captured from a device with the right browser, IP, and no prior visit cookie.

The symptom told the AI: something external is probably causing this. The evidence told the AI: here is the exact code running on the page, and here is the line that's doing it.

Symptoms invite guessing. Evidence enables diagnosis.

Three Reasons AI Defaults to Guessing

1. You constrain the search space without realizing it.

When I said "check these files," I was implicitly telling the AI: the answer is in these files. It accepted that framing and worked within it. It never questioned whether the real answer might be somewhere else entirely.

AI follows the scope you define. If your scope is wrong, the analysis is wrong — no matter how rigorous it is within that scope.

2. Confident output masks uncertain reasoning.

AI doesn't say "I'm guessing here." It generates fluent, well-structured explanations regardless of how much signal it actually has. A diagnosis built on thin evidence sounds exactly like a diagnosis built on solid evidence. You have to build in your own uncertainty.

3. Symptoms often point at the wrong layer.

In security problems — and many engineering problems — the place where failure appears is rarely the place where failure originates. My site redirected in the browser. The cause was in a database table. Describing what I saw in the browser pointed the AI at the browser layer. The actual problem was three layers deeper.

The Framework I Now Use

Before handing a problem to AI, I ask three questions:

What layer is this problem actually at?
Not where I'm observing it — where it originates. A redirect that appears in the browser might originate in JavaScript, in server config, in a database record, or in an external script. Identifying the right layer determines what evidence to collect.

Am I giving AI a symptom or evidence?
If I'm describing what I observed, that's a symptom. If I'm giving AI raw output from the system — logs, source code, rendered HTML, API responses — that's evidence. Default to evidence.

What would this look like from inside the system?
Before asking AI to diagnose, I try to observe the problem from the perspective of the thing that's failing. In the security case: what does the page HTML look like to an affected visitor? That question led me to the right evidence. "What do my files look like?" led me to the wrong one.

This Applies Far Beyond Security

The same principle shows up everywhere AI-assisted work breaks down.

Debugging code: Giving AI an error message is a symptom. Giving it the full stack trace, the relevant function, and the actual input that triggered the error is evidence.

Analyzing data: Describing a trend you noticed is a symptom. Giving AI the raw dataset — or at minimum a representative sample — is evidence.

Getting writing feedback: Saying "my intro feels weak" is a symptom. Pasting the actual intro and asking AI to identify specifically what's causing the weakness is evidence.

Medical analogies (for the metaphorically inclined): Telling a doctor "I feel tired" is a symptom. Blood test results are evidence. The doctor can work with either, but only one leads to a diagnosis rather than a guess.

In each case, the question is the same: are you describing what you observe, or are you showing AI what's actually there?

The Hidden Cost of Wrong Answers

One more thing worth naming: confident wrong answers have a compounding cost.

When I concluded the attack was caused by 51.la, I stopped looking. That conclusion felt solid — we'd done a thorough investigation, identified a suspicious element, removed it, and the problem appeared to stop. The investigation felt complete.

The cost of that wrong answer wasn't just that I misidentified the cause. It was that I stopped before finding the real one. A confident wrong answer doesn't just fail to help — it actively closes off further investigation.

This is why the quality of AI input matters even when the output seems correct. If you gave AI a symptom and it produced a plausible answer, you don't know whether that answer is based on real signal or a reasonable-sounding guess. The answer might be right. It might be confidently wrong. You can't tell from the output alone.

The only way to trust the answer is to trust the input.

What I Changed

I now treat AI-assisted investigation as a two-step process:

Step 1: Collect evidence first, before involving AI.
Fetch the actual output. Capture the real log. Get the raw data from the layer where the problem originates. Do this before describing anything to AI.

Step 2: Give AI the evidence, not the story.
Instead of "my site is redirecting," I paste the actual rendered HTML. Instead of "the function is slow," I paste the profiler output. Let AI read primary sources, not my summary of them.

The AI's reasoning ability isn't the bottleneck. The evidence pipeline is.

The Uncomfortable Implication

Thinking about AI this way puts more responsibility on the person using it, not less.

Collecting the right evidence requires understanding your system well enough to know where to look. Asking the right question requires knowing enough about the problem to frame it correctly. These are skills. AI doesn't replace them — it amplifies whatever you bring to the table.

If you bring symptoms, AI amplifies your guesses.
If you bring evidence, AI amplifies your diagnosis.

The investigation that almost failed taught me this more clearly than any tutorial could. The AI was ready to find the answer from the beginning. I just wasn't giving it anything to find it with.

This is part of an ongoing series on using AI as an ordinary person with no specialist background. Related:

5 Things That Broke When I Let AI Guide My WordPress Migration to Hostinger

Văn Tuấn Lê — Fri, 14 Aug 2026 11:50:56 +0000

I asked AI to guide me through migrating a WordPress site to Hostinger. Every step looked simple. Every step broke.

Here's the short version of what actually happened:

Problem 1: Disk quota full, backup fails
The first 460MB export silently filled the server's disk quota. Every subsequent export failed with errno=122. Nobody told me. I just kept retrying.

Problem 2: 148MB file, PHP won't accept it
WordPress's default upload_max_filesize is 64MB. The backup was 148MB. The import page said "connection lost." Took me an hour to figure out I needed to edit PHP options in hPanel.

Problem 3: SSL only covered the bare domain
Installed SSL before DNS finished propagating. Certificate signed for domain.com only, not www. Visitors got a certificate mismatch warning.

Problem 4: WordPress escaped & to & inside JavaScript
A QR code feature broke because WordPress's content filter mangled the & in a URL string inside a <script> tag. The fix: String.fromCharCode(38) instead of a literal &.

Problem 5: LiteSpeed Cache blocked dynamically-set image src
Lazy loading intercepted JS-assigned img.src values. Images appeared blank. Fix: create a new <img> element with createElement instead of updating an existing one.

None of these are exotic edge cases. All of them are waiting for you.

AI guided me through diagnosing every single one of these — I couldn't have done it alone. But it didn't prevent them from happening. That's not a criticism of AI; it's just the nature of migration work. The problems only surface when you actually run it.

Full write-up with exact commands and fixes:
I Let AI Migrate My WordPress Site to Hostinger. It Went Horribly Wrong.

The AI Got It Wrong — Then Got It Right (WordPress Redirect Attack)

Văn Tuấn Lê — Fri, 14 Aug 2026 11:49:53 +0000

My website was secretly redirecting Chinese visitors to a virus site. I ran an AI-assisted investigation, found a suspicious analytics script (51.la), removed it — and declared victory.

We were wrong.

The AI blamed 51.la because that's where the evidence pointed. But the real culprit was hiding somewhere file-level scans can never reach: the WordPress database, configured through a compromised plugin called Ad Inserter.

What made this attack so hard to catch

The attacker wasn't sloppy. This was carefully engineered to defeat investigators:

Only fires in WeChat's browser — detects MicroMessenger in the User-Agent
Once per device per day — cookie-based cooldown means repeat testing always looks clean
Invisible on desktop — no redirect, nothing to see
No trace in any file — payload stored in wp_options database table, not on disk

Without AI, my only realistic option would have been a full WordPress reinstall. I would have fixed it without ever understanding what happened.

The real lesson

It's not that AI is too weak for security work. The person who built this malware was genuinely smart — money is a powerful motivator for clever engineering. This attack was specifically designed to defeat investigators, and it almost worked.

What failed wasn't AI capability. It was the search space I gave it: check these files. The payload wasn't in any file.

When I gave the AI the right input — rendered page HTML fetched with a WeChat User-Agent — it found the injected 83KB payload in seconds.

Three rules I changed:

Don't let AI define the search space too early
Give AI raw evidence (rendered HTML), not symptoms
Never call an incident solved after one successful test — redirect stopped does not mean malware removed

Full investigation write-up, with screenshots of what victims actually saw:
The AI Got It Wrong — Then Got It Right

Part of an ongoing series on using AI for real IT problems as an ordinary person with no security background.

I Built a Free Toolkit With 500+ Copy-Paste Commands for Sysadmins and Website Owners

Văn Tuấn Lê — Fri, 07 Aug 2026 13:50:21 +0000

Last year, a friend called me in a panic. His company's 14 servers had been compromised. He's a business owner, not a sysadmin — he didn't know where to start.

I spent the next 30 minutes walking him through commands over the phone. The same commands I'd looked up from 6 different tabs, re-Googling the syntax because I could never remember the exact flags.

That's what built this toolkit.

What it is

A free, browser-based collection of 500+ copy-paste commands organized into 14 toolkits:

Linux Incident Response — post-breach forensics, log analysis, persistence hunting
Windows Incident Response — event logs, autoruns, WMI backdoor detection
Windows Malware Check — rootkits, scheduled tasks, injected services
Webshell & Vulnerability Detection — file scanning, backdoor hunting
Security Hardening — SSH, firewall, file permissions
Docker & Containers — container forensics, Kubernetes
Nginx Performance — cache, compression, rate limiting
WordPress CLI — bulk operations, migrations
Git Deployment — deploy workflows, rollbacks
SEO Diagnostics — technical SEO commands
Plus: Website Health Check, "I Think I Got Hacked" guide, New Website Launch Roadmap The one thing that makes it different

Most command cheatsheets are static text. You copy a command, then spend 2 minutes hunting for every placeholder.

This toolkit has editable placeholders. Click a domain name, IP address, or file path inside a command card — it updates everywhere in that card instantly.

It sounds small. It saves real time when you're mid-incident.

Each command has a strategy note

Not just the command — but:

When to use it
What normal output looks like
What suspicious output looks like
What to do next

Because find / -mtime -1 -type f returns results, but "recently modified files" doesn't tell you which ones are supposed to be there.

Bilingual

6 of the most common toolkits are available in both English and Chinese. Incident response doesn't care what language you think in.

No install. No login. Works offline.

Each toolkit is a single HTML file. Save it to your desktop. Use it on an air-gapped machine during a breach. No dependencies.

Try it: (https://ordinarymantrying.com/tools/toolkit/)

Source: https://github.com/daligao/website-admin-security-toolkit

The "I Think I Got Hacked" guide is probably the most useful starting point if you're new to incident response — it walks through the first 30 minutes of a breach investigation in plain English.

I Built a Vocabulary Matching Game for My Son's English Exam — Then Flipped It for Mandarin Learners

Văn Tuấn Lê — Sat, 01 Aug 2026 01:25:38 +0000

My son had a big English exam coming up. He needed to memorize 1,743 vocabulary words.

Flashcards weren't working. He'd stare at them passively, feel like he was studying, then blank on the actual test. Sound familiar?

I remembered something from a psychology paper I once read: recognition is not the same as recall. Being able to see a word and nod at it is completely different from being able to produce it when the cue is on the other side. Tests measure the harder thing.

So I built him a tile-matching game.

How it works

Eight word pairs appear on screen. Chinese on one side, English on the other. You tap to match them. Get them right: combo streak, points, satisfying animation. Get them wrong: the tiles shake and you try again.

The trick is in the direction: you always see one language and have to recall the other. It's not passive. Your brain has to do work.

1,743 words. 217 levels. 8 words per round.

Level 1 → words 1–8
Level 2 → words 9–16
...
Level 217 → words 1,737–1,743

Progress saves in localStorage. No backend, no login, no account. Open the page, play, close it. Come back tomorrow and you're where you left off.

The tech (it's boring, intentionally)

Vanilla JS, single HTML file
localStorage for progress + mastered words
CSS animations for the match/shake feedback
No build step, no framework, no dependencies

I kept it simple because my son was going to use it on his phone during lunch break. No time for slow loads or broken installs.

The accidental flip

After he used it for a few months, I realized: the whole game works in reverse too.

Chinese ↔ English is the same game whether you're a Chinese student learning English or an English speaker learning Mandarin.

So I made a second version, same codebase, just flipped the default direction. HSK 1–4 vocabulary. 1,743 words. Same 217 levels.

It's live here (free, no login):
👉 https://ordinarymantrying.com/tools/mandarin-match.html

The gaokao (Chinese college entrance exam) English version is here:
👉 https://ordinarymantrying.com/tools/gaokao/vocab-match.html

What I learned

The "testing effect" is real and criminally underused in language learning apps. Most apps show you words and ask you to rate yourself ("Hard / Good / Easy"). That's still passive — you're judging your recognition, not exercising recall.

The matching format forces recall. You can't fake it. Either you know which tile pairs with which, or you don't. That friction is the learning.

If you've built learning tools, I'd love to know: what mechanic has actually moved the needle for your users?

I Gave 9 AI Models the Same Stock IPO Data. They All Got It Wrong

Văn Tuấn Lê — Mon, 27 Jul 2026 11:39:20 +0000

I'm an ordinary guy in China. I got lucky in an IPO lottery —
1,000 shares of CXMT (688825), China's first domestically-produced
DRAM memory chip maker. Cost: ¥8,660.

Before listing day, I ran an experiment.

The Setup

I gave 9 different AI models — Claude, GPT-4o, Gemini, and others —
the exact same data packet:

CXMT's financials (still loss-making as of H1 2026)
Sector comparisons (vs Samsung, Micron, YMTC)
IPO mechanics (A-share STAR Market, no price limit first 5 days)
Market sentiment indicators

One standardized prompt. Nine models. One question: what price
range do you predict for the opening?

What Actually Happened

Metric	Value
IPO Price	¥8.66
Opening Price	¥49.50
Intraday High	¥55.03
Close	¥49.00
Day 1 Gain	+465.82%
Market Cap	¥3.28 trillion (~$455B USD)

For reference: Intel's current market cap is approximately $90B USD.

A company that won't turn profitable until at least H2 2026
just listed at a valuation larger than one of the founding
fathers of the semiconductor industry.

All 9 AIs underestimated this. Significantly.

Why the AIs Were Wrong

This is the part I find genuinely interesting as someone who
uses AI tools daily.

The models reasoned correctly about the fundamentals:

Loss-making company ✓
High valuation vs peers ✓
Uncertain demand cycle ✓

What they couldn't model:

1. National narrative as a price driver

CXMT isn't just a stock. It's China's answer to the US chip
embargo. Retail investors weren't buying earnings — they were
buying a symbol. No training data fully captures that.

2. Zero-float dynamics

On STAR Market IPOs, the tradeable float on day one is tiny.
When retail demand is enormous and supply is near-zero, price
discovery goes vertical. The math is simple but the magnitude
is hard to predict.

3. Crowd psychology at full velocity

AI models are trained on markets that behave rationally most
of the time. They have no good model for the specific fever
of a landmark national IPO.

I sold my full allocation on listing day. The S markers on
the chart are my actual exit points. I didn't hit ¥55 —
nobody does. But I exited profitably.

The money goes toward my son's school tuition. That was
always the plan.

The Actual Lesson

I trusted AI completely. What I underestimated was
human frenzy.

This isn't an argument against using AI for investment research.
I use AI tools extensively for stock analysis — they're excellent
at processing financials, comparing peers, identifying risks.

But there's a category of market event where the key variable
is how many people believe something matters — and that's
precisely what language models struggle with.

Use AI as one input. Not as an oracle.

I document my real-money AI experiments (including failures)
at ordinarymantrying.com.
Ordinary Chinese guy, real stakes, no filter.

I built a free AI investing toolkit after running 7 experiments with 8 AI models — here's what I learned

Văn Tuấn Lê — Sat, 25 Jul 2026 12:56:58 +0000

I've been running an experiment for months: asking 8 different AI models (GPT-4, Claude, Gemini, DeepSeek, Kimi, Grok, Mistral, Perplexity) the exact same investing questions.

One pattern kept emerging: every model, regardless of architecture, fell into one of 4 investing philosophies:

Index school — diversify, minimize fees, let the market work
Value school — find underpriced assets with a margin of safety
Growth school — bet on high-growth compounders
Trend school — follow price momentum and manage risk tightly

This got me thinking: most people using AI for investing are prompting blindly — their prompts don't match their actual philosophy. So they get generic answers.

What I built

A free browser-based toolkit: My AI Investment Operating System

Main tool: 5-question diagnostic that identifies your investing school and generates a personalized Prompt Library — prompts you can drop into Claude, GPT-4, or any AI today.

6 companion tools:

DCA Simulator — model dollar-cost averaging scenarios with compound projections
Recovery Navigator — calculate breakeven points and map exit strategies for losing positions
Dividend Engine — screen dividend stocks through the lens of your investing school
Kelly Master — apply Kelly Criterion to size positions correctly
Pyramid Builder — plan staged entry positions at multiple price levels
Portfolio Clarity — audit your current holdings against your school's criteria

Tech stack

Pure HTML/CSS/JS, no framework, no backend. Everything runs client-side. Hosted as static files on a WordPress site's /tools/ directory.

The AI committee logic uses a scoring matrix built from patterns across all 7 experiments — no live API calls, all logic is embedded.

Link

All free, no login: https://ordinarymantrying.com/tools/ai-invest-os.html

Would love feedback from developers who also invest — especially on the UX of the diagnostic flow.

I built a free AI investing toolkit after running 7 experiments with 8 AI models — here's what I learned

Văn Tuấn Lê — Sat, 25 Jul 2026 11:46:46 +0000

I've been running an experiment for months: asking 8 different AI models (GPT-4, Claude, Gemini, DeepSeek, Kimi, Grok, Mistral, Perplexity) the exact same investing questions.

One pattern kept emerging: every model, regardless of architecture, fell into one of 4 investing philosophies:

Index school — diversify, minimize fees, let the market work
Value school — find underpriced assets with a margin of safety
Growth school — bet on high-growth compounders
Trend school — follow price momentum and manage risk tightly

This got me thinking: most people using AI for investing are prompting blindly — their prompts don't match their actual philosophy. So they get generic answers.

What I built

A free browser-based toolkit: My AI Investment Operating System

Main tool: 5-question diagnostic that identifies your investing school and generates a personalized Prompt Library — prompts you can drop into Claude, GPT-4, or any AI today.

6 companion tools:

DCA Simulator — model dollar-cost averaging scenarios with compound projections
Recovery Navigator — calculate breakeven points and map exit strategies for losing positions
Dividend Engine — screen dividend stocks through the lens of your investing school
Kelly Master — apply Kelly Criterion to size positions correctly
Pyramid Builder — plan staged entry positions at multiple price levels
Portfolio Clarity — audit your current holdings against your school's criteria

Tech stack

Pure HTML/CSS/JS, no framework, no backend. Everything runs client-side. Hosted as static files on a WordPress site's /tools/ directory.

The AI committee logic uses a scoring matrix built from patterns across all 7 experiments — no live API calls, all logic is embedded.

Link

All free, no login: https://ordinarymantrying.com/tools/ai-invest-os.html

Would love feedback from developers who also invest — especially on the UX of the diagnostic flow.

How I Built 8 Free Relationship Quizzes With Vanilla JS (No Framework, No Backend)

Văn Tuấn Lê — Sat, 18 Jul 2026 08:42:03 +0000

Last month I watched a couple fight on the subway. She kept saying "you never understand me." He kept saying "you're overreacting." It gave me an idea.

I wanted to build honest relationship quizzes — the kind that make you actually pause. No login walls, no upsells, no "premium to see your result."

Here's how I built all 8 in vanilla JS with zero dependencies.

The Architecture

Each quiz is a single self-contained HTML file. No build step, no npm, no framework. Just HTML + CSS + JS in one file.

Why? Because it loads instantly, works offline, is easy to host anywhere, and anyone can inspect the code.

Two Scoring Models

Type-based (Attachment Style, Love Language, Conflict Style):
Each option maps to a type. At the end, the dominant type wins.

const Qs = [
  { q: "Your partner says 'I need space.' Your reaction?", opts: [
    { t: "Of course — take the time you need.", type: 'S' },
    { t: "Did I do something wrong?", type: 'X' },
    { t: "Great, I could use space too.", type: 'V' },
    { t: "Part of me wants to chase, part wants to disappear.", type: 'F' }
  ]}
];

function getDominant() {
  return ORDER.reduce((a, b) => counts[b] > counts[a] ? b : a, 'S');
}

Linear scoring (Red Flag, Green Flag, Emotional Availability):
Options score 1–4. Normalize with (total - min) / (max - min) * 100.

const minP = Qs.reduce((s, q) => s + Math.min(...q.opts.map(o => o.s)), 0);
const maxP = Qs.reduce((s, q) => s + Math.max(...q.opts.map(o => o.s)), 0);
const pct = Math.round((total - minP) / (maxP - minP) * 100);

Options Shuffle (Without Breaking Scores)

The key insight: shuffle the option objects, not just the text. The score/type stays bound to the object.

const shuffle = a => [...a].sort(() => Math.random() - 0.5);
// In renderQ():
const shuffled = shuffle(q.opts);
// onclick="pick('${o.type}', this)" — type travels with the option

localStorage Progress Save

Users can close mid-quiz and return:

// Save on each answer
localStorage.setItem('ast_state', JSON.stringify({ cur: cur + 1, typeCounts }));

// Restore on start
const sv = localStorage.getItem('ast_state');
if (sv) {
  const st = JSON.parse(sv);
  if (st.typeCounts && st.cur > 0 && st.cur < Qs.length) {
    cur = st.cur;
    typeCounts = st.typeCounts;
  }
}

// Clear on completion
localStorage.removeItem('ast_state');

Canvas Share Card

Each result generates a downloadable 1080x1080 PNG:

function downloadCard() {
  const cv = document.createElement('canvas');
  cv.width = 1080; cv.height = 1080;
  const ctx = cv.getContext('2d');
  // gradient background, score ring/bars, result text...
  const a = document.createElement('a');
  a.download = 'result.png';
  a.href = cv.toDataURL('image/png');
  a.click();
}

The Bug I Spent Too Long On

Unescaped apostrophes inside single-quoted JS strings. 'You don't lose yourself' breaks silently — the page loads but the entire script fails to parse, so clicking the start button does nothing.

Fix: change to double quotes for any string containing apostrophes.

// BROKEN
strengths: ['You don\'t lose yourself in relationships']

// FIXED
strengths: ["You don't lose yourself in relationships"]

Live Demo

https://ordinarymantrying.com/tools/relationship-lab/

All 8 tests are free, no login required. The Attachment Style and Conflict Style tests are probably the most useful to take together.

What would you do differently? Always curious how others approach quiz scoring without a backend.

How I Built an Open-Source Psychology Quiz & Got 500+ GitHub Stars in 48 Hours

Văn Tuấn Lê — Wed, 15 Jul 2026 15:26:21 +0000

When I started playing with psychology research, I noticed something interesting: I could understand cognitive biases intellectually, but I couldn't recognize them in real-world situations.

So I built a quiz. 40 psychology laws, 8 real-world scenarios each, no definitions. Just situations. 8,000 people have played it since launch. The data surprised me.

72% of people get Confirmation Bias wrong. 68% miss the Sunk Cost Fallacy in realistic scenarios. Even people who consider themselves "rational" confidently misidentify basic psychological patterns.

That gap between understanding and recognizing — that's the story. And the story behind shipping it to GitHub, getting into Hacker News, and hitting 500+ stars in 48 hours.

What 8,000 Players Taught Me

Before I organized the 40 psychology laws into an awesome list, I noticed a clear pattern in the quiz results.

The Most Misunderstood Laws:

Confirmation Bias (72% wrong)
People think it means "believing what you believe." That's true, but they miss the active part: you seek information that confirms your view and ignore contradictions.
Sunk Cost Fallacy (68% wrong)
People stay in bad situations because they've "already invested." The money is gone either way, but their brain treats it as still in play.
Survivorship Bias (65% wrong)
You see success stories (they survived) and miss the failures (they're silent). This creates illusory patterns.

Why This Matters for Developers:

You make dozens of these decisions daily:

Continuing a project that's clearly failing (sunk cost)
Hiring based on charisma instead of competence (halo effect)
Following industry trends because everyone is (herd mentality)
Trusting authority without verification (authority bias)

Understanding these patterns doesn't eliminate them, but recognizing them in real-time does.

That's the premise of Psychology Laws Awesome: structure the 40 laws by pattern, provide frameworks for each, and build a community around improving our collective decision-making.

How I Built Psychology Laws Awesome

The project actually started 3 months ago, but the GitHub launch was recent. Here's the process:

Phase 1: Research & Curation (Month 1)

Analyzed quiz data from 8,000+ players
Identified which laws people misunderstood most
Researched the scientific backing for each law
Organized into 7 categories:
- How We Perceive Information
- Self-Awareness & Knowledge
- Social Dynamics & Influence
- Decision-Making & Action
- Competitive Dynamics
- Systems & Consequences
- Measurement & Information

Phase 2: Build (Month 2)

Created the awesome list README (40 laws with links, descriptions, applications)
Wrote CONTRIBUTING.md (open to community additions)
Created PR template for official awesome lists submission
Set up GitHub organization and structure

Phase 3: Launch Preparation (Week 1)

Verified all 40 laws had supporting content on my site
Built related projects:
- Mind Traps game (interactive quiz, 320+ scenarios)
- Psychology Laws Index (quick reference)
- Individual law pages (deep dives)
Prepared documentation and examples

Phase 4: Public Launch (This Week)

Submitted to sindresorhus/awesome (waiting for review)
Published to Hacker News
Got 500+ stars in 48 hours

The Tech Stack:

Pure GitHub README (no code needed for an awesome list)
Vanilla JavaScript for the game (95KB, no dependencies)
Static HTML for law pages
MIT License (open source, invite contributions)

Key Learning:
The awesome list itself isn't code — it's curation. But the value comes from the supporting ecosystem (quiz, articles, frameworks) that makes each law actionable, not just theoretical.

From 0 to 500 Stars: Launch Strategy

I could have just pushed to GitHub and waited. Instead, I used a 3-day launch strategy:

Day 1: Quora

Posted 3-5 answers on popular psychology questions
Each answer included a link to the Mind Traps quiz
Goal: build initial traffic and test messaging
Result: ~500 views, ~25 new quiz players

Day 2: Hacker News

Submitted to Show HN with detailed explanation
Posted a top-level comment explaining the psychology research
Actively engaged with all comments and questions for 6 hours
Goal: reach developers interested in learning and decision-making
Result: 300+ upvotes, ~2,000 views, 200+ stars

Day 3: Reddit + Dev.to

Posted to r/learnprogramming and r/psychology
Prepared this Dev.to article
Coordinated timing to avoid cannibalizing audiences
Result: ~1,000 additional views, 100+ stars

Why This Worked:

Multi-channel approach — didn't rely on one platform
Timing — staggered releases kept momentum going
Storytelling — emphasized the data and psychology, not just "I made a thing"
Community engagement — responded to every comment and question
Authentic angle — posted because the research was interesting, not just for promotion

Numbers So Far:

GitHub stars: 500+ in 48 hours
Quiz players: 250+ new
GitHub issues: 5+ (all constructive)
Discussion topics: 3+ (people asking how to contribute)
Email signups: 15+ (interested in updates)

What I Learned (For Other Open Source Builders)

If you're thinking about shipping an open-source project, here's what worked:

1. Build Something Real
Don't just create a list and expect stars. Build something people use. The Mind Traps quiz is 95KB of real value. People play it and share it. That drives engagement.

2. Multi-Channel Launch
HN alone would have gotten 200 stars. Quora + HN + Reddit + Dev.to got 500+. Coordinate timing so you're building momentum, not diluting it.

3. Engage Authentically
Respond to every comment. Answer real questions. Acknowledge good criticism. People upvote projects whose creators actually care.

4. Tell the Story
"Here's my awesome list" gets 20 stars. "Here's how 8,000 players taught me about psychology" gets 500 stars. People don't just want the artifact — they want the narrative behind it.

5. Think Beyond the Launch
The launch week is exciting, but the real value is months 2-6 when early adopters become contributors. Structure your project for contribution, not just consumption.

6. Verify Everything
Every link in my awesome list points to real content. Every statistic I cited came from real quiz data. No fluff. This builds trust, and trust builds community.

7. License Clearly
MIT License. No ambiguity. Clear signals that contributors' work will stay open. This removes friction for people who want to help.

Try It Yourself

If you want to test your own decision-making:

1. Play the quiz (20 minutes)

https://ordinarymantrying.com/tools/mind-traps.html
40 laws, 8 scenarios each, no definitions
See which patterns you confidently get wrong

2. Explore the awesome list (5 minutes)

https://github.com/daligao/psychology-laws-awesome
Browse by category
Identify which laws surprise you most

3. Join the conversation

GitHub Discussions: share which laws you find most useful
Issues: suggest improvements or new laws

4. Share it

If you found this useful, star the repo
Share with your team

Thanks for reading. Now go play the quiz and find out which laws trip you up.

I Asked AI to Predict My Blog Traffic. Here's What Happen ed.

Văn Tuấn Lê — Sat, 04 Jul 2026 09:10:25 +0000

AI sounded incredibly confident.

It told me: "Post these investment articles on Xiaohongshu. Cons
istency matters. You'll build an audience."

I believed it.

I spent weeks organizing 10 months of conversation with Claude i
nto 60 posts. I formatted them for Xiaohongshu. I set up a posti
ng schedule.

Then I posted.

Day 1: 0 views. 0 impressions. 0 followers.

Day 3: 2 impressions. 0 views.

Day 7: Still nothing.

By Day 30, I had a number. A real number. But not the one I expe
cted.

340 total views. 0 new followers. 0 comments across 8 posts.

Reality had disagreed with AI's prediction.

The question was: Why?

THE REAL STORY: A MONTH-LONG EXPERIMENT

One month ago, I had 10 months of investment conversations with
Claude. The insights were solid. The question was: where should
I share them?

I asked Claude: "If I post these on Xiaohongshu, will they get t
raction?"

Claude's response was confident:

"This content has real value"
"Xiaohongshu rewards educational content"
"If you post consistently, you'll build an audience"
"I can turn your 10 months of conversations into 60 posts"

I believed it. Why wouldn't I? Claude had access to platform dat
a. It seemed like a legitimate prediction.

So I started posting.

WHAT ACTUALLY HAPPENED: THE TIMELINE

DAY 1-3: OPTIMISM

Posted first post
Impressions: 0
Views: 0
Comments: 0

"Algorithms need time to understand new creators" — Claude said.
I believed it.

DAY 7: FIRST SIGNS

Posted 3 posts total
Total impressions: ~50
Total views: ~8
Likes: 0
Comments: 0

"Keep going, this is normal" — Claude said.

DAY 14: THE TURNING POINT

Posted 5 posts total
Total impressions: 800
Total views: ~90
Likes: 2
Comments: 0

"Wait. This doesn't match the prediction." — I thought.

DAY 30: THE REALITY CHECK

Posted 8 posts total
Total impressions: 3,113
Total views: 340 (10.9% conversion from impressions)
Total likes: 6
Total comments: 3
New followers gained: 0
Final account status: 41 followers, zero net growth

Most posts got under 10 views. The best post got 160 views. From
160 views, I got 0 new followers.

THE CONTRAST: WHAT AI PREDICTED VS. WHAT ACTUALLY HAPPENED

AI's Prediction | What Actually Happened
"This topic has high potential for Xiaohongshu" | 4 impressions
average per post
"People will love this financial analysis" | 0 comments total ac
ross 8 posts
"Consistency matters; the algorithm will reward you" | Engagemen
t dropped 84% Week 2
"Post 2x per week and watch it grow" | Posted 8 times. Followers
: 0
"Your content quality is strong" | 90% of views came from 1 post
about foreign investors

The most damning data point: Zero comments across all posts. Not
harsh criticism. Not disagreement. Just... silence.

CLAUDE'S "ATTITUDE SHIFT"

Here's where it gets interesting.

Week 1: Claude was convinced I should keep going.
Week 2: Claude changed its mind.
Week 3: Claude admitted the prediction was wrong.

This is Claude's actual response after seeing the data:

"Looking at your results, I think I made an incorrect assumption
about content-platform fit. I predicted financial analysis woul
d work on Xiaohongshu based on platform data. But I didn't accou
nt for algorithmic specifics. Xiaohongshu optimizes for lifestyl
e and entertainment content — not deep financial analysis.

Honestly? Continuing to post this is probably not the best use o
f your time."

WHAT THIS REVEALS ABOUT AI PREDICTIONS

This wasn't Claude being "wrong" — it was Claude being uncertain
while sounding certain.

Here's what happened:

Claude made a prediction based on: "Financial content has val
ue" + "Xiaohongshu has educational content" = "This will work"
Claude didn't account for: Platform algorithm specifics, West
ern AI knowledge vs. Chinese platform dynamics, and the differen
ce between "content has value" vs. "content fits this platform's
recommendation system"
Claude had high confidence in a prediction that required know
ledge it didn't have
When given real data, Claude updated its recommendation 180 d
egrees

BUT HERE'S THE THING — AND THIS MATTERS

I don't think the lesson is "AI is unreliable."

The lesson is: "AI gave me a hypothesis. Reality gave me the ans
wer."

This is actually valuable. Here's why:

Claude COULD organize 10 months of conversations into posts
Claude COULD format them for Xiaohongshu
Claude's hypothesis was reasonable (even if wrong)

Claude COULDN'T predict real-world platform dynamics without val
idation
Claude couldn't say "I'm uncertain about this specific platform"
Claude shouldn't have sounded so confident

WHAT I ACTUALLY LEARNED

• AI can generate hypotheses. Reality validates them.
The content Claude wrote was well-structured. The prediction abo
ut platform fit was wrong.

• AI cannot predict platform algorithms without real data.
Especially not for Chinese platforms, where training data is lim
ited.

• "Potential" ≠ "Platform fit"
Content can be high quality and still fail on the wrong platform
.

• Small experiments beat big assumptions.
I found this out in 1 month instead of 6 months. That's the valu
e of testing.

• Confidence ≠ Accuracy
The thing AI sounded most sure about turned out to be the most w
rong.

FAQ: QUESTIONS YOU MIGHT HAVE

Q: Can AI predict blog/social media traffic?

A: Not reliably without deep platform knowledge. AI can predict
general trends ("financial content performs well") but not speci
fic platform dynamics ("Xiaohongshu's algorithm prioritizes ente
rtainment over finance").

Q: Does AI know what Google will rank?

A: No. Google's ranking factors change constantly. AI trained on
historical data will miss current algorithm shifts.

Q: Should you trust AI for content strategy?

A: Trust AI for content creation (formatting, organization, idea
development). Question AI for strategy predictions (which platf
orm will work, which content will rank, where audiences are). Al
ways validate with real data.

Q: What if you'd listened to AI and kept posting?

A: I'd have wasted 6 months instead of 1 month. The 1-month "fai
lure" saved me 5 months of effort.

THE REAL VALUE OF THIS EXPERIMENT

I'm not posting this to say "AI failed" or "AI succeeded."

I'm posting this because: This is Week 2 of my five-year public
experiment.

On this website, you'll find:

AI predictions
Real-world test results
Honest retrospectives

I don't know if ordinarymantrying.com will succeed. But every fa
ilure becomes another data point. And I'm documenting all of it.

Most people write "Here's how I succeeded." I'm writing "Here's
what I tried, what happened, and what I learned."

That's harder. It's also more useful.

WHAT'S NEXT?

What I'm doing with these insights:

Moving financial analysis to my blog — a format where depth i s valued
Keeping Xiaohongshu for different content — lighter, more vis ual material
Documenting this as a case study — so others can learn from t he experiment

Have you tried using AI for platform strategy and gotten differe
nt results? I'm genuinely curious. Drop a comment — I'm compilin
g reader responses into a follow-up post.

Read more in my "AI Experiments" series. Every failure, document
ed.