An AI app builder for the Spanish market that has no Spanish UI, on purpose.
Every competitor on the SERP for this query is selling the same thing: a translated dashboard. A Spanish onboarding. A Spanish pricing page. None of them mention the thing that actually decides whether a Spanish-speaking builder gets to ship today: whether the builder needs a localized UI at all.
mk0r does not. The whole Spanish path is one line of code. Here is that line, and why it matters more than a translated sidebar.
What the top results for this query miss
Search for ai app builder spanish market and you land on the same story five times. Company X launches a Spanish-localized builder. They translated the sidebar. They translated the pricing page. They ran a press release about Spain and Latin America. The article ends.
That is a real product change and I do not want to dismiss it. But it is solving the wrong problem. A Spanish-speaking builder who wants to ship a quinielas app does not spend most of her time in the dashboard. She spends most of her time writing the prompt, reading the output, and iterating. The dashboard is a stop on the way.
The product that wins the Spanish market is not the one that translates its dashboard. It is the one where the prompt language controls the output language, end to end, without the builder having to configure anything. That is a property of the model pipeline, not the UI.
Anchor fact
The entire Spanish-language pipeline in mk0r is promptBlocks.push({ type: "text", text: prompt }) at line 343 of src/app/api/chat/route.ts.
No language detection, no translation hook, no locale switch. The system prompt is one English sentence at src/core/e2b.ts line 148 that never mentions a language. Claude Haiku handles the rest. You can open both files on GitHub and check.
The line of code, in the repo
Here is the actual hand-off from your keystroke to the model. It is the only place your prompt is touched before it reaches Claude. Every character you type, Spanish or otherwise, lands in Claude intact.
And the system prompt, which is the only other string Claude reads before your text, is one sentence long and language-neutral in effect:
How the Spanish prompt actually flows
Three inputs on the left, one hub, three outputs on the right. The hub is the route we just looked at. Nothing in the hub cares about the language of the text flowing through it.
Prompt in Spanish, app in Spanish
The old way vs this way
The gap is not code-quality. It is friction. Every step a Spanish-speaking builder has to do in English, or in a translated dashboard she still has to learn, is a step she can abandon on.
From signup wall to first app
The builder translates its marketing site and sidebar into Spanish and calls that a Spanish product. You still land on a signup form, still need a card, still learn their component canvas. The localized UI saves you maybe 10 minutes of translation. It does not save you the 30 minutes of onboarding.
- Translated landing page
- Signup wall in Spanish
- Credit card required for first app
- Component canvas you still learn in Spanish
- Pricing tiers gate meaningful features
What a Spanish prompt produces
Here is the kind of thing I mean. One prompt in Spanish, one app that works in Spanish, with currency, plural agreement, and button labels all inherited from the prompt. The terminal below is a stylized reconstruction of the streaming tokens so you can see the shape.
The Intl locale call, the peso sign, the word order, the button text, the header: none of those came from a Spanish setting. They came from the prompt. Claude Haiku mirrored the language of the input.
Why this matters for Latin America and Spain
The structural friction of most app builders is not language. It is payment and identity. A freelancer in Bogotá who wants to ship a small client tool today does not mainly need a translated tutorial. She needs to be able to ship without a US-billing credit card, without an English email verification loop, and without learning a new component model.
No signup, no email
Firebase anonymous sign-in fires on first page load. You are building inside a second, before any modal. This removes the language-of-the-signup-flow problem entirely.
No credit card to try
FREE_MODEL = "haiku" in src/app/api/chat/model/route.ts lets anonymous users build without a card. Relevant for markets where US-billing cards are not the default.
Output in your variant
Write in voseo, get voseo. Write in vosotros, get vosotros. The model inherits the register of your prompt. You do not pick a locale; you write the locale.
Real code you keep
Quick mode output is plain HTML, CSS, and JavaScript. VM mode gives you a full Vite + React + TypeScript project inside an E2B sandbox. Both are exportable. No proprietary format.
“The entire Spanish-language pipeline is one line in src/app/api/chat/route.ts. The system prompt is one sentence. That is all the language-handling code there is.”
src/app/api/chat/route.ts line 343, src/core/e2b.ts line 148
What you can verify without an account
Every claim on this page maps to a file in the public repo. You can open each of these without signing up for anything:
- src/app/api/chat/route.ts line 343: the raw prompt pass-through.
- src/core/e2b.ts lines 148 to 149: the one-sentence English system prompt, with no language instruction.
- src/app/api/chat/model/route.ts line 5:
FREE_MODEL = "haiku", available to anonymous users. - src/lib/auth-server.ts: the anonymous-token check on incoming chat requests.
- src/components/header.tsx lines 565 to 574: the current list of residential IP countries (Spain is not yet on this list; this is a known gap).
Pruébalo en español ahora mismo
Abre mk0r.com, escribe tu idea en español, y mira cómo la app aparece en tiempo real. Sin registro.
Abrir mk0r →Frequently asked questions
¿mk0r tiene interfaz en español?
No, y ese es el punto. mk0r casi no tiene interfaz. Escribes una frase en español y sale una app. No hay menús que traducir, no hay tutorial que leer, no hay panel de control que aprender. La única parte que importa, el prompt, ya está en tu idioma porque lo escribes tú.
¿Funciona realmente si escribo el prompt en español?
Sí. El código en src/app/api/chat/route.ts línea 343 pasa tu texto a Claude Haiku sin transformación. Claude es multilingüe, así que si pides 'crea una app para dividir la cuenta del restaurante con propina ajustable' te devuelve exactamente eso, con etiquetas en español, formato de número español, y símbolo de euro si lo pides. El idioma de salida lo decide tu prompt, no una configuración.
Do I need a Spanish-issued credit card to try it?
No card. No signup either. Firebase signs you in anonymously on first visit, and src/app/api/chat/model/route.ts sets FREE_MODEL to haiku for anonymous users. This matters specifically for Latin American builders without easy access to US-billing products.
Can I get output in a specific Spanish variant (Spain, Mexico, Argentina)?
Yes, because the LLM mirrors the variant of your prompt. If you write with voseo and Argentinian vocabulary (vos, che, acomodar), the generated labels tend to match. If you write in Castilian Spanish with vosotros, it leans that way. The app has no hardcoded locale; the prompt is the locale.
What about currency, number formats, and dates?
Those come from your prompt. Ask for 'formato de precios en pesos mexicanos' and the generated HTML uses toLocaleString with es-MX. Ask for euros and comma decimals and you get es-ES. The generated code is real JavaScript, so the localization primitive is whatever Intl API the model writes. You can read the output and change it.
Is there a residential IP for Spain so I can test geolocked APIs?
Not yet. The residential IP selector in the header component currently exposes US, UK, Canada, Germany, France, Australia, Japan, Brazil, India, and Singapore (src/components/header.tsx lines 565 to 574). Brazil is the closest Lusophone option; Spain and Mexico are not in the list at this time. The app building itself is fully multilingual; the residential IP proxy is a separate feature with its own supported-country list.
¿Puedo exportar el código generado?
Sí. En modo rápido, el output es HTML + CSS + JavaScript en un solo archivo que puedes copiar o descargar. En modo VM, obtienes un proyecto Vite + React + TypeScript completo dentro del sandbox E2B que puedes abrir y modificar. No hay vendor lock-in, no hay formato propietario, no hay plugin que instalar.
No hay panel que traducir. No hay tarjeta que registrar. Escribe la app que necesitas y observa cómo aparece.
Empieza ahora