The US marketing site used to go through Webflow or a China-based front-end team, then the full internal GitLab loop. I moved the build onto my laptop: AI-assisted web coding, a written SOP, one clean branch per release. About ten versions shipped in three weeks.
Taking over website operations was one of the main reasons I was hired. I had run sites on WordPress and Webflow for years, so the operating half was familiar. The new part was the mandate: build it entirely in code ourselves, and move production and release authority to the US side.
The starting position made that harder than it sounds. The US site was built the way the domestic product was built, which is correct for a product and wrong for a marketing site that has to move at campaign speed. And the English site is not one site: Japan and Korea live inside it as subfolders, sharing its skeleton and much of its global configuration, so a careless change on our side surfaces on theirs.
A local web-coded pipeline, a written SOP that acts as long-term memory, a clean-environment release workflow, and a hard guardrail on the remote. The domestic team's role narrowed to deploy and merge, by design.
I stood up the site's Next.js project locally and drive every change through AI-assisted web coding against a real dev server. I self-check each change visually on localhost before it leaves my machine. No front-end engineer, no Webflow.
npm run dev → localhost:3000, hot reload · every change seen before it ships
I codified the whole process into a durable knowledge doc: environment prep, the naming law, i18n region rules, release steps. Every change follows the same mature procedure instead of ad-hoc memory. The naming law makes work traceable at a glance: local folder name = remote branch name, dated to the day.
Folder = branch = feature_x.x_US_<MMDD> · folder, branch and MR map one-to-oneEvery round follows the same path: clean clone of the latest main into a new dated folder, the previous round renamed with a -published-donotuse suffix and kept on disk, edits and self-check on localhost, changelog and version bump, push and announce. Doing that by hand is twenty minutes of setup before any actual work, every single time, and it is exactly the kind of procedure a person eventually starts shortcutting.
So the SOP became an agent workflow with the procedure held in long-term memory. I say one line, that we are preparing an update, and it runs the chain: builds a clean folder, pulls the current main from GitLab, installs and prepares the local environment, applies the naming law, and carries my locally tested changes into the new merge request untouched. Two checks run inside it. One agent verifies that anything I changed in the shared global configuration cannot reach the Japanese or Korean sites. A technical-SEO agent runs new content against our own checklist. Then it uploads to GitLab, writes the changelog, and drafts the channel message.
The last step is the one that keeps it honest over time. The merge request it just pushed becomes the working base for the next round, and the previous folder is archived automatically. My local copy is therefore never more than one version behind main, which is what stops the slow drift that makes a hand-run process rot.
Old rounds are archived and kept · the folder listing is the audit trailOne standing rule sits above the rest: never touch the GitLab remote without explicit sign-off. Local commits are always fine; push, force-push and branch deletion are not mine to do unilaterally. Branches are cut from the latest main, fetched fresh at the start of every round.
node_modules and build output never enter GitLab. Ever.The structural change underneath all of this was separating the global configuration. Japan and Korea sit in subfolders of the English site and inherited a large amount of shared setting, which meant the US moving quickly and those two staying stable were in direct tension. I split the shared layer so their configuration stands on its own. The skeleton and the visual system still line up across all three, deliberately, and now there is defined room inside that for each region to differ.
The reason is sequencing. The US runs as the pioneer: we build a thing, ship it, and find out where it breaks. Japan and Korea then adopt it on their own schedule rather than having it pushed onto them mid-release. When I later built the CMS, that is exactly how it went: stand it up in their environment, hand over an account, and let them adjust within their own global settings for local reading habits and visual conventions, with no risk of their changes landing on anyone else's site. It works in the other direction too, since a configuration we ship here is something they can copy, translate and localize quickly.
A build-time check verifies the shared-route list still matches reality, because a stale entry hands a Japanese or Korean visitor a 404 from our language switcher
The point is repeatability: every change gets made the same reliable way, from a written SOP with a naming law and hard rules. It is an operating model someone else could run.
Never reuse an old folder. Every round starts from a clean clone of main into a new dated folder; the finished one gets archived and kept on disk. No cross-round contamination, no re-shipping merged work.
Every ship carries a semver bump, a dated CHANGELOG entry, and a Slack note with the MR link. The domestic team and I always have an auditable record of what changed and why.
Each rule traces to a real production mismatch. English site means en || other as an allowlist, so only the listed locales get through and jp/kr stay out; pure-English pages scope their static params. Written once, solved forever.
The pipeline carried real weight: 16 competitor comparison pages, Cloudflare Turnstile anti-spam, region-based round-robin meeting routing, and a full headless-CMS integration, with no front-end engineer.
Marketing sites used to mean Webflow or a dedicated front-end team. This is a working proof that web coding replaces both: same-day iteration, full ownership, real complexity. It also made the CMS Rebuild possible next.
Every release is a dated CHANGELOG block with a semver bump, so the cadence is auditable.
16 competitor comparison landing pages · Cloudflare Turnstile anti-spam · region-based round-robin meeting routing · the full Sanity CMS integration (12 content queries, 6 Resource Center sections).
Deploy and merge to production stay with the domestic team. That split is deliberate: I own design and implementation; they own the remote.
React
TypeScript
GitLab
Sanity
Cloudflare Turnstile
Once the US site shipped from my laptop, adding a headless CMS was the natural next move.