Next.js development for Miami cross-border and bilingual businesses

Miami sells north and south at the same time, and that makes its websites a specific technical case that most multilingual advice does not cover.

A business here is typically selling into the United States and into Latin America from the same Florida entity, to an audience that is substantially bilingual in the same city. So English and Spanish are not two markets - they are two languages for one place, plus several other places that share one of them.

Two languages, one country

Almost every multilingual setup assumes language maps to country. Spain gets Spanish, Germany gets German, the United States gets English. A Miami business breaks that assumption on its first page.

The mechanism that handles it exists and is rarely used properly. Alternates can be declared by language and region together, so a Spanish page intended for the United States is a different target from a Spanish page intended for Spain or Mexico. Declared that way, a Spanish speaker in Florida is served the page written with US terminology and dollar pricing rather than one written for a different market entirely.

Declared the common way - language only - the versions compete, and search engines choose between them on signals nobody controls. How hreflang and alternates actually work covers the specifics, and this is the market where getting it wrong is most visible.

Spanish for Miami is not Spanish for Madrid

This is a content point with a technical consequence, which is why it belongs here rather than in a style guide.

The terms that differ between regional variants of Spanish are concentrated in exactly the areas a Miami business operates in - banking, insurance, property, logistics, healthcare. Those are also the words people type into a search box. A page using the European term for a financial product ranks for a query nobody in Florida makes, and reads to a local audience as though it was written somewhere else.

So the Spanish version is written rather than translated, and the technical requirement that follows is that the content model allows the two versions to diverge. A structure that assumes each page is a translation of its English counterpart, one to one, fights the thing that makes the Spanish version worth having.

Currency belongs to the customer, not the language

The last recurring Miami question is pricing across borders, and the mistake is to attach currency to language.

A Spanish page does not imply a currency. A Spanish-speaking customer in Miami pays in dollars; one in Bogotá may want to see pesos and still pay in dollars; one in Madrid is a different market altogether. Showing a converted figure as though it were the price produces a dispute when the card is charged at a different rate.

The arrangement that holds is that the transaction currency is a property of the customer and the agreement, displayed figures in another currency are labelled as indicative, and the conversion rate used for any actual charge is recorded with the charge. That is a backend decision with a front-end obligation - to not display a converted number as though it were a quote.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - state privacy laws, sales tax, accessibility exposure - is on the United States market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption and no US entity on our side.