Helping a friend build a cross-border independent website with zero code tools: A developer's pitfalls notes

I am a small backend developer who usually deals with APIs and databases. A while ago, a friend who works in foreign trade approached me and said he wanted to open his own independent website to sell goods. He asked if he could "help me create one". My first reaction was: okay, set up the front-end and back-end, connect payments, and manage the back-end... forget it, he has no technical background, and I can't fix bugs for him every day. Later, I changed my mindset: I used a zero code website building tool to help him with it, and I only checked key nodes. This article should be treated as a build in public note, taking note of the pitfalls you have encountered.
Why didn't you choose to write from scratch
To be honest, building an independent website is not difficult in terms of technology, but the difficulty lies in subsequent maintenance: payment compliance, logistics docking, inventory synchronization, SEO, etc., each of which requires continuous investment. For a small seller, investing energy in product selection and operations is clearly more cost-effective. The value of zero code tools, in other words, is to package the "infrastructure" of website construction, allowing you to focus on the business itself.
When choosing tools, I mainly focus on four points
As a developer, I think tools are quite picky: firstly, the page structure and URL are search engine friendly, otherwise independent website SEO would be impossible to talk about; Secondly, I can modify the copy and product by myself without relying on customer service; Thirdly, receiving payments can be connected to common online channels, and money can be deposited into one's own account; Fourthly, it is best for the backend to be in Chinese so that friends can understand it themselves. After comparison, I ultimately chose Taoify to help him set up the Chinese backend, which is indeed convenient for domestic sellers.
The actual steps to build it up are actually very short
Registering for a store, setting up language and currency, delivering the first batch of products, connecting payment and logistics, and selecting a template, basically everything runs smoothly. What really takes time is not the operation, but the preparation of product information and copy clearly. The following pitfalls are ones I have actually stepped on in practice.
Pit 1: Currency and exchange rates are not manually adjusted to change prices
My friend started using an English website and asked, 'How did the previous Chinese yuan price change to US dollars?'. Later on, I realized that after these tools changed the main currency, the products that had already been listed would be automatically converted according to the latest exchange rate. For example, the original 7799 yuan will become approximately 1091.85 US dollars (subject to exchange rate fluctuations at that time). It's not a bug, it's a mechanism, but beginners are easily startled.
Main currency: CNY ->USD. Product listed price: ¥ 7799=>Automatic conversion to $1091.85 (based on current exchange rate)
Pit 2: Manual payment requires offline confirmation by oneself
After adopting the manual payment method, the backend will not automatically determine that the money has been received. After the customer has paid, you need to confirm receipt offline and manually change the order status to paid. This is counterintuitive for developers - we are used to automatic system flow, but manual backup is necessary here, otherwise it is easy to miss orders. Remember: Key orders will be manually verified by bank/channel notifications.
Pit 3: English website, articles must also be in English
After the store front desk is set to English, articles such as "About Us" and "Return and Exchange Policy" uploaded in the background must also be written in English. Tags are not translated, what is conveyed is displayed. A friend once lazily left a Chinese article, and when the front desk opened it, it was awkward to mix Chinese and English. Conclusion: For multilingual websites, the content is a holistic project and cannot be modified solely based on interface language.
Pit 4: Too many product attributes, synchronization will fail
Later, he wanted to synchronize a batch of goods to another store, but he couldn't push products with more than 100 attributes. This type of restriction is actually written in the document, but it is easy to ignore in practice. My approach is to first streamline the SKU dimension for products with explosive attributes, and then synchronize them, resulting in a significantly higher success rate. Those who work in technology understand that boundary conditions are always more than happy paths.
Several thoughts from a technical perspective
After building it, looking back, the real value of an independent website system is not "the ability to decorate pages", but the ability to pre fabricate dirty and tiring tasks such as currency, payment, logistics, and SEO. For developers, zero code does not mean zero thinking - you still need to understand how page structure is conducive to search, how to ensure mobile experience, and how to close the payment chain. Tools lower the threshold, but they cannot lower your understanding of the logic that should be understood.
Another tip for publishing: If you first publish a version on your own blog and then sync it to dev.to, remember to set canonical_url back to the original site, so that Google's weight still belongs to your original site, and dev.to is responsible for community distribution without delay. This is quite practical for someone like me who wants to keep external links but doesn't want to be judged as spam.
If you are also helping friends or want to build an independent website with zero code, you can search Taoify to learn more, or you can first write a version on your own blog and then synchronize it with Canonical.