A platform that scaled. An architecture that didn't.
When Ria Money Transfer first built its public web platform, the setup made sense. The team was small, the locale count manageable, and the CMS did what it needed to do. Then the business grew.
I joined when the platform had around 60 locales. Over the next 4+ years, I grew the content operation to support the expanding global business, adding markets, building out the team, and scaling the page count to 2,500+ across 100+ locales. But with the existing setup, the content architecture couldn't evolve with it. We were still operating on a one-to-one model that required a separate document for every page in every locale. A single global update meant dozens of manual changes. A new locale meant rebuilding every page from scratch. A promotion running across 30 locales meant updating 30 individual documents, even when 10 of them were identical English copy.
The content management process was becoming a bottleneck across marketing, product, legal, and growth.
We had 100+ homepage documents for 100+ locales. A global update meant updating the same content over and over, even when it was identical across markets.
Consider something as simple as updating a network location count: when Ria grew from 500,000+ to 600,000+ locations worldwide, that number appeared across hundreds of pages. At roughly 3 minutes per locale, a straightforward update like that meant 5+ hours of manual work. For more complex updates, like a legal disclaimer date referenced across hundreds of pages, the work could stretch across days. In the new architecture, values like these are stored as content keys, updated once, and reflected instantly across the entire platform.
The deeper problem wasn't the tool. It was the architecture. A one-to-one content model treats every page as a standalone document. It works at small scale. At 2,500+ pages across 100+ markets, it creates compounding complexity that no amount of workflow optimization can solve.
Three structural problems, one architectural root cause.
Before proposing a solution, I conducted a full audit of the platform, mapping every content type, every locale, every workflow, and every pain point the team experienced day to day. Three core structural problems emerged:
- Every locale required a separate document per page
- Identical content had to be updated individually across locales
- Translations required manual field-by-field replacement
- No way to push a global change across all locales at once
- 1,000+ corridor pages with overlapping content
- Send and receive country content managed separately
- No programmatic way to update shared sections
- Every new corridor page required a full manual build
- No folder structure beyond locale-level grouping
- No way to view pages across locales simultaneously
- Asset management at page level only
- URL structure limited to locale folders, no deeper hierarchy
The conclusion was clear: incremental fixes couldn't solve a structural problem. The architecture needed to be redesigned from the ground up.
Building the case. Winning the debate.
Before a single page could be migrated, I had to solve a harder problem: getting the organization to agree that the problem was worth solving, and that my solution was the right one.
I started raising the issue in 2024, documenting the platform's limitations and building the internal case for change. From there I led a full CMS evaluation: creating the requirements list, reaching out to vendors, organizing and running demos, and evaluating each platform against our complex use cases: 100+ locales, country-language pairings, programmatic content needs, API flexibility, localization workflows, and A/B testing integrations.
I maintained ongoing relationships with vendors throughout the process, analyzed pros and cons across every candidate, and documented everything clearly enough to present to our heads of marketing and product. When it came time to finalize the contract, I worked through the details before handing off to our CMO.
Not everyone agreed. Other stakeholders pushed for different platforms. I spent months making the case for Storyblok and walked away with my first choice.
The most important part of the process was earning buy-in from our heads of product. Through persistent, evidence-based advocacy grounded in our specific use cases, the limitations of the alternatives, and a clear vision for what the new architecture could enable, I secured sign-off.
From one-to-one to one-to-many.
The goal wasn't to move content from one CMS to another. It was to redesign how content is created, managed, and scaled. The challenge was to find a platform that could support it.
The shift at the center of this work was moving from a one-to-one content model, where every page in every locale is a standalone document, to a one-to-many model, where content is created once at the component or reference level and applied across pages, locales, and markets programmatically. I partnered with our engineering and product teams and selected Storyblok for its component-based content modeling, flexible API, and folder structure that could support our locale and country-level needs.
The current migration isn't just a technical lift. It's a full platform transformation: new content architecture, new UX and visual design, new component library, and new workflows built to reduce the manual effort of managing content at global scale.
The new architecture is built around three distinct scaling mechanisms, each solving a different dimension of the problem.
Old: every page is a standalone document. A change means 100+ manual edits.
New: content lives once, referenced everywhere. A change means 1 edit.
Result: a lean team manages 2,500+ pages across 100+ markets.
- One document per page per locale
- Identical content duplicated across 100+ locales
- Global updates required manual changes to each document
- No folder structure beyond locale grouping
- New locales required full page rebuilds
- No programmatic content assembly
- Asset management at page/slice level only
- Global reusable components placed across country folders
- Content keys for dynamic values updated in one place
- AI workflows to programmatically update content from business data
- Full folder structure: global, country, page type
- New locales via translation workflow, not rebuild
- Programmatic page assembly from content database
- Global asset management with page-level tracking
Global reusable components are built once in a global folder and placed directly onto pages in their country-specific folders. A shared section (a promotional banner, a trust module, an app download CTA) is authored once and referenced everywhere it appears. Update it once and it updates everywhere.
Content keys solve the dynamic value problem. Shared legal language, years of operation, transaction limits, and other values that appear across hundreds of pages are stored as keys and referenced throughout the platform. Change the value once and it propagates instantly across every page that references it, with no manual updates and no risk of inconsistency.
AI-powered content workflows, built in partnership with our development team, address the corridor page challenge specifically. The business provides regular data exports with corridor-specific information: available delivery methods, transaction limits, top partners, and more. Rather than manually updating hundreds of information-rich sections, these AI workflows read the data export and programmatically update the relevant content. The team reviews and approves certain updates rather than writing them all from scratch, dramatically reducing the time and effort required to keep corridor pages accurate and current.
Together, these three mechanisms shift the content model from one-to-one to genuinely one-to-many, where a small team can maintain and update a platform of 2,500+ pages across 100+ markets without proportional increases in effort.
Building a platform worth redesigning.
The visual transformation of the Chile locale is the most visible output of this project. But the design didn't come first. The content did.
When I joined Ria, the navigation was purely tactical: track a transfer, find a location, help. It served existing customers completing transactions. There was no content layer for acquisition, no send money pages, no receive method pages, no regional hubs. The platform didn't reflect the depth of what Ria actually offers.
Over the past two years, I led my team in building that content infrastructure from the ground up: all the send money pages, receive method pages, and the regional hub pages that organize them. The new "Money transfer" dropdown in the nav isn't a design decision. It exists because we built what goes in it.
The "Money transfer" dropdown structures the full content architecture I built: ways to send, ways to receive, send money on the go, and as we complete the migration, regional "Send to" hubs linking to every corridor cluster we operate in. The nav is the content strategy made visible.
The visual redesign launched alongside the new CMS in partnership with our UX and brand design teams. I led the content strategy, information architecture, and the page infrastructure underneath it. The CL locale is the first market live on the new platform. The US and additional markets are in progress.
Cross-functional from day one.
This project requires building alignment across product, engineering, SEO, design, legal, and the content team, all with different priorities and constraints. I own the content strategy and architecture decisions and serve as the primary bridge between teams throughout the process.
Key cross-functional workstreams include:
- Partnering with engineering to design the new component library and content model in Storyblok
- Working with design on a full UX and visual overhaul that launched alongside the new CMS
- Coordinating with SEO on URL structure, internal linking, and the migration plan to protect organic rankings
- Working with legal to ensure the new architecture supports compliance requirements across markets
We launched the first market, Chile, as a proof of concept. It validated the new architecture, the new design system, and the new content workflows as we scale the migration across all 100+ markets.
Early signals from a platform built to last.
The Chile locale is live. Additional markets are queued. The migration is active. One month after full rollout, homepage unique views on the new architecture have doubled.
What we can already measure: the new architecture has validated the one-to-many model in production, content updates that previously required hours of manual work now take minutes, and the team is building on a platform that can actually grow with the business.
The larger results will compound. New locales that launch on the new architecture never have to be manually rebuilt. Shared components update once instead of 100+ times. Corridor pages stay current because the data pipeline handles it, not because someone spent hours doing it manually.
That's not a project metric. It's a platform capability that will continue to grow alongside our money transfer business.