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?
Top comments (0)