DEV Community

Cover image for From Writing Requirements Docs to Shipping My First Solo Product
QUN ZOU
QUN ZOU

Posted on

From Writing Requirements Docs to Shipping My First Solo Product

For most of my career, I was the person around the code.

I wrote requirements documents. I planned sprints. I argued about pricing models. I sat in rooms with engineers and said things like "can we ship by Friday?" I understood software deeply — but I'd never built an entire product by myself, from idea to deployment.

This year, I decided to change that.

The result: chinanam.online — a Chinese name generator for foreigners. It's live, it takes real payments, and I built every line of it myself.

Here's what that actually looked like.
Why This Project
I've always been fascinated by how foreigners get Chinese names. Most tools online just phonetically map English sounds to random characters — which produces names that native speakers find odd or meaningless.

I thought: someone should build this properly. Then I realized — that someone could be me.

It was small enough to ship alone, but complex enough to teach me something. Good enough.
What It Does
You enter your English name, birthday, gender, and a style preference. The generator produces:
Authentic Chinese characters — selected for meaning and phonetic harmony, not just transliteration
Pinyin pronunciation guide
Character meanings — so you understand what your name actually says
Chinese zodiac sign from your birthday
A personalized lucky phrase drawn from your name's characters
A downloadable "Lucky Card" — a decorated digital card with your name and zodiac animal ($1 via PayPal)
The Parts That Humbled Me
Coming from a planning background, I thought I understood what "building software" involved. I did not.

  1. There's no one to hand the ticket to When I wrote requirements, someone else figured out the hard parts. Now I was the someone else. Every ambiguous edge case, every API quirk, every "how do we actually do this?" — that was mine.

The Canvas API was a good example. I wanted the Lucky Card to render instantly, client-side, with no server involved. That meant embedding all artwork as base64 in a TypeScript constants file and drawing everything programmatically:
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

const bg = new Image();
bg.src = CARD_BACKGROUNDS[style]; // base64, loads instantly
ctx.drawImage(bg, 0, 0, 1200, 800);
// then zodiac animal, name text, lucky phrase...

It took me three days to get the text rendering right across different screen densities. Three days on text rendering. I'd never budgeted for that in a requirements doc.

  1. Decisions don't wait for a meeting Every day brought 10 decisions I'd normally escalate. Do we support 2-character names, 3-character, or both? What happens if the zodiac year lookup is off by one? Is $1 the right price?

I had to just... decide. And live with it. That was uncomfortable at first, then liberating.

  1. Shipping is the hardest part of the spec to write I've written "Definition of Done" criteria hundreds of times. I've never felt the weight of them until I was the one deciding whether something was done.

Deploying to Cloudflare Pages with @cloudflare/next-on-pages was straightforward once I understood the edge runtime constraints. But deciding it was ready to show people? That took longer than the deployment itself.
The Stack (and Why)
Next.js 15 — I knew React from reading PRDs for React projects. Close enough to start.
Tailwind CSS v4 — Fast to iterate without a designer (me).
Cloudflare Pages — Free tier, global CDN, deploys in under 2 minutes.
PayPal JS SDK — One-time payments, no subscription complexity, buyers don't need an account.
Canvas API — Client-side card rendering, zero server cost.

My entire deploy command

npx @cloudflare/next-on-pages

wrangler pages deploy .vercel/output/static --project-name chinese-name-v2

What I Got Right (By Accident)

Going client-side for everything I could. No backend means no server to maintain, no database to babysit. Name generation and card rendering are 100% in the browser. The only server interaction is the PayPal payment flow.

Keeping the MVP tiny. I resisted every urge to add user accounts, name history, social sharing, bulk generation. Ship first. Add later.

What I'd Do Differently

Bundle size. Base64-encoding all images keeps things self-contained but bloated the homepage to ~970KB. I'd use Cloudflare R2 for assets next time.

Mobile testing earlier. Canvas pixel ratio differences between iOS and Android bit me late in the process. A requirements doc never would have caught that either — but I would have asked an engineer about it.

Where I Am Now

The site is live. It gets real traffic. Someone paid $1 for a Lucky Card last week, and I felt something I'd never felt before in my career: the specific satisfaction of someone paying for a thing you made entirely yourself.
I'm not a "real developer" by most definitions. I still think in requirements and user stories. But I'm learning that those instincts — thinking about the user, questioning assumptions, caring about the whole product — are actually useful when you're the only one in the room.
👉 https://chinanam.online

If you've made a similar transition — from PM, analyst, designer, or any non-engineering role into solo building — I'd genuinely love to hear how you approached it.

Built with Next.js 15, Tailwind CSS v4, Cloudflare Pages, Canvas API, and PayPal JS SDK.

Top comments (0)