I'm going to skip the inspiration and give you the engineering decisions, because that's what I'd want to read.
Context: I'm a solo developer with no technical background. I built NameSoul, an app that generates a Chinese name for a non-Chinese speaker and then treats that name as a starting point — six style paths, a real historical figure behind each name, seal-script and calligraphy rendering, audio on every name, ten languages. No team, no funding, no prior code.
Here are the six decisions that actually determined the outcome.
1. Architecture before features
The first thing I did wasn't writing features. It was mapping the framework: where users enter, what they see first, what they do second, how a name gets generated, what gets displayed afterwards, how the pages connect.
I drew it out on paper, repeatedly, before letting AI turn any of it into something executable. Skeleton first, flesh second. If you start from features, you end up refactoring your data model three times.
2. Learn to talk to AI before you learn to code
My earlier projects all failed, and one big reason was the tooling: AI couldn't follow what I actually meant. I'd say A, it would give me B; I'd explain for ages and it would produce an even more absurd C.
What changed wasn't the models getting smarter. It's that I learned to decompose. Small, unambiguous, verifiable steps. Describe the interface as a contract, not a vibe. The bottleneck was never my typing speed — it was the specificity of my instructions.
3. Treat aesthetics as a separate discipline
AI is genuinely good at logic and structure. It is close to useless at visual design. What it produced was functionally correct and visually wrong in a way that's hard to articulate — nothing obviously broken, but something off.
What worked: referencing. I screenshotted sites whose feel matched what I wanted and said "this direction, this density, this restraint." Concrete references outperform adjectives by an enormous margin.
I also deliberately cut animations and motion polish I couldn't land well. Shipping something solid beat shipping something half-animated.
4. Data is a product decision, not a content task
The single most expensive part of this build was not code. It was building a vetted dataset of historical figures, with accurate, English-friendly notes, verified against real geography — cities, landscapes, historical sites.
Generated bios read smoothly and mean nothing. A curated dataset is dramatically slower, which is exactly why most tools skip it. That asymmetry is the product.
5. Localization is content, not just strings
Ten languages, and the hard part isn't the UI. Every name explanation and every story has to be translated properly — accurate, natural, with some warmth — then proofread, then checked for layout breakage in that language.
If you've only ever localized a UI, multiplying that by full content is a different order of magnitude. Plan for it before launch, not after.
6. Refuse the lazy version, but know which laziness is fatal
Standard advice: ship the crudest usable version, validate demand, then build.
I only took half of it. Demand validation — sure, but the market already proves the category has demand. The crude-shipping half I rejected, because I'm a user too, and I wouldn't download a version I'd be embarrassed to recommend.
That said, I did cut scope aggressively elsewhere. "Refuse the lazy version" isn't "build everything" — it's choosing the two or three places where shortcuts would hollow out the product, and taking the shortcut everywhere else.
What I'd tell the next person
- The architecture diagram is not overhead. It's the thing that keeps you from rewriting yourself into a corner.
- Your prompt quality is your engineering skill right now. Decompose, constrain, verify.
- For visual work, collect references before you ask for anything.
- Budget your time for data and localization. That's where the product actually lives.
The app is live. I'm now going back through it for v1.1 and I'd rather hear what's broken than what's fine.
Source / product: namesoul.net
Top comments (0)