Taipei-based fullstack and forward engineer

I build useful software.

Some clients come with a full spec and Figma screens. I like building that work. Other times, the idea is only half formed. I can turn it into a spec, ask what each role needs, and catch problems before they turn into expensive rules.

Talk through a project

How I approach it

The edge cases show up early if you ask the right questions.

A request can sound simple until there are several roles, different rules for each one, and an admin view sitting behind the customer-facing one. I like getting into that before the work piles up.

I think about the data model and the person at the other end of the screen. A decision that keeps the database tidy can still give users more work. A polished mockup can still hide a process that will break the first time an exception appears.

A good place to start

Where are you starting?

Bring the requirements, mockups, a Figma file, or a list of features. I will build the feature, pressure-test the details, and flag choices that will get costly later.

What I build

Operational systems

Where it helps: When scheduling, records, and day-to-day staff work need to live in one system with the right context for each role.
What I build: I turn requirements and rules into clear specs, then build the frontend, backend, and test coverage that keeps the workflow reliable.

AI-assisted review

Where it helps: When a team needs to make decisions from a large amount of information without losing the human judgment behind them.
What I build: I design and build data flows, review interfaces, and human-in-the-loop AI features that provide context instead of hiding it.

Document-driven automation

Where it helps: When long documents and repetitive form work slow people down, but the final approval still needs a human eye.
What I build: I build prototypes and production-ready foundations that combine uploaded material, structured state, and AI-assisted drafting.

Working style

Bring me a clear brief, or a problem that still needs one.

When the brief is clearI build it carefully, write the pieces that still need deciding, and flag choices that will hurt later.

When it is notI help map the work, turn it into a spec, and decide what the first version needs to do.

All the way throughI pay attention to the implementation and the experience. Users have to live with both.

Before it shipsI write unit and end-to-end tests around the paths that matter, then use them to keep later changes from breaking the work.

Tools I reach for

TypeScript
Next.js
React
PostgreSQL
tRPC
Drizzle
Vitest
Playwright

Writing

Outside of software, I write reported features.

Timid MagazineRead my writing