Building with AI

The problem

I wanted to test two hypotheses about how children learn to write: whether AI can coach in real time through repeated practice, and whether the model can help without ghostwriting.

The constraint

I deliberately set the product constraint that the model coaches but never ghostwrites: it can give feedback, hints, and scoring, but cannot write the answer for the child.

What I did

In 2025, I designed, built, and shipped WordGyms (wordgyms.com) solo and end to end: problem definition, UX, engineering, launch, and user acquisition. The stack includes Claude / OpenAI / Gemini APIs, prompt engineering and evaluation, MCP, agent workflows, Google OAuth, and Cloudflare.

The key finding

The hard part was not only model quality, but product economics: token cost affects margin, and bad output affects trust. AI lowered the cost of building, but it did not lower the cost of being wrong.

The result

WordGyms is live with real users. Standing on the API customer and developer side gave me a concrete view of what ecosystem partners need from a platform: docs, cost, model performance, integration experience, and commercial viability have to work together.

The problem

A poll shows what respondents intend, but the result depends on who actually turns out. I wanted to isolate how much turnout, undecided voters, and people polls never reach can each change the outcome.

My role

Working with AI, I broke the problem into three layers of calculation (population, turnout by age group, and poll support) and planned the product features and interface. Every number is labeled as observed, derived, or assumed; unverified data stays out of the model, and a separate program recalculates the results independently as a check. I also reviewed the risks under Taiwan's election law, set the site's shutdown window, and tested and shipped the product.

The result

The site is live. Users can switch between three sets of historical turnout, or adjust turnout for men and women across four age groups, and see how the result changes. It is a scenario simulation, not an election forecast.

Roughly 60 confirmed cases worldwide. The real number may be far higher — many sudden infant deaths could be SMARD1 that was never genetically tested.

The problem

An ultra-rare disease has no commercial value, so nobody builds the information site — and the non-profits have no budget. Yet families need answers the moment the diagnosis lands, and almost nothing exists in Chinese.

My role

I used the skills I have to fill the gap the non-profit could not fund.

What I did

I wrote thirty bilingual care articles and handled the content, information architecture, and SEO myself, bringing my marketing background to the work:

• Keyword research: Found the Chinese and English terms families search for at each stage, from diagnosis to post-tracheostomy and home care, and used them to choose topics and titles.
• On-page SEO: Planned every title, description, and URL, with internal links connecting related topics.
• Audience segmentation: Rare-disease and tracheostomy families need different things, so categories and navigation let each group find what they need.
• Bilingual content: Chinese and English versions are maintained separately, so families and clinicians abroad can find them too.

The result

smard1.org is live and fully indexed by Google, reachable by Chinese- and English-speaking families worldwide.

The problem

I am not an engineer, but I wanted to understand how far a commercial operator could move strategy, research, content, product experiments, and delivery forward with AI.

What I did

I built my own AI operating system: collaboration rules, task decomposition, cross-conversation memory, workflows, and automation skills that help move ideas faster toward validation.

The result

The system lets me independently move product prototypes, content architecture, and site delivery, turning AI from a tool list into a manageable execution system.