AI-Native Senior Product Designer · Designed and shipped solo · Financial Finesse · 2026

I designed and shipped the AI studio that took our content library into 28 locales — solo, in four weeks, with the architecture, the tradeoffs, and what broke written down.

Financial Finesse's people were quietly using their own unregulated AI subscriptions to write company content. I built one tool, grounded in our voice pillars and compliance rules, that replaced all of it, then turned it into a localization engine that rewrites an article for any market. TypeScript and Lit, a Cloudflare Worker, the Anthropic API, 221 tests. In production today.

8,118
Localized variants in production, 28 locales
3,512
Pieces localized in one four-day run
25
Locales with published or approved content
Live demo — localizing an article (2× speed)
At a glance

The team was writing company content on scattered, unregulated AI subscriptions, and the company had decided to go global. I designed and shipped Global Content Studio: one grounded AI studio with an 8-step localization pipeline, Atlas, and a human localizer between the model and the member. Solo, first commit to launch QA in four weeks. It holds 8,118 localized variants across 28 locales today; one four-day run localized 3,512 pieces and brought ten locales live.

Role
AI-Native Senior Product Designer · designed & built solo
Timeline
First commit Apr 28, 2026 · launch QA May 22 · first ten-locale run Jun 1–4
Team
Solo (493 of 524 commits); one engineer, 20 commits
Scope
Strategy · UX/UI · Grounding and guardrails · Build · Pipeline
My Role

Strategy, design, grounding, and the build — end to end

Strategy

Spotted the risk in the team's scattered, unregulated AI and defined the product — then saw where the company was headed and pivoted it from a writing tool into a localization engine.

Product design

UX, UI, and the authoring workflow — from a single prompt to a compliance-checked, localized asset, one country at a time or in bulk.

Grounding and guardrails

Wrote the voice pillars, compliance rules, and the per-country wiki the model is grounded on — the source-of-truth layer that keeps a general model inside Financial Finesse's facts. Nothing is trained; everything is prompted, retrieved, and checked.

Build — coded by me

The whole app: the TypeScript and Lit front end, the Cloudflare Worker and its Azure Blob client, the pipeline, the CLI workflow, and 221 Vitest tests. 493 of the repo's 524 commits are mine. First working version in about two weeks; launch QA at week four.

Built by engineering

Nothing in the Studio itself. One engineer contributed 20 commits of integration and review. The localizer review console that reads the Studio's output lives in a sibling repo, where I also ship the Python review API and the React console.

Ship

Designed Atlas and the human-in-the-loop review that lets it run at scale. In production: 8,118 localized variants across 28 locales, 4,154 published, 975 approved, 2,772 in review.

The content library — every piece across content types and locales, with status, audience filter, and localization queue
The Problem

Everyone had an AI tool. None of them sounded like us — and then we decided to go global.

Last year, AI went from novelty to daily habit across the company. Most of the team reached for it to write and edit content — each on their own paid subscription, each with no guardrails. The output was fast, but it didn't sound like Financial Finesse, and we had no way to regulate what any of it said. In a business built on financial trust, that's a real risk.

Then the company set its sights on every market. Localizing our library the traditional way would have meant hiring one in-country specialist per market, then having each of them translate, culturally adapt, and QA every single item — slow, expensive, and impossible to scale.

592 English source pieces × 25 target markets ≈ 14,800 localized outputs to produce — and 25 in-country localizers to recruit and manage.
Financial advice changes by country: tax structures, retirement systems, and regulations are all different.
Tone, customs, religion, and ways of life all shape how money is discussed — a literal translation would be technically correct and completely wrong for the reader.
Getting it wrong in a financial context isn't a typo — it's a liability.
Localize QA — 1,816 pieces awaiting review across 26 locales, with per-locale need-review, approved, and flagged counts
Localize QA1,816 pieces awaiting review across 26 locales
The Solution

From a writing tool to a localization engine

I pivoted the studio from writing content to writing and localizing it. It can take an existing article or write a brand-new one, then adapt it for any country in the world — one at a time or in bulk. Not a translation. A rewrite in the correct tone, financial structure, customs, and culture.

01

Grounded, not trained. Every request carries Financial Finesse's voice pillars, compliance rules, and content schemas, and runs through the Anthropic API behind a Worker. Drafts come back sounding like us because the prompt and the retrieved facts say so, not because a model was fine-tuned.

02

A per-locale wiki as the source of truth. For each market, a curated knowledge base the model reads from instead of the open web: the tax authority, the retirement system, the programs a reader can actually use. That is what makes a localization accurate instead of a guess.

03

True localization, checked, not just scored. Each output is rewritten for tone, financial structure, customs, and culture. The model rates its own confidence per pass and tags every local fact high, medium, or low; anything below high is flagged for the reviewer. Then an independent verify pass reads the draft the way a native reader would and returns pass or fail with typed problems, and a redo loop runs before a human ever sees it. The score is a routing signal. The verify pass and the localizer are the gate.

04

Human in the loop, always. Nothing auto-publishes; the policy is in the code. Every variant lands in review, a localizer approves it, and approved articles are never overwritten by a later run unless someone asks.

The authoring studio — prompt sidebar with content type, locale, and audience; the editor drafting a quiz in Korean; and the accuracy-check panel flagging high-stakes claims for review
Architecture

Four parts, one secret-holder

The browser never sees a key. A static TypeScript and Lit app on Vercel talks to one Cloudflare Worker, and the Worker is the only thing that holds the Anthropic key and the Azure connection string. It proxies model calls and exposes a small REST surface over Azure Blob Storage, where every entry, localized variant, per-locale wiki page, and QA flag lives. Bulk localization runs from a CLI workflow that fans out one model call per stage per article and writes back through the same Worker, so the app and the pipeline share one source of truth and one write path.

Global Content Studio architecture The Studio app in the browser and the CLI localization workflow both call one Cloudflare Worker. The Worker proxies the Anthropic API and reads and writes Azure Blob Storage, which holds entries, localized variants, the per-locale wiki, and QA flags. Studio app · browserTypeScript + Lit + Vite, on VercelDexie for local job state · 221 Vitest tests CLI localization workflowgate → research → draft → verify → saveone Sonnet call per stage, 5 workers per locale Cloudflare Workerholds the secrets · CORS allowlistbearer gate on writes · save queue Anthropic APIclaude-sonnet-4-6 Azure Blob Storageentries · variants · wiki · flagssource of truth, nothing auto-publishes /v1/messages · /api/*bearer tokenproxied, key never client-sideSharedKey REST client
The Worker's Azure client is hand-written REST with SharedKey HMAC, because the Azure SDK cannot run in Workers. Reads and writes from the app and the CLI go through the same routes.
The Pipeline

Inside Atlas — what happens to every article

Every article moves through Atlas, an 8-step pipeline — whether it's brand-new or being localized. It starts with a fit check that decides whether the piece even belongs in that market (if it's built around something that doesn't exist there, we don't localize it), then runs eight controlled steps. The model's confidence is carried through every step as a routing signal, never as a guarantee: the fit check, the independent verify pass, and a human localizer are what decide whether anything publishes.

Get it right Guarantee it Approve & ship

Why it matters

Hover or tap a step to see what happens and why it matters.

What comes out the other side
Locally accurate On brand Compliant No US references Human approved Repeatable at scale
One Life Event article — Starting a Family — localized side-by-side across three markets: English for Ireland, Simplified Chinese, and Czech, each rewritten with local facts and voice rather than translated
Decisions and tradeoffs

Three calls I would make again

One Worker holds every secret

Not taken: calling the Anthropic API and Azure from the browser, which is faster to build and one less deploy.

Why: a shared key in client code is a leak waiting to happen, and there would be no single place to gate writes. The cost is a second deploy target and a hand-written Azure client, since the SDK cannot run in Workers.

A per-locale wiki instead of open-web search

Not taken: letting the model research each market live on the web at draft time.

Why: financial facts have to be ours. A curated wiki is slower to build, one locale at a time, but every retirement system and tax authority the model cites is something a person vetted. Web search still runs in the research stage; it feeds the wiki, it does not bypass it.

Five model calls per article, not one

Not taken: the original one-pass pipeline, which was a fifth of the cost.

Why: one-pass output kept US framing and US-only links that no automated check could see. Splitting into gate, research, draft, independent verify, and save took an article to roughly 335k tokens, and that cost is what forced the skip-approved default and targeted re-runs instead of full-corpus rewrites.

What broke and what changed

Five production failures, and the fix for each

5,455 published variants carried English titles and slugs on localized bodies

Found in the live data during an August audit, not by a user. Title and slug localization is now a checked output of the packager, and the review console shows source and localized titles side by side.

US-only links were invisible to every automated check

Localized articles kept first-party links to US-only content: HSAs, 401(k)s. The fix was a new independent verifier stage (a fail on a US-only link forces a redo) plus a deterministic link check that wraps, aligns, or strips links and rewrites the dangling call-to-action sentence. The first full scan found 51 of those across 27 locales and 8,120 variants.

Five different locale briefs for the first five articles of every batch

The 5-worker pool derived the per-locale brief in parallel before the cache was written: five model calls and five inconsistent briefs. The fix is a keyed single-flight lock with its own tests. A cached brief was later caught still using the wrong register, which led to brief versioning.

A pass failed silently and the job sat at "running" forever

The cultural pass threw a JSON parse error that was swallowed. Unparseable model output now fails the job with a retry, and a count check throws rather than saving a partial article.

A batch overwrote articles a localizer had already approved

A 25-article run reported "25 written, 0 errors" while discarding human edits: measured on three reviewed articles, none of the reviewed sentences survived the re-run. Approved variants are now skipped by default; re-localizing one is an explicit flag.

And the fit check, on real data: of 75 en-GB articles the gate dropped, 13 had a genuine UK analogue and were rewritten as UK-native pieces; 62 could not honestly exist there, 26 of them about the US healthcare system.

Proof

Real counts from the live index

The Studio's code is Financial Finesse's, so it is private. What can be shown is the production data it runs on. These are read from the live content index on September 8, 2026.

8,729
entries in the index
592
English source pieces
8,118
localized variants, 28 locales
4,154
published
975
approved by a localizer
2,772
in human review
A localized article — The £100 Rule and Your Child's Tax-Free Allowance — published and live in the Financial Finesse member product for the UK market
A localized article, published and live in the member product

The Localize QA screenshot above (1,816 pieces awaiting review across 26 locales) and the library view are also production, captured mid-run. The engine behind this site, its test harness, and the rest of what is public are on the Code page.

Timeline

First commit to a ten-locale run in five weeks

April 28, 2026 First commit: the writing studio
May 5–7 Cloudflare Worker live, Vercel deploy, localization tabs
May 22 Launch QA: Azure persistence end to end, batch and localize flows
June 1–4 3,512 pieces localized, ten locales live, peak day 1,575
August Verifier, single-flight, skip-approved: the fixes above, with tests

"A tool one designer built in two weeks changed what our company thought it could go after — and helped us win the Federal Reserve."

Impact

In production for 28 locales, five weeks after the first commit.

8,118

Localized variants in production across 28 locales; 25 with published or approved content (live index, Sep 8, 2026)

3,512

Pieces localized in one four-day run, June 1–4, 2026, bringing ten locales live

4 weeks

First commit to launch QA, one designer, 221 tests; in production for a platform serving 1M+ employees

For scale: doing the same 25-market run by hand would have meant 25 in-country localizers, roughly 9.4 months even in parallel, and about $2.44M in labor. The Studio's run cost $21,287 all in.

Meta NFL JPMorgan Chase CVS Health Federal Reserve Patagonia McKinsey Nestlé Comcast General Mills
Final Takeaway

Global Content Studio writes in the company's voice and carries it into 28 locales, with an independent check and a human localizer between the model and the member. One designer built it, and it is in production.