Spanish is not one language. A teacher in Mexico City does not write a lesson plan the same way as a teacher in Santiago de Chile, and a teacher in Bogotá uses a different official curriculum framework than a teacher in Buenos Aires. When we started planning Creaclases (the Spanish-speaking fork of our lesson-planning engine, currently in pre-prod at preprod.creaclases.com), we thought "we just translate the UI". Six weeks in, we knew we had been naive. Localizing SaaS multiple countries is a real architecture problem, not a strings file. Here is what we learned and what shipped.
The 10 countries we cover, and why
Creaclases targets ten Spanish-speaking Latin American markets: Mexico, Colombia, Argentina, Chile, Peru, Ecuador, Guatemala, Bolivia, Costa Rica, and Uruguay. We picked these for a mix of reasons: market size, internet penetration, willingness-to-pay for educational tools, and our ability to validate the curriculum (we have collaborator contacts in five of the ten and we are building the others).
We deliberately did not include Spain in this fork. Spain has a different educational system, a different currency, and a different cultural register. It deserves its own product later if we go there at all.
The 10-country scope is ambitious for a small studio. We are not pretending it is easy. Plan F (the current iteration of the launch plan, in progress as of late April 2026) is the sixth pass at the rollout sequence. We have rewritten it five times because each revision taught us something the previous one missed.
The first lesson: language is the easy part
We thought translation would be the hard part. It is not. Translation is well-trodden territory, the LLMs are excellent at it, and our Spanish-language reviewer can polish the output in hours per locale.
The hard parts, in order:
- Curriculum frameworks differ. Mexico's SEP, Colombia's MEN, Argentina's Núcleos de Aprendizajes Prioritarios, Chile's Currículum Nacional. They are structurally different. A Mexican teacher's lesson plan needs to map to "aprendizajes esperados" while a Colombian one references "estándares básicos de competencias".
- Vocabulary is country-specific. Some words are neutral across the region (libro, profesor, escuela). Others are not (computadora vs ordenador vs computador). Slipping into Spanish-from-Spain is the fastest way to lose a Latin American teacher.
- Pricing reality is different per country. A 14 USD per month price point that is fine for Mexico is brutal for Bolivia. We need country-specific pricing without the fragmentation of country-specific products.
- Payment methods differ. Stripe handles most LATAM countries but local payment methods (OXXO in Mexico, PSE in Colombia, Mercado Pago in Argentina) matter for conversion.
- Time zones, date formats, and grade-level conventions all vary. "Sexto grado" is not the same age range in Mexico and Argentina.
Translation is maybe 10% of the work. The rest is structure.
The architecture: country configs, not country forks
The single biggest decision was to do this in one codebase. Creaclases lives inside the same monorepo as PrepareMesCours, DraftMyLesson, and PrzygotujLekcje. Same engine. Same authentication. Same multi-tenant patterns we covered in our day-one multi-tenant playbook.
Each country is a configuration object with:
- Locale code (es-MX, es-CO, es-AR, etc.)
- Curriculum framework reference
- Grade-level mapping (a 12-year-old maps to "primero de secundaria" in Mexico, "sexto grado" in Colombia)
- Pricing tier in local currency
- Allowed payment methods
- Vocabulary overrides for terms that differ
- Date and time formats
- Default classroom assumptions (class size, period length)
The application reads the country config at request time based on the user's profile (the teacher tells us their country during onboarding). The same lesson-plan engine generates a different output for the same input, depending on the country.
The temptation to fork was real. We fought it. The reason: we have lived through what happens when you fork. We did it with PrepareMesCours, DraftMyLesson, and PrzygotujLekcje for a year and the rot was visible. Bug fixes in one fork did not propagate. Features drifted. We unified into a monorepo (Plan A finished April 24, 2026) and the relief was immediate. We were not going to make that mistake again with Spanish.
Localization is a configuration problem, not a fork problem. The minute you have two codebases, you have two times the maintenance and zero times the velocity.
The vocabulary problem, solved imperfectly
Vocabulary is the trickiest part. Most words are universal. A subset are country-specific. Our approach is layered:
- A base Spanish dictionary with neutral terms.
- A country-specific override file for each of the 10 countries. The override only contains terms that differ from the base.
- A community feedback loop where teachers can flag a term as "we don't say it like that here" and we add the override.
This is not perfect. There are terms that are right in 6 countries and wrong in 4, and our override system handles this fine, but it requires maintenance. We accept that maintenance as the cost of doing business.
For the LLM-generated lesson content, the prompt includes the country code, the dialect cues we want preserved, and explicit instructions to avoid terms that are common in Spain but not in Latin America. The LLM is good at this when prompted well.
Pricing in 10 currencies without losing your mind
We landed on a deliberately simple model:
- One reference price in USD as the internal "fair value" of the product.
- A purchasing-power adjustment per country to set the local price. Mexico might be 90% of USD reference, Bolivia might be 50%.
- Display the price in the local currency with the appropriate locale formatting.
- Stripe handles the conversion and the payment, with country-specific payment methods enabled per market.
The simple model has a key property: a teacher in Bolivia is not paying USD prices that feel out of reach, and a teacher in Chile is not paying Bolivian prices that we cannot afford to honor. The price is contextualized to the buyer.
We discussed pricing AI features more broadly in our pricing AI features for SMBs post. The principles transfer: be transparent, set caps, and respect the customer's economic context.
Curriculum mapping: where we paid the most engineering tax
Mapping a generated lesson plan to a country's curriculum framework was the single largest engineering investment in Creaclases.
The shape of the problem: a teacher selects "I want to teach a lesson on ecosystems for 10-year-olds". In Mexico, this needs to map to specific "aprendizajes esperados" inside the SEP framework. In Colombia, it maps to specific "estándares básicos de competencias" in the MEN framework. The structures of these frameworks are not isomorphic.
Our approach is to maintain a per-country mapping table from "topic + age" to "framework reference". Building these tables required real domain work. We worked with collaborators in each country to assemble the initial maps. The maps are not static: when curriculum guidelines update (which happens), we update the maps.
The output of a generation includes the framework reference inline so the teacher can paste it into their official lesson-plan documentation, which most LATAM teachers are required to file. This is the moat. A horizontal AI tool will give you a lesson plan. Creaclases gives you a lesson plan with the right framework references for your country, ready to file.
The pre-prod state: what we learned by not launching yet
We are deliberately in pre-prod at preprod.creaclases.com as of April 26, 2026. Plan F (the current rollout) is sequencing the 10 countries in priority order based on collaborator readiness and market signal. We are not going GA in all 10 simultaneously.
The lesson from the preceding 5 plans:
- Plan A assumed all 10 countries simultaneously. Naive.
- Plan B sequenced by population. Wrong, because population does not equal teacher willingness-to-pay.
- Plan C sequenced by collaborator availability. Closer.
- Plan D added a "free B2C detector" approach inspired by Carriva. We are still iterating on this.
- Plan E tried to launch Mexico standalone and discovered the curriculum mapping for Mexico needed two more months of work.
- Plan F (current) launches Colombia and Chile first because curriculum maps are ready, follows with Mexico in 6 weeks, then sequences the remaining seven over the rest of the year.
If you are localizing SaaS multiple countries, the process of writing six rollout plans is part of the work. You cannot plan it once. You plan, you learn, you re-plan.
What we would warn a founder about
Three traps to avoid:
- Do not assume one Spanish. Even our domain experts who speak fluent Spanish were surprised by how much country-specific vocabulary mattered.
- Do not fork the codebase. Configuration. Configuration. Configuration.
- Do not launch all countries at once. Sequence by collaborator readiness and curriculum maturity. The ones that are ready will inform the ones that are not.
For broader context on how we ship this kind of work as a small studio, our shipping four SaaS in parallel post covers the operational shape and what breaks. Creaclases is the fifth product fitting into that operating rhythm. We discussed how we got fast at this in our idea to production in six weeks story, which is the model we keep returning to.
Tooling that compounds
A tactical note: most of our localization workflow runs through Claude Code with persistent skills that know our country configs and can generate vocabulary overrides on request. We tried Cursor briefly. Claude Code's 1M-context window means we can hold the full set of country configs in memory while iterating, which matters when the question is "is this term consistent with how we treat the same concept in the other 9 countries?"
That tooling choice is downstream of why we made the choice in the first place: localizing SaaS multiple countries is the kind of multi-context work that punishes short-context tools.
What is next
By Q3 2026 we expect Creaclases to be live in 6 of the 10 countries. The remaining 4 will follow as collaborator readiness and curriculum work mature. We are intentionally going slow in the rollout because the cost of launching a country with a wrong curriculum mapping is higher than the cost of waiting two months and getting it right.
Localizing SaaS multiple countries is not a translation project. It is a curriculum, vocabulary, pricing, payment-method, and rollout-sequencing project. If you treat it like translation you will ship a thing that feels like Spanish-from-Spain to a Mexican teacher, and you will lose them in 90 seconds. Treat it like configuration, get domain experts on the inside, and sequence carefully. The ten markets are worth it. Just respect the work.
