Work · Web-Coded US Site · ThinkingAI, 2026

I took over the US site and web-coded it solo

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.

~10 releasesin ~3 weeks, versioned
2.1.9 → 2.5.1Jun 16 → Jul 9
0front-end engineers in the loop
Before

Every change waited on another team

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.

  • Coupled to the domestic pipeline and calendar. Every change waited on a China-based front-end engineer's bandwidth, then traveled the full internal GitLab path: dev, branch, staging, merge.
  • Marketing pages meant Webflow or front-end engineers. A tooling-and-headcount dependency for what were, functionally, content and layout changes.
  • No US-side ownership of the build. No local environment, no documented process, no way to ship a US change same-day without the domestic loop.
The operating model

How a US release gets built now

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.

Module A · Local dev environment

The build lives on my laptop

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
thinkingai.io/en/home-v3
Home v3 hero and dashboard module, built and shipped from the US pipeline
Module B · The SOP

A written SOP so mistakes only happen once

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-one
The naming lawone doc, every rule writtenSOP
folder = branch, dated
English site = en || other, allowlist
All copy lives in messages/en.json
Pre-flight checklist every round
Module C · The snowball workflow

One sentence starts a release round

Every 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 trail
One release roundtriggered by a sentenceagent-run
01 Clean foldernaming law applied
02 Pull latest mainGitLab
03 Env + dependencieslocal build ready
04 Carry my changesinto the new MR
Guard: global settings cannot reach JP/KR
Guard: technical-SEO checklist on new content
05 Upload + changelog+ channel message
06 Rebase the basenew MR becomes next round's start
Module D · The iron rule

No push to the remote without sign-off

One 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.
Guardrailswhat never happensiron rule
No remote push without sign-off
Branches cut from latest main only
node_modules never enters GitLab
Module E · The locale split

Pulling Japan and Korea out of our blast radius

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
thinkingai.io/en/solutions/app
Solutions page built from the shared module library
Three sites, one skeletonshared shape, separated settingsUS pioneers
StructureJP + KR as subfolders of EN
Problemshared global settings couple them
Global config split per region
Skeleton and visual system stay aligned
Room reserved for local customization
AdoptionUS ships → they port on their schedule
Decisions I'd make again

The calls that made it a system

01 Write it down, or it isn't a system

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.

02 Fresh clone per round

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.

03 Release hygiene is not optional

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.

04 i18n rules are scar tissue, codified

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.

05 It scaled to hard work, solo

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.

06 The thesis

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.

Result

Three weeks, on the record

Every release is a dated CHANGELOG block with a semver bump, so the cadence is auditable.

What shipped through it

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).

What I didn't own

Deploy and merge to production stay with the domestic team. That split is deliberate: I own design and implementation; they own the remote.

The version chain · Jun 16 → Jul 9
v2.1.9–2.1.11 · eBook landing + homepage bannerJun 16
v2.2.x · Korea blog + static-export fixes·
v2.4.0 · 16 comparison pages + Turnstile·
v2.5.0 · full Sanity CMS integration·
v2.5.1 · gated-form fix, chain closedJul 9
Next.js React TypeScript GitLab Sanity Cloudflare Turnstile
For every project, he's also a strong partner to help shepherd and support the development of net new deliverables, troubleshooting everything from design resources to securing buy-in from cross-functional global stakeholders, including executives.
Christine M. Porretta Christine M. PorrettaSenior Manager, Intl. Marketing
Gusto
More work

Need a site shipped without a front-end team?

Once the US site shipped from my laptop, adding a headless CMS was the natural next move.