This is the first website I have ever built. When I started, I did not even know where the difficult parts would be. I only knew that I wanted an English B2B website for an apparel factory—and that I wanted to see how far I could take it with Codex beside me throughout the process.
So yes, this project was partly a website and partly tuition. Instead of paying for a course that would tell me where the problems were, I met the problems one by one.
An encouraging first week—and a quieter second one
On the second day after Cynida went live, I received a real inquiry on WhatsApp. By the end of the first week, the site had brought in roughly eight or nine inquiries.
For a first-time builder, that felt surprisingly good.
Then the second week was quieter.
I do not want to turn one good week into a dramatic growth case study. Maybe the first week was simply lucky. Maybe the traffic source was not yet repeatable. Still, the first week proved that the website could do its job, while the second week gave me the more useful question: can I make those results consistent?
What I actually built
apps/web Next.js 16 storefront -> Vercel
apps/cms Strapi 5 CMS -> AWS Lightsail
packages/contracts Shared validation and upload rules
Strapi media Cloudflare R2 -> media.cynida.com
The monorepo separates the public website, the CMS, and shared rules.
The problems I did not know existed
1. B2B apparel content is not normal e-commerce content
A wholesale buyer does not only ask for a price. They ask about MOQ, fabrics, private-label options, sample approval, measurements, quality control, lead time, and what happens before bulk production.
Instead of putting everything into one giant rich-text field, I modeled reusable Strapi sections such as quickFacts, materialOptions, customizationOptions, processSteps, qualityChecks, caseStudy, relatedResources, and faqs. This was when I realized that content modeling is also product design.
2. An image loading successfully does not mean the media system works
The files are stored on Cloudflare R2, but uploads still pass through Strapi so that CMS relations and alternative text remain attached. I had to trace alt text from the CMS response through normalization and into the final image component. One mapper dropping a field can quietly undo good CMS data.
Caching brought another lesson: an immutable Cache-Control header alone does not guarantee an edge-cache hit. I needed a Cloudflare cache rule, response headers, and a sensible Next.js image-cache TTL—then repeat-request evidence to prove the configuration actually worked.
3. Performance problems often hide in import paths
The homepage originally paid for features before anyone used them. I replaced the immediate YouTube embed with a click-to-load facade and loaded the Quick Inquiry interface only after a real interaction.
“Unused JavaScript” did not mean useless code. It often meant useful code loaded too early. The route bundle report and dependency chain were more helpful than randomly deleting features.
4. A green build is not the same as a working production site
My release process now includes type checks, lint, tests, a production build, a preview deployment, sitemap and media scans, and live acceptance after Vercel reports READY. The CMS, media origin, final www domain, and production logs are checked separately because they can fail separately.
What using Codex really changed
I used Codex throughout: architecture, code, tests, debugging, CMS operations, performance checks, and SEO planning.
For a first-time builder, the biggest benefit was not simply “write this code for me.” It was having a development partner that helped me find the next question before I even knew the correct technical vocabulary.
But Codex was never the proof. The repository, CMS records, HTTP responses, rendered pages, Search Console data, and actual buyer inquiries remained the source of truth. AI can help investigate; it should not invent factory facts or declare success while a deployment is still building.
The next experiment is SEO
My next step is to spend more time on SEO: stronger commercial pages for OEM/ODM, private label, MOQ, sampling, and quotations; useful articles for buyer questions; better internal links; and careful indexing checks.
I want to see how far a website built with Codex as my constant development partner can go—and whether a lucky first week can become a repeatable baseline.
When I build a second independent website for an apparel factory, I hope to do it better. Not because I will suddenly know everything, but because this first site has taught me where the difficult questions are.
That is the tuition I paid. Honestly, it already feels worth it.
Top comments (0)