Una app de avatares que es tuya, y una llave que no sale de tu máquina

Avatar App Kit es una aplicación que clonas y levantas en tu propia computadora. Desde ahí le habla directo a la API de Higgsfield con la llave que tú pones, y todo lo que ves en el navegador lo está sirviendo tu máquina. Es de código abierto con licencia MIT, así que puedes leerlo, cambiarlo y repartirlo sin pedirle permiso a nadie.

Por dentro no hay nada exótico: Next.js 16, React 19, TypeScript, Tailwind v4 y shadcn/ui. Lo único que vale la pena señalar es lo que no está. No usa ningún SDK de Higgsfield; en su lugar hay un cliente tipado de unas 200 líneas hecho con fetch. Eso importa por una razón práctica: cuando quieras cambiar cómo se arma una petición, tienes que entender un archivo, no una dependencia.

El repositorio es Hainrixz/avater-appkit, y sí: se escribe «avater», con la errata. Así se llama la carpeta cuando la clonas y así es como el enlace funciona.

Vale la pena decir las dos mitades, porque la primera suena a producto y no lo es.

En la bóveda ya hay dos guías que llegan a este mismo motor por otra puerta, y conviene saber cuál te sirve hoy. No compiten: resuelven momentos distintos del mismo trabajo.

Si nunca has conectado Higgsfield a Claude, ese es el arranque más barato y no pide instalar nada: la guía del conector lo deja funcionando en tres pasos. Esta página va por la otra puerta, la que pasa por la API.

El prompting tampoco se re-enseña aquí, y no por falta de espacio: ya está escrito. El método de dirección de arte tiene su propia guía, y lo que aprendas ahí se escribe igual en el campo de texto de esta aplicación. Aquí el tema es la herramienta, no lo que le dices.

Los tres caminos terminan en el mismo motor. Este es el único donde puedes abrir el archivo que arma la petición y cambiarlo.

Hay dos caminos para ponerla a correr y los dos terminan en el mismo lugar: la aplicación abierta en tu navegador, esperando una llave. El primero es pedírselo a Claude Code y no tocar la terminal en ningún momento. El segundo son cuatro líneas, si la terminal ya es tu casa.

Lo único que necesitas antes de empezar es una carpeta vacía donde vivir. El código es abierto y la licencia es MIT: se baja, se queda en tu disco y es tuyo para modificarlo. Aquí no hay cuenta que crear ni servicio al que registrarse.

Empecemos por el camino que no pide terminal. Abre Claude Code —la versión de Claude que trabaja dentro de una carpeta de tu computadora y sí puede bajar, instalar y arrancar cosas— dentro de una carpeta vacía, y pégale el encargo de abajo. Él clona el repositorio, instala lo que haga falta, lo arranca y te dice en qué dirección abrirlo.

Lo importante de ese prompt está en el final: le pide explícitamente que arregle él lo que truene —que te falte Node, que el puerto esté ocupado, que la instalación se caiga a la mitad— y que te lo explique en una línea, en vez de devolverte un error para que lo resuelvas tú. Y le pide que no te pida ninguna llave todavía, porque ese paso no pasa por la terminal.

Si es la primera vez que lo oyes nombrar, se instala una sola vez y vive en tu terminal: así se consigue Claude Code. El resto de esta guía asume que ya lo tienes abierto.

Clona el repositorio https://github.com/Hainrixz/avater-appkit en esta carpeta, instala sus dependencias y arráncalo en modo de desarrollo.

Cuando esté corriendo, dime exactamente en qué dirección lo abro y qué voy a ver en la primera pantalla.

Si algo falla —que me falte Node, que el puerto esté ocupado, que la instalación truene— arréglalo tú y explícame en una línea qué pasó. No me pidas que edite archivos.

No me pidas ninguna llave de API todavía: eso se pega después, dentro de la propia aplicación.

El camino corto, si prefieres escribirlo tú

Son cuatro líneas y están tal cual en el README: bajarlo, entrar a la carpeta, instalar, arrancarlo. Ninguna pide configurar nada antes.

Ojo con el nombre, porque muerde: el repositorio se llama avater-appkit, con esa errata. Es el nombre real y así hay que escribirlo; corregido a «avatar» el enlace simplemente no existe.

Termines por donde termines, lo que sigue es idéntico: se abre en http://localhost:3000. La primera pantalla te pide tu llave de Higgsfield, la pegas ahí dentro de la aplicación, y ya está lista para generar.

No hay un paso intermedio entre arrancarla y verla funcionando: la llave entra por la interfaz, no por un archivo que haya que editar. De dónde sale esa llave, dónde queda guardada y por qué no se mueve de tu máquina es lo que viene enseguida.

Hay una sola cosa que la aplicación te pide de fuera, y es la llave de tu cuenta de Higgsfield. Vale la pena saber exactamente de dónde sale, dónde se queda y hasta dónde llega, porque de eso depende lo que puedes hacer con el repositorio después.

Empecemos por lo que no hay. En este repositorio no viaja ninguna llave: nada está quemado en el código y nada se guarda ahí. Lo clonas y te llega una aplicación sin credenciales, esperando la tuya.

La llave sale de la consola de Higgsfield, en cloud.higgsfield.ai, que es la misma cuenta de la que se descuentan tus créditos. Copiarla de ahí y pegarla en la aplicación es todo el trámite. Lo interesante es lo que pasa después de que le das pegar.

Una última cosa de ese primer momento: pegar la llave no dispara ningún cobro, así que ahí mismo sabes si quedó bien puesta. Averiguarlo a la mitad de tu primera generación es peor.

Una receta no es un filtro ni un estilo. Es un paquete de decisiones ya tomadas: cuántas fotos pide, para qué sirve cada una, qué instrucción se le manda al modelo y qué modelo la recibe. Tú llegas con las imágenes y lo demás ya está resuelto.

Primero eliges Fotos o Video, arriba. Después eliges la receta. Y entre las tres, lo único que cambia de verdad es qué sueltas en el segundo hueco: un lugar escrito, una prenda, o la foto de otra persona.

El recorrido es el mismo sin importar cuál elijas, y son tres movimientos.

Por debajo las tres son más parecidas de lo que aparentan. Cuatro cosas valen para todas:

• Las tres salen en vertical, 9:16.
• En cualquiera de las tres puedes pedir 1, 2 o 4 imágenes en la misma tanda.
• Cada receta llega con su par de modelos ya elegido, y en las tres es el mismo: popcorn/auto para la foto y kling-2.5-turbo-pro-i2v para animarla.
• Lo que escribes no llega solo al modelo. La aplicación le antepone su propia instrucción para orientarlo: en Teleport, esa instrucción pide que la cara y la complexión se mantengan idénticas a la foto de referencia, y que la escena se arme alrededor de la persona con su luz cayéndole encima.

Teleport es la única que exige texto, así que para que ese campo no sea una hoja en blanco ya viene con media docena de lugares escritos. Sirven tal cual, y sirven como molde: fíjate que ninguno es nada más un sitio. Todos traen hora del día y estado de la luz.

• Tokio de noche, con el neón reflejado en el asfalto mojado.
• Una escalera de Lisboa a la hora dorada.
• Un campo de nieve con luz nublada.
• Una terraza de café en París bajo la lluvia.
• El puente de Brooklyn a la hora azul.
• Una azotea en Ciudad de México al atardecer.

Si te ganó la curiosidad de ver cómo está escrita cada receta por dentro, viven todas en lib/recipes.ts. Ahí se lee palabra por palabra la instrucción que la aplicación le antepone a la tuya.

Hasta aquí, qué le das a cada receta y qué te devuelve. Lo que la aplicación hace con eso por debajo —una llamada o dos, y con qué número enfrente antes de cobrarte— es la 05.

Antes de elegir receta, la aplicación te hace una pregunta de dos opciones: Fotos o Video. No es un interruptor de calidad ni de estilo. Cambia cuántas llamadas se hacen por debajo y, con eso, cuánto te cuesta apretar el botón.

Ninguno de los modelos de video que se verificaron para esta app va del texto directo al clip: todos necesitan una imagen que animar. Así que pedir un video son dos etapas —primero la foto, después la animación— y la aplicación las encadena sola, sin que tengas que guardar nada en medio ni volver a subir la imagen que acaba de salir.

Lo que hace tolerable pagar dos veces es ver la cuenta completa antes. El botón no dice «generar» a secas: trae el total y el desglose de las dos etapas, ya sumado.

Generate video · $0.442

  foto $0.092  +  video $0.350

Esos tres números son el ejemplo que enseña el README, no una tarifa: cambian con el modelo que elijas y con lo que le cobre Higgsfield a tu cuenta. El que manda es el que aparece en tu pantalla, con tu llave, un segundo antes de que decidas.

De que el video sean dos etapas se desprenden cuatro cosas que se notan en la interfaz:

• Son dos catálogos distintos y no se cruzan: los modelos de imagen no hacen video y los de video no hacen imagen. En modo Video los dos selectores aparecen numerados, como las dos etapas que son.
• La proporción del video no se elige: la hereda de la foto que lo origina, porque ninguno de los modelos de video verificados acepta un campo de proporción. La aplicación lo dice en pantalla en vez de dejarte buscar un selector que no existe.
• Si eliges Fotos te quedas con imágenes que puedes descargar y usar tal cual. Nada te obliga a animarlas.
• Y si después quieres el clip, cualquiera de esas fotos se anima en su momento: ahí la imagen ya existe, y lo que vas a pagar es el precio que aparece junto al botón.

El ajuste existe porque los cuerpos de petición de la API no son uniformes. Un mismo dato —cuántos segundos dura el clip— se pide de tres formas distintas según el modelo:

Un catálogo así se rompe el día que se agrega un modelo más y su función queda a medias. Por eso hay una prueba que revisa todas de un golpe —que cada una acepte lo que dice aceptar y quite lo que no— sin salir a internet y sin gastar un solo crédito.

Regla corta: si vas a Video, el precio del botón ya trae las dos etapas. Si vas a Fotos, pagas una y decides después si quieres la segunda. En los dos casos el número que cuenta es el que ves tú, no el de este ejemplo.

Todo lo de arriba se lee como si la aplicación cumpliera entera. Esta es la parte donde no. Subes tu selfie, pides una azotea en Ciudad de México al atardecer, y lo que baja es una foto vertical creíble: el lugar está, la luz cae sobre la persona, el encuadre se sostiene. Lo que no está del todo es tu cara.

Y la razón vive en el modelo, no en cómo lo pediste. Teleport corre sobre popcorn/auto, que el propio catálogo de Higgsfield clasifica como un modelo de texto a imagen. Recibe tu foto de referencia, sí. Pero no expone ni un solo parámetro de identidad: no hay nada que subir, ajustar ni pesar para decirle «esta cara, exactamente esta, en todas las tomas». Un control que el modelo no tiene no se inventa desde el texto.

El arreglo está identificado y no está construido, y esas dos mitades van juntas en la misma frase. Se sabe qué endpoints hay que tocar y en qué orden; nadie los ha cableado dentro de este repositorio. Va escrito como plan, con esa palabra.

Y antes de leerlo, una aclaración que evita el malentendido obvio: aquí vuelve a aparecer la palabra «referencia», pero no es la misma de la receta de Teleport. Aquella es la foto suelta que le entregas a la receta y que el modelo mira una sola vez, sin guardar nada de ella. Esta es un identificador que se entrena con varias fotos de la misma persona y se guarda con nombre propio, para pedirlo después en cada encargo. Se parecen en el nombre y en nada más.

Y un detalle que conviene tener claro, sobre todo porque es fácil culparlo de lo que no es. Higgsfield tiene una mejora automática de prompt —reescribe tu texto en su propio servidor antes de generar— y viene encendida por defecto en varios de sus modelos. En los que usan estas tres recetas, no: ni el de foto ni el de video mandan ese campo. Así que si un Teleport ignoró lo que pediste, la explicación no es esa.

• Donde sí viene encendida es en el modelo de referencia de Soul y en los dos de DoP: están en el catálogo, pero ninguna receta los usa.
• O sea que te alcanza el día que salgas de las recetas y llames a esos modelos por tu cuenta. Ese día, lo que se manda a generar no es palabra por palabra lo que escribiste, sino la versión que el servidor reescribió.
• Para un resultado de Teleport, Try-on o Duo que no obedeció, el primer sospechoso sigue siendo el de arriba: el modelo no tiene con qué sostener una identidad.

Si lo que necesitas es tu cara y lo necesitas ahora, la ruta que sí funciona hoy es la manual, y está contada paso a paso en Video con IA con Higgsfield y Seedance 2.0: te clonas primero como personaje a partir de tus fotos y de ahí en adelante trabajas con ese personaje. Es más trabajo y no cabe dentro de esta aplicación, pero el parecido lo resuelve.

Nada de esto se arregla desde la interfaz, y por eso va junto en una sección en vez de repartido como notas al pie. El código es tuyo: si lo que quieres es construir el arreglo, el camino de arriba está descrito con detalle suficiente para intentarlo.

El catálogo no es el mismo para todos. Lo que puedes correr depende de la cuenta que hay detrás de la llave que pegaste, así que dos personas con el mismo código, la misma pantalla y la misma versión pueden abrir listas distintas. Eso no se arregla desde el repositorio porque no está del lado del repositorio.

Por eso la aplicación no trae la lista escrita a mano en ningún archivo. La pregunta cada vez que arranca: recorre el catálogo modelo por modelo preguntando el precio, y esa consulta no cuesta créditos. Lo que termina en pantalla son precios reales junto a disponibilidad real, medidos con tu llave y no con la de nadie más.

Así salió ese sondeo en la cuenta con la que se construyó la aplicación. Léelo como lo que es: una foto de una cuenta un día, no una lista oficial de lo que incluye tu plan.

Estos son los cuatro nombres que se quedaron en gris en esa cuenta. Están en el catálogo de la aplicación, aparecen en la lista y no se pueden elegir:

• Veo 3.1 (reference)
• Veo 3.1
• Sora 2 Pro
• Seedance Pro Fast

Ninguno de esos necesita que le hagas nada. Si tu plan los incluye, se encienden solos: no hay bandera que activar ni archivo de configuración que editar, porque la disponibilidad no la decide el código sino la respuesta de la API. El siguiente arranque los vuelve a preguntar y aparecen a color, con su precio al lado.

Esconder lo que no puedes correr saldría más limpio en pantalla y sería peor para ti. Un catálogo recortado en silencio te deja creyendo que eso es todo lo que existe, y cuando alguien menciona un modelo que tú nunca viste, no tienes forma de saber si te falta plan, si te falta versión o si te lo estás inventando.

En gris y con la razón al lado, la misma lista contesta dos preguntas de una: qué puedes hacer hoy y qué te estás perdiendo. Eso convierte una decisión de compra en un dato que ya tienes en la pantalla, en vez de una consulta a un soporte.

Lo que diga tu propio sondeo manda sobre cualquier número de esta guía, este incluido.

Un error bien etiquetado se arregla en un minuto. Uno mal etiquetado te manda a buscar donde no es: revisas la llave, cambias la foto, reescribes el texto y vuelves a enviar —y a pagar— por un problema que nunca estuvo ahí. En esta API hay tres respuestas que se presentan con la cara de otra cosa, y las tres tienen una lectura correcta que no es la primera que se te ocurre.

La aplicación ya trae esa traducción hecha, así que en pantalla vas a ver la lectura buena y no el mensaje crudo. Vale la pena saber qué hay detrás de cada una: es lo que te va a permitir reconocerlas si algún día le pides a Claude que toque esa parte del código.

Los tres se ven mal y solo uno lo es de verdad. Esta es la traducción, en el orden en que suelen aparecer.

Falta una pieza que en cualquier servicio en la nube darías por hecha: aquí no hay webhooks. Higgsfield sí ofrece uno, pero para avisarte que tu trabajo terminó necesita poder tocar la puerta de tu aplicación, y eso pide una dirección pública con HTTPS. Tu localhost no lo es. Existe nada más dentro de tu máquina, y desde fuera no lo alcanza nadie.

Así que la aplicación hace lo contrario de esperar: pregunta. Desde el navegador consulta el estado del trabajo cada tanto, respetando la espera que documenta la propia API, hasta que hay resultado o hay error. No tienes que configurar nada para que funcione, y mientras la pestaña esté abierta la app se entera sola de cuándo terminó.

Los tres casos comparten la misma moraleja, y sirve mucho más allá de esta aplicación: lo que devuelve una API es una pista, no un diagnóstico. Cuando algo falle en tu copia, la primera pregunta no es cómo lo arreglo sino qué me está diciendo de verdad.

Hasta aquí la aplicación es la que armó alguien más: sus colores, sus tres recetas, sus fotos de ejemplo. La licencia es MIT y el código completo está en tu carpeta, así que nada de eso es definitivo. Cambiar cómo se ve, qué ofrece y qué enseña son tres movimientos distintos, y cada uno vive en un lugar concreto del repositorio.

Ninguno de los tres pide que sepas programar. Lo que sí ayuda es saber dónde está cada cosa antes de pedirla, porque así te das cuenta si la respuesta se fue por otro lado.

Los colores y la tipografía viven en un solo bloque

Todo el tema está declarado junto, en un solo archivo —app/globals.css—, y de ahí lee la aplicación entera. Eso vuelve el cambio de paleta un cambio de un solo lugar, en vez de una cacería por treinta archivos buscando dónde quedó el morado que ya no quieres. Quedan dos colores fuera, y conviene saberlo: el de la barra del navegador, que vive en los metadatos porque una etiqueta meta no puede leer una variable de CSS, y un degradado índigo en la pantalla de progreso.

La regla que conviene sostener es esa misma: si aparece un color quemado dentro de un componente, lo correcto es subirlo al tema, no volver a pintarlo ahí. El prompt de abajo se lo pide a Claude Code de forma explícita, para que la próxima vez que cambies de marca siga siendo un solo bloque.

No hace falta que lo abras para pedir el cambio, pero está a la vista: el tema vive en app/globals.css, junto y antes de cualquier regla de componente, no repartido por el archivo.

Quiero que esta aplicación se vea como mi marca.

Mis colores: [PEGA TUS HEX]
Mi tipografía: [NOMBRE, o "deja la que trae"]
El nombre del producto: [CÓMO SE VA A LLAMAR]

Cambia el bloque de tema al principio de app/globals.css, el nombre y el texto de la portada, y deja listo el lugar donde voy a poner mis propias imágenes de ejemplo en public/demo/.

No toques la lógica ni los componentes: todo lee del tema, así que no debería hacer falta. Si te topas con un color escrito a mano en algún componente, muévelo al tema y dímelo.

Cuando acabes, arráncalo y dime qué revisar.

Las recetas son datos, no componentes

Teleport, Try-on y Duo no son tres pantallas distintas que alguien programó por separado. Son tres entradas en lib/recipes.ts, y cada una declara lo mismo: cuántas fotos pide, qué prompt base le antepone al texto que tú escribes, y con qué modelo genera la imagen y con cuál la anima. El selector, el texto y los modelos salen de ahí y de ningún otro lado.

Por eso una receta nueva no es un rediseño. Es una entrada más con la misma forma que las tres que ya están.

Quiero agregar una receta más a esta aplicación, junto a Teleport, Try-on y Duo.

Se va a llamar [NOMBRE] y hace esto: [DESCRÍBELO EN UNA FRASE]
Le voy a dar: [QUÉ FOTOS, cuántas y de qué]
Me devuelve: [QUÉ]

Agrégala en lib/recipes.ts siguiendo exactamente la forma de las tres que ya están: sus huecos de foto, su prompt base, su modelo de imagen y su modelo de video.

Después comprueba que la zona de arrastre y el selector la tomen solos. Ojo con una cosa: ese componente está escrito para una o dos fotos y las toma por su posición, así que si mi receta pide tres, la tercera no se va a dibujar y el botón de generar se va a quedar apagado sin decir por qué. Si es mi caso, dime qué hay que cambiar antes de cambiarlo.

Las imágenes de ejemplo son salida real, y se cambian por las tuyas

Lo que ves en la portada y en el comparador no son maquetas armadas en una herramienta de diseño: son resultados que salieron de esta misma aplicación, y viven en la carpeta public/demo/. Cambias esos archivos por los tuyos y las dos pantallas se actualizan con ellos.

Y si vas a agregar piezas de interfaz que hoy no existen, el proyecto ya usa componentes de 21st.dev, que se agregan con el comando de shadcn. O sea que traer una tarjeta o un selector nuevos no obliga a inventarlos desde cero ni a romper el tema: llegan leyendo las mismas variables que todo lo demás.

Si tienes curiosidad de ver la forma antes de pedir la tuya —qué campos trae cada receta y cómo se ven las tres juntas—, lib/recipes.ts está abierto en el repositorio. Ahí están las tres declaradas, una debajo de la otra.

Debajo de todo lo que ves en pantalla hay una sola puerta. La aplicación no le habla a Higgsfield: le habla a una interfaz que un archivo declara y que una carpeta implementa. Higgsfield es esa carpeta. Es la única que viene incluida, pero no es la única que cabe.

La distinción suena a detalle de arquitectura y es justo lo contrario: decide cuánto cuesta el día que quieras generar con otra cosa. Si cada pantalla llamara a la API por su cuenta, cambiar de proveedor sería reescribir la aplicación entera. Así, es escribir esas seis operaciones una vez más contra la API nueva y registrarla.

Además de esas seis, la interfaz pide dos cosas que no son parte de generar nada: entregar el catálogo de modelos que el proveedor nuevo sepa correr, y comprobar que las credenciales sirven sin gastar. Se escriben una vez y se olvidan, pero se escriben.

Quiero que esta aplicación deje de usar Higgsfield y use [NOMBRE DE LA OTRA API] en su lugar.

Lee lib/provider/provider.ts para ver qué operaciones hay que implementar, y lee lib/provider/higgsfield/ como ejemplo de una implementación completa. Después escribe la mía en su propia carpeta y regístrala.

No cambies nada por encima de esa costura: ni las recetas, ni la interfaz, ni el sondeo de modelos, ni cómo se muestran los precios.

Si la API nueva no puede hacer algo que la interfaz pide, dímelo en vez de inventar un rodeo.

Su documentación está aquí: [PEGA EL LINK]

Lo más probable es que nunca escribas esa segunda implementación, y la costura sigue valiendo lo mismo. Un repositorio que le habla directo a un proveedor desde todos lados es un callejón: el día que ese proveedor suba precios, cierre, cambie su API o simplemente deje de servirte para lo que haces, se tira el proyecto y se empieza otra vez desde cero.

Con la costura ese día es una carpeta nueva. Lo que construiste encima —tus recetas, tu marca, la forma en que enseñas el precio antes de cobrar— sobrevive a una decisión que tomó alguien más. Y como se escribe una implementación más y se registra, no es necesariamente una sustitución: agregar no obliga a quitar lo que ya funciona.

El archivo que declara la costura es corto y se lee de una sentada aunque no programes, porque es la lista de lo que un proveedor tiene que saber hacer, sin nada de cómo lo hace: provider.ts, en el repositorio. La carpeta de al lado, la de Higgsfield, es el ejemplo completo de cómo se llena esa lista.

Nada de esto te pide aprender TypeScript. Te pide saber que la costura existe, para que el día que la necesites le pidas a Claude Code que la use en vez de dejar que reescriba la aplicación.

El README del repositorio termina con cuatro apuntes que no son consejos generales. Son cosas que pasaron, en este código, y cada una costó horas o créditos antes de entenderse. Van aquí tal cual porque tres de las cuatro te van a morder también si construyes cualquier cosa contra una API de generación, uses esta aplicación o no.

La cuarta no tiene nada que ver con imágenes. Es un error de JavaScript de los que se ven obvios cuando alguien te los explica y no se ven nunca cuando los estás viviendo.

Lo que falta para que esto cobre

Conviene decirlo sin rodeos: traer tu propia llave es exactamente lo que no aguanta un producto de pago. Funciona de maravilla para regalar la aplicación —cada quien pone su llave, cada quien gasta sus créditos y tú no pagas la fiesta de nadie— y por eso mismo no hay nada que cobrar. En el momento en que la llave es tuya y no del usuario, todo cambia de forma.

Lo de abajo no es una lista de mejoras: es la lista de lo que hoy no existe. Ninguno de los cinco puntos es imposible, y ninguno es un rato de tarde tampoco. El orden importa: sin la llave del lado del servidor y sin límites de uso, montar el cobro primero es abrirle tu cuenta a cualquiera. Cuando llegues a esa parte, la guía de PagoKit cubre checkout, webhooks y reembolsos. Aquí solo se nombra el hueco.

• Dónde vive la llave cuando es tuya y no del usuario: deja de ser una cookie en el navegador de cada quien y pasa a ser un secreto que tú custodias y que tú pagas.
• Qué límites de uso pones para que un solo usuario no te vacíe la cuenta en una tarde.
• Cuentas, sesiones y contraseñas: hoy no hay ninguna de las tres, porque no hacían falta cuando la aplicación corre en la máquina de quien la usa.
• Dónde entra el cobro y qué pasa cuando alguien cancela a mitad del ciclo.
• Qué pasa con los resultados que caducan si el usuario ya pagó por ellos: la caducidad la pone el proveedor, la promesa se la haces tú.

Esta aplicación está hecha para que cada quien traiga su propia llave de API y la corra en su máquina. Yo quiero cobrar por ella.

Audítamela con ese objetivo y dame la lista de lo que falta, ordenada por lo que me bloquea primero:

· dónde y cómo se guardaría la llave si ahora es mía y no del usuario
· qué límites de uso hay que poner para que un solo usuario no me vacíe la cuenta
· qué hace falta para tener cuentas, sesiones y contraseñas
· dónde entraría el cobro y qué pasa si alguien cancela
· qué pasa con los resultados cuando caducan, si el usuario ya pagó por ellos

De cada punto dime qué tan grande es y qué se rompe si lo dejo para después. No construyas nada todavía.

Un dato más antes de intentar venderla: el código es MIT, pero las tipografías Satoshi y General Sans que vienen en la carpeta de fuentes van bajo la licencia gratuita de su fundidora. Si lo comercializas heredas esa licencia, y hay que conservar su archivo dentro del proyecto.