DEV Community: MinJian

I Built a Six-Language B2B Site With AI. Checking the Result Was the Hard Part.

MinJian — Thu, 05 Nov 2026 03:31:37 +0000

Disclosure: this article was written with AI assistance and checked against the project files and recorded implementation work. I am the website owner; this is a project-owner retrospective.

I used AI assistance to build a website for a small B2B mold-supply business. The stack is React and Vite, with prerendered public pages and a Cloudflare Worker backend. The site now has English, Simplified Chinese, Thai, Vietnamese, Arabic, and Korean versions.

The work that needed the most attention happened after a feature first appeared to be finished: translated states still contained English, images disappeared from a section, navigation spacing looked wrong, and an analytics integration was collecting data without a project card appearing in its dashboard.

The site is EXACTMEC, used here as the concrete case behind these lessons. Its purpose is to help visitors understand a mold project and make an inquiry. This article covers the website implementation, not manufacturing advice.

Illustrative visual from the project website, not a photograph of a delivered customer project.

1. A translation dictionary is only the beginning

The first Chinese version exposed an easy mistake: translating the main page copy while missing text generated by application states.

The customer area still showed labels such as “Need information” and an English empty-state heading. Another page retained “We do.” Those strings were short, easy to overlook, and visible during ordinary use.

The useful unit of review became a route × state × language combination:

Area	States worth checking
Navigation	Closed, expanded, narrow-screen menu
Inquiry list	Empty, populated, filtered, loading, error
Inquiry detail	Missing information, saved information, update feedback
Sign-in	Initial form, code entry, expired or invalid code

Dynamic messages also need translation before inserting their changing values. Translating a static list of complete sentences cannot reliably cover a countdown or a heading with an appended status.

Arabic added another dimension: right-to-left layout. Logical spacing properties helped, but account controls, arrows, numbers, and language switching still needed actual inspection. A translated string did not prove that the surrounding layout worked.

2. “No overlap” is a lower bar than “looks right”

The navigation went through several revisions. At one point it passed checks for horizontal overflow, yet the menu still looked too spread out.

The cause was a mismatch between the layout rule and the intended appearance. Fixed gaps inside the menu were combined with automatic distribution of spare space elsewhere in the header. Changing one gap did not control the entire row.

The eventual desktop direction was specific: keep the logo at the left, push the continuous sequence of menu and account controls toward the right, slightly reduce the text size, and increase its weight.

Here is a simplified version of that rule, without the project's selector and breakpoint overrides:

.header-inner {
  display: flex;
  align-items: center;
  gap: 20px;
}

.wordmark {
  margin-inline-end: auto;
}

.main-navigation {
  display: flex;
  flex: 0 0 auto;
  gap: 24px;
  font-size: 15px;
  font-weight: 600;
}

The important part was deciding where extra space should go. The auto margin puts it after the logo; it does not stretch the distances between the five content categories.

The final desktop check covered six languages at four widths. That gave evidence about overlap and overflow. The visual decision still came from looking at the rendered header, including the longer English and Thai labels.

3. Illustrations need a clear boundary from real engineering files

A generic 3D rendering looked attractive, but did not explain what product information a visitor should prepare. The examples became more useful when they showed dimensions, units, and revision information.

AI-generated reference example. Not a customer drawing or a drawing approved for manufacturing.

AI-generated reference example. The labels explain what information a reference might contain; the image does not establish engineering correctness.

That distinction matters in the interface. A parameter table drawn into an image is not a validated CAD model. These examples need explicit labeling, and a visitor's actual project files need their own review.

The website also provides enlarged views, a fit-to-screen option, and scrolling at original size. Those interactions matter more than simply placing a detailed image inside a small card.

For localization, image text deserves its own inventory. Translating the caption does not translate words embedded in the image.

4. Measure the action the business actually needs

A conventional sales dashboard was not the right starting point for this site. The useful questions were simpler:

How many daily visitors were counted?
Which countries and cities were represented?
Did someone click WhatsApp or submit an inquiry?
Which verified account was observed when a signed-in action occurred?

The labels need to stay precise. A WhatsApp click does not prove that a message was sent. A daily deduplicated network IP is not a verified person: multiple people can share a connection, and an address can change. Location is an estimate.

Keeping those distinctions in the dashboard prevents a clean-looking number from promising more than the measurement supports.

5. SDK installation and dashboard setup are separate acceptance checks

Ahrefs was the clearest example. Its setup screen reported that visitors were already being counted. However, the website still had no card in the workspace's project list.

The remaining work was in the account workflow: finish creating the project, verify ownership through a public DNS TXT record, and complete the final settings. After that, the Web Analytics card appeared and showed existing data. The website's tracking code did not need to be replaced.

That experience changed the acceptance checklist:

Is the expected integration present in the deployed build?
Does it respect the site's measurement choice and route boundaries?
Does the provider report receiving data?
Is the intended project actually available in the intended workspace?

A script tag, a successful request, and a visible dashboard are different pieces of evidence.

What I would carry into the next language release

AI assistance made implementation faster, but it did not make “finished” a reliable visual or operational judgment. The project still needed concrete checks:

Review industry terminology and proper company names separately from general prose.
Exercise dynamic states, not just the homepage.
Inspect images, captions, and embedded image text.
Check long labels, narrow screens, and right-to-left layouts.
Keep business events distinct from outcomes they cannot prove.
Finish provider-side setup before calling an integration complete.

For this project, a useful acceptance question became: Can I point to the rendered state or provider result that proves this particular part works?

Building Paper Adventure: a printable game app with React, Cloudflare, and Stripe

MinJian — Mon, 26 Oct 2026 01:42:55 +0000

I'm building Paper Adventure Workshop, a web app for printable story adventures for families and classrooms. An adult downloads the game, prepares the paper materials, and guides children through five connected checkpoints.

There are two product paths: ready-made games with existing files, and AI-assisted custom adventures built around a buyer's idea. Both need a Player Pack and a separate Host or Teacher Guide, with A4 and US Letter options.

The live homepage introduces the print-first experience: a story, connected paper clues, and a separate adult guide.

This case study documents the engineering decisions behind turning generated content into a downloadable product.

The stack

React and Vite for the interface, with pre-rendered public pages.
Cloudflare Workers for the API and site delivery.
D1 for orders, saved generation progress, entitlements, and support records.
Private R2 storage for purchased files and generated covers.
Cloudflare Queues for background generation work.
Stripe Checkout and webhooks for payments.

The public catalogue and the private purchase flow have different jobs. Visitors should be able to explore a story before signing in. Purchased files need server-side ownership and access checks.

What the product looks like

A ready-made story page

The Dinosaur Home page gives the story context and group information before the purchase flow. The artwork introduces the world; the printable activities are explained further down the page.

A separate custom adventure flow

The custom path starts with an idea and group preferences. It makes the sequence explicit: personal plan after payment, then PDFs after the adult approves the plan. This capture shows the public introduction and step navigation.

1. Treat payment and delivery as separate states

A successful redirect from a checkout page is not enough to unlock a file. The backend needs to confirm the payment and associate it with the correct order.

After that, a ready-made game and a custom game take different paths:

Ready-made:
confirmed payment -> entitlement -> existing downloadable files

Custom:
confirmed payment -> saved plan -> adult approval
                  -> background generation -> checked PDFs -> downloads

That distinction also matters in the interface. "Payment confirmed," "Generating," and "Files ready" should not be interchangeable labels. If generation stops, the paid order needs to stay visible with an explanation and a support path.

2. Save progress before moving to the next generation step

A single long-running request is an awkward place to build a complete game. If the final step fails, restarting everything can repeat work and spend more provider credit.

The custom flow saves progress between generation steps. Background jobs resume from saved work, and retries have bounded budgets. A queue message advances a generation step instead of asking the browser to wait for the whole process.

One particularly useful boundary is between checked game content and PDF rendering. A rendering failure should be able to reuse saved content rather than request another story.

The principle applies beyond games: save expensive, validated intermediate results before starting the next fallible operation.

3. A generated story still needs a game contract

A printable adventure needs more than an interesting premise. Players need materials they can handle, instructions they can follow, and clues that support an answer.

The implementation uses structured game data, deterministic puzzle checks, and paired PDF checks around the generated narrative. The player materials and adult answers have to agree. A story sentence should not imply that a clue exists when it was never printed.

This also affects product design. Home and Classroom editions have distinct stories and adult guidance, rather than being the same PDF with a different label.

Automated checks help catch contradictions and layout problems. Testing a printed game with real people is a separate part of evaluating its play quality.

4. Keep optional cover generation separate from the purchased files

The game cover and the game PDFs are separate outputs. A failed cover request should not remove access to a completed game.

This separation became especially concrete during development: failed historical cover requests left some library cards without illustrations even though their PDFs were available. Fixing a provider integration does not automatically repair every old record.

The lesson was to keep optional asset status explicit and handle historical recovery deliberately. Repeated refreshes should not keep submitting new paid image requests.

5. Design the download and support experience together

Once files are ready, the page should make the next action obvious:

A complete ZIP as the main download.
One paper-size selection for the matching files.
Separate Player Pack and adult-guide downloads.
A compact receipt and clear online access expiry.
Order-linked help without asking the buyer to retype an order reference.

Support is part of delivery. Recording a request, notifying the operator, reviewing a refund request, and actually completing a refund are different events. The interface should describe the event that has happened.

What I'd like feedback on

For developers who have shipped generated documents or other asynchronous digital products: where do you draw the boundary between automatic recovery and an explicit user action? I'd also welcome feedback on making a print-first product understandable in a web interface.

Disclosure: Paper Adventure is my project. An AI agent prepared this article from the project's implementation and development notes at my request.

Building a 10-language B2B site: the localization bugs our code checks missed

MinJian — Sat, 24 Oct 2026 02:48:48 +0000

We built Custom Sign Forge as a B2B website for custom commercial signage. The public site has ten language versions and six product families. The implementation uses Astro and React on Cloudflare Workers, with D1 for application data and private R2 storage for uploads.

The interesting part was not adding a language switcher. It was keeping the product pages, imagery, enquiry flow, and search metadata coherent as the site grew. Here are the lessons that would carry into another multilingual build.

1. Keep locale routing explicit

English uses the original URLs; other languages have prefixes such as /zh/, /pt-br/, and /ar/. We do not redirect visitors based on IP address or browser language. A visitor can choose a language and share a stable URL.

One routing module owns the conversion between equivalent pages. Product slugs and internal field codes remain stable. A language change updates the visible text and labels, but it does not rewrite customer-entered text or change the underlying enquiry record. This separation matters when a customer starts an enquiry in one language and returns in another.

2. Translation coverage is a UI problem, too

A dictionary can be complete while the interface is not. We found untranslated navigation text in the Arabic account menu. We also caught a wrong flag next to a language label. Neither would be found by a simple check that counts translated strings.

We now treat the header, account menu, validation messages, upload controls, policy links, and enquiry summary as part of every locale's acceptance criteria. For Arabic, the check also includes RTL layout, icon direction, mixed Latin/Arabic text, and alignment. We keep the actual language name visible because a flag alone is a poor identifier for a language used in multiple countries.

Arabic homepage screenshot: the navigation and hero follow a right-to-left layout. The storefront scene is a labelled design concept.

3. Image composition needs its own content model

Our first Chinese product layouts exposed a familiar problem: applying the same fixed image box and object-fit: cover rule to every asset. Some signage photos are wide; others are close-ups or portrait compositions. A uniform crop can remove the sign itself. Switching every image to contain is not enough either; it may create awkward empty bands.

We changed the gallery approach instead. Each image gets a frame appropriate to its purpose and source aspect ratio. Product design concepts use consistent 4:3 compositions; wide construction photographs keep their native proportions. On mobile, the grid becomes a single column, and the enquiry action stays easy to reach before a long image sequence. We also label generated design concepts as concepts rather than implying that they are photographs of completed customer projects.

Chinese product-page screenshot: equal landscape frames make the design concepts comparable without cropping away the signs. These are design inspirations, not completed customer installations.

The reusable rule: decide whether an image is a hero, a comparison, a detail, or evidence before choosing its crop behavior. Inspect the actual focal point at desktop and phone widths.

4. Search metadata is part of localization

Each public locale page renders its own HTML language, title, description, H1, and canonical URL. Equivalent pages carry reciprocal hreflang links, and the sitemap includes locale alternates. Private account and admin paths are kept out of the public index. This prevents the common failure where a translated page looks localized but still advertises the English canonical URL.

A sitemap submission is only a discovery signal, not a guarantee of indexing. We still check the live HTML, response status, robots rules, and Search Console reports after deployment.

5. Share the business flow; localize its presentation

The quote form uses shared sessions, CSRF protection, stable field codes, and private attachments across languages. The submitted locale is stored with the enquiry, while the original customer wording remains untouched. A language-only retry reuses the existing idempotency key so it does not create a duplicate enquiry.

This gave us one set of business rules to test, with a separate presentation layer for each language. It also exposed the places that need real browser testing: sign-in return paths, draft restoration, optional uploads, validation, and account summaries.

6. Test the rendered pages, not just the translation files

For each new locale, our release checklist now combines automated checks with a small visual matrix: homepage, product index, all six product detail pages, account menu, quote flow, and mobile header. We inspect long headings, contrast, missing images, focal-point crops, and language leaks. Arabic adds RTL-specific checks.

The broader lesson is that internationalization is a product quality discipline. A locale is ready when its content, layout, interaction, and search signals work together—not when the JSON file is filled.

Disclosure: This article was generated by an AI agent from the project's source and implementation notes. Factual implementation details were checked against those materials. It is a technical case study, not a claim that AI-generated concept images are completed customer installations.

Building FitRooted: a fitness knowledge library organized around questions

MinJian — Sun, 04 Oct 2026 02:40:42 +0000

A product can have useful content and still make it difficult to know where to start. That’s the design problem I’m working on with FitRooted.
It’s a fitness and fat-loss knowledge library, with a complementary Chinese wellness section. The core is the knowledge, not a chatbot.

Website: https://fitrooted.com/

The challenge is presenting those parts without making the homepage look like a directory of everything the site can do.

Questions first, categories second
The library uses everyday questions as entry points: starting strength training, fitting exercise into two days a week, or restarting after a break.
My working assumption is that a specific question can be easier to recognize than a broad category. Someone may not know which training topic they need, but they can recognize their own situation.
Categories still have a job. They give someone who wants to browse a map of the content. I don’t want a question-first design to become search-only navigation.
The trade-off is repetition. Several questions can lead to almost the same explanation. A useful review question for this kind of library is: does each new page address a different situation, or just rephrase an existing headline?

Put the source within reach of the answer
One published example asks: “How should I combine strength training and cardio?”
You can see the page here:
https://fitrooted.com/answers/strength-and-cardio

The page presents a short answer and names Physical Activity Guidelines for Americans as a supporting source.
That doesn’t make the answer automatically correct. A citation still needs to support the claim being made. But it gives the reader something specific to inspect rather than a generic promise that the content is trustworthy.
The interface trade-off is how much to show immediately. Too little context makes the answer hard to assess; too much can overwhelm someone who only needs a starting point.
My design goal is a readable short answer with an obvious route to its supporting material, rather than forcing the reader to choose between simplicity and transparency.

Keep the main subject clear
The Chinese wellness section covers movement, everyday routines, food and seasonal ideas. It sits alongside the fitness and fat-loss library, rather than replacing it.
That section is here:
https://fitrooted.com/knowledge/chinese-wellness

This distinction matters to the navigation. Someone arriving with a strength-training question should immediately understand where to go. Someone exploring Chinese wellness should be able to follow that path without confusing lifestyle content with medical advice.
AI has a supporting role, too. I want it to help people explore knowledge, not make the whole product feel like a blank chat box. The library should still make sense to someone who never opens the AI feature.

The navigation question I’d like feedback on
For this kind of content-heavy product, would you make common questions, topic categories, or a short guided starting point the most prominent entry on the homepage?
I’m particularly interested in the trade-off between helping a first-time visitor and keeping navigation efficient for someone returning to a specific answer.
I’d test that by giving people one concrete question and watching where they look first, rather than assuming a cleaner-looking homepage is automatically easier to use.

I Built HSKKit: A Different Way to Learn HSK 3.0 Vocabulary

MinJian — Mon, 14 Sep 2026 02:43:33 +0000

Learning Chinese vocabulary looks simple at first.

You get a word list, memorize the words, and move on to the next level.

But while looking at how HSK learners actually study, I noticed a problem: having access to thousands of words is not the same as having a clear learning path.

A learner might have a vocabulary list, a flashcard app, a dictionary, a listening resource, and a mock test — but these tools often exist separately.

That was the problem I wanted to explore when building HSKKit.

The problem I wanted to solve

The new HSK 3.0 framework introduces a much larger vocabulary system across Levels 1–9.

For someone preparing for HSK, several questions appear very quickly:

What level should I start from?
Which vocabulary should I learn today?
When should I review a word?
How do I know which words I keep getting wrong?
How can I combine vocabulary and listening practice?
How do I avoid repeatedly studying words I already know?

A static vocabulary list doesn't really solve these problems.

So instead of building another directory of HSK words, I wanted to experiment with a more connected study workflow.

What I built

The result is HSKKit, a web-based learning platform organized around published HSK 3.0 vocabulary.

The current workflow connects several parts of studying:

Placement → Vocabulary → Listening → Practice → Review → Mistakes

Learners can first find a practical starting level and then move into vocabulary organized by HSK level or topic.

The platform currently includes HSK 3.0 Levels 1–9, with Chinese characters, pinyin, English meanings, listening practice where audio is available, and a searchable dictionary.

The interesting part: deciding what to review

One of the biggest design decisions was not simply what content to show, but when to bring content back.

If someone already remembers a word easily, showing it again tomorrow isn't very useful.

If they repeatedly forget another word, that word deserves more attention.

That's why I added a spaced-repetition-style review flow.

Instead of treating every vocabulary item equally, the study experience tries to bring words back when they actually need another review.

Mistakes are also kept in the learning loop rather than disappearing after a practice session.

Learning by situations instead of only levels

Another thing I wanted to experiment with was topic-based learning.

HSK levels are useful for exam preparation, but people don't experience a language as "Level 1 words" and "Level 2 words" in real life.

They experience situations.

For example:

getting ready in the morning
staying at a hotel
doing household chores
making plans
travelling
ordering food

So HSKKit also groups vocabulary into practical situations while keeping the words connected to their published HSK levels.

This creates two possible paths:

Exam-oriented: learn by HSK level.

Usage-oriented: learn vocabulary through real-world topics.

AI without replacing the source material

I also wanted to be careful about how AI is used.

For a language-learning product, simply asking an LLM to generate unlimited vocabulary or definitions introduces an obvious problem: the learner may not know whether the generated material actually belongs to the HSK standard.

So the core vocabulary catalog is source-controlled rather than freely generated by AI.

AI-assisted features can help around the learning experience, while the underlying HSK vocabulary remains tied to the published dataset.

This separation became an important product decision:

Use AI to improve the learning experience, not to invent the curriculum.

What I learned while building it

The biggest lesson for me was that an educational product doesn't necessarily need more content.

Sometimes it needs better connections between existing content.

A vocabulary database is useful.

A listening tool is useful.

A flashcard system is useful.

A placement test is useful.

But connecting them into one continuous path can make the product much easier to understand:

Where am I? → What should I learn? → Can I recognize it? → Can I hear it? → When should I review it?

That's the direction I'm continuing to explore.

I built the project here:

HSKKit: https://hskkit.com/

I'd especially be interested in feedback from developers who have worked on EdTech, language-learning products, spaced repetition, or AI-assisted learning.

What would you improve about this learning flow?

I Built an AI Career Test That Gives You Career Hypotheses, Not a Career Verdict

MinJian — Sat, 05 Sep 2026 03:42:39 +0000

Career questions have become harder to answer in the AI era.
It is no longer only about what someone is good at, what job title to pursue, or which skills to learn next. People are also asking which parts of their work AI can accelerate, whether a direction genuinely fits them or is simply popular online, and how they can test a career path before spending months on courses or making a major switch.
That is why I built AI Career Test, a free, roughly ten minute career self exploration tool. It is designed to turn personal signals into career directions to investigate and practical next steps.
It is not a professional assessment, career advice service, or a machine that can tell someone what job they should do.

The problem with a single career verdict
A result such as You should become a product designer can sound decisive, but it hides too much uncertainty.
A useful career exploration tool should look beyond a single personality label. It should help someone examine the combination of interests and work values, strengths and preferred ways of working, personality and collaboration signals, current skills, and AI era preferences such as learning, judgment, privacy awareness, and adaptability.
Even then, the result should be treated as a working hypothesis, not a prediction.
A test cannot know someone’s finances, location, qualifications, health, responsibilities, or the real hiring conditions in their market. It can help organize the signals already present and turn them into questions worth testing.

From assessment signals to an action plan
The free assessment contains 40 questions and uses a simple response scale rather than asking users to write a long biography.
The goal is not to label people. It is to help them reflect on patterns such as the kinds of problems they enjoy, their preferred work environment, whether they gain energy from analysis, creativity, collaboration, or execution, and what role AI should play in their work.
The result should lead to a better question than What is my perfect career. A more useful question is Which career directions are credible enough for me to validate next.

What a complete report should explain
The sample report on the site is intentionally fictional and marked as illustrative data. It demonstrates the kind of information I think a career report should provide.
A working hypothesis in plain language, including the strongest patterns and the uncertainty that remains.
Evidence linked career matches, with an explanation of why a path may fit rather than only a ranked list of job titles.
Trade offs and risks, showing what to test rather than only what looks attractive.
Skills and AI readiness, including learning, verification of AI output, privacy awareness, and judgment.
A 30, 60, and 90 day roadmap that creates momentum through small experiments, proof of work, and reflection.

Why test before you commit matters
A career match is more useful when it comes with a validation exercise.
Instead of telling someone to immediately pivot into a new field, a better next step could be to interview someone already doing that work, compare what the role involves during a normal week, build a small project resembling an important task in the role, collect evidence for one skill gap before buying another course, or rewrite one resume bullet around a real outcome instead of a generic responsibility.
The goal is to reduce blind commitment. Career exploration should move from vague self description to observable evidence. What work do I actually enjoy doing repeatedly. What can I show. What assumptions about a role have I tested.

Building around explainability
I wanted the product to make its limits visible. The site states that results are for self exploration, not professional assessment or career advice. The sample report also distinguishes between a recommendation, an uncertainty, and a next experiment.
AI can make reflection faster. It can help organize signals and reveal options people may not have considered. But it should not replace a person’s lived context, responsibility, or decision making.
The best outcome is not that the AI chose my career. The better outcome is that I have a clearer direction, understand why it may fit, and know the next small experiment to run.

Try the free assessment
If you want to try the free assessment or inspect the illustrative report structure, visit https://aicareertest.work/
I would also love to hear from developers and career changers. What would make you trust an AI assisted career exploration tool, and what would immediately make you distrust one?