Vender el tema que has hecho: la guía del autor

Este es el otro lado del mostrador. Crear un tema termina en cuanto tu tema funciona; esta empieza ahí y acaba cuando alguien a quien no conoces lo tiene instalado, lo ha pagado y sabe a quién escribirle cuando se le rompa.

Si quien lleva la tienda eres tú y lo que quieres es meter dentro el trabajo de otros, lo tuyo es Vender temas y extensiones de otros. Aquella guía está escrita desde el panel. Esta está escrita desde tu máquina.

Casi todo vale igual para una extensión, con una diferencia que conviene decir ya: para los plugins no hay pack. pcc-plugin tiene nuevo, comprobar y dev, y nada más, así que pasas pcc-plugin comprobar y comprimes la carpeta tú — un plugin se copia dentro de plugins/, de modo que la carpeta es lo que tiene que acabar dentro del archivo.

1. De un tema que funciona a un paquete que alguien puede instalar

Tres órdenes, y responden a tres preguntas distintas. Pasar una no sustituye a pasar las otras.

npx pcc-theme validate
npx pcc-theme audit
npx pcc-theme pack

validate pregunta si eso es un tema. Comprueba theme.json, tokens.json y settings.schema.json contra los esquemas del contrato, y encima las reglas de coherencia: que una plantilla no componga una sección que no has declarado, que un ajuste tenga dónde vivir, que el manifiesto diga en qué se ejecuta. No ejecuta tu código, y por eso puede darte el visto bueno a un tema que no compila. Se publica sin un solo aviso, no con pocos: un paquete que llega con avisos le enseña a quien lo instala a pasar de largo de los avisos, y a partir de ahí el validador no vale nada para nadie.

audit pregunta qué pasaría si alguien lo instalara. Lee el código y el marcado y contesta a dos cosas: qué se ejecutaría y con quién habla. Esto para el paquete en seco:

• child_process, exec, spawn y compañía. Un tema pinta páginas; no lanza programas.
• eval o new Function, y cadenas largas en base64 descodificadas al vuelo. Así es como viaja una carga útil.
• next/font/google. La fuente se descarga mientras el tema se construye, y el panel construye los temas sin red, así que muere en el servidor de quien te compró y nunca en tu portátil, donde la fuente ya está en caché. Mete el .woff2 dentro del tema, cárgalo con next/font/local y deja su licencia al lado.
• Un script install, preinstall, postinstall, prepare o prepublish en el package.json. El instalador los bloquea igualmente, pero no deberían estar.
• No haber fichero de bloqueo de dependencias. Sin él nadie puede saber qué está a punto de descargarse el servidor de tu comprador. Dentro de este repositorio el tema no tiene bloqueo propio, así que se pasa audit --monorepo; en cualquier otro sitio, primero npm install.

Y estas salen como avisos, para leerlos y no para obedecerlos: escribir o borrar ficheros, leer variables de entorno con pinta de secreto, un next.config sin output: "standalone" y cada dominio de fuera con el que habla tu tema que runtime.hosts no declare. Un tema que se baja una hoja de estilos de un servicio de tipografías manda la dirección de cada visitante a ese servicio en cada visita, y eso en la UE es un problema legal ajeno que has creado tú. Si lo haces a propósito, decláralo.

pack pregunta si eso se puede entregar, y es la única de las tres que produce algo. En una orden valida, audita solo los ficheros que van a viajar, elige esos ficheros, les lee el contenido buscando secretos, los copia a un montaje aparte —tu carpeta no se toca—, empaqueta dentro los contratos que estés consumiendo desde una ruta local, instala, construye y escribe el .zip.

npx pcc-theme pack                          # mi-tema-1.0.0.zip
npx pcc-theme pack --salida ~/salida/mio.zip
npx pcc-theme pack --sin-construir          # solo si ya hay fichero de bloqueo

Dos cosas de esa lista se pasan por alto con facilidad, y las dos importan.

La construcción es una prueba, no un entregable. Un tema se distribuye en fuente y se construye donde se instala, que es lo que permite que el mismo paquete funcione en máquinas y versiones de Node que nunca vas a ver. pack construye una copia en el montaje solo para demostrar que compila, y después eso no entra en el archivo: .next, dist, build, .output, .astro y .svelte-kit no se empaquetan nunca, tengas lo que tengas en la carpeta.

Lo que entra es una lista de permitidos, no de exclusiones. pack sabe de qué nombres está hecho un tema —el manifiesto, los tokens, los ajustes, las plantillas, los idiomas, el contenido de ejemplo, tus carpetas de código, el fichero de configuración de tu stack, el bloqueo, el README y la licencia— y todo lo demás se queda fuera y sale escrito en pantalla para que veas qué has dejado atrás. Al revés, como lista de cosas que borrar, el fichero que se escapa es siempre el que nadie pensó en poner en la lista.

No montes el .zip a mano. Eso acaba casi siempre igual: una dependencia apuntando todavía a una carpeta de tu máquina, el paquete se instala perfectamente en tu ordenador y en ningún otro, y te enteras por un comprador.

2. Firmarlo

Una firma responde a una sola pregunta de quien instala tu tema: ¿esto es el paquete que publicó su autor, byte a byte?

pcc-theme firma con RS256 sobre un manifiesto que lleva un SHA-256 de cada fichero, más tu nombre de editor, el id del tema, su versión y cuándo se firmó. Todo eso acaba en un theme.sig al lado del manifiesto.

Firmar y empaquetar son el mismo paso. sign sobre tu carpeta de trabajo falla en cuanto hay compilados dentro, y después de un npm run build siempre los hay, así que en la práctica se firma empaquetando:

npx pcc-theme pack --key ruta/a/clave-privada.pem --publisher "Tu Estudio"

Las dos banderas o ninguna; una sola para la orden. --kid le pone nombre a la clave y vale 1 por defecto; ponle uno de verdad el día que tengas dos.

Para revisar tu propio trabajo, descomprime el archivo en algún sitio y verifícalo:

npx pcc-theme verify ./descomprimido --pubkey ruta/a/clave-publica.pem

verify es estricto a propósito: un fichero cambiado, uno que falte y uno que sobre le hacen fallar igual. El último es el útil: es el que caza algo que se coló en el archivo después de firmarlo.

Lo que ve quien te compra. Al subir el paquete, antes de instalar nada, el panel enseña un informe, y la primera línea es la firma: firmado por quién, sin firmar, o «la firma no es válida» — y esa última no se instala jamás. Un tema sin firmar sí se instala, avisando de que no se puede saber quién lo hizo ni si lo han tocado. Pero una tienda con THEMES_EXIGIR_FIRMA=1 lo rechaza sin más, y rechaza igual un tema firmado con una clave que no esté en su lista. Así que si quieres venderle a quien lleva su tienda así, publica tu clave pública y dile que la añada a THEME_TRUSTED_KEYS, con el mismo kid con el que firmaste.

La clave privada vive fuera del tema y fuera de tu repositorio. Si se te olvida, pack hace de red dos veces: un .pem no se empaqueta nunca, y una clave privada pegada dentro de un fichero de texto es uno de los patrones en los que para el rastreo de secretos.

Cómo decide el panel en quién confiar está contado en Seguridad de los temas.

3. Venderlo en el mercado de pcreative Commerce

Entrar

Te das de alta desde el escaparate de una tienda, en /vender en los temas de fábrica. La solicitud pide tu nombre, tu correo, si publicas temas, extensiones o las dos cosas, y un enlace a algo que hayas hecho — ese último no es opcional, porque sin él no hay nada que revisar. País, web, los stacks en los que trabajas y tu experiencia son opcionales y todos suman.

Un correo, una solicitud viva. Si te aceptan pasas a ser vendedor con tu propio panel, y el reparto por defecto es el 70 % de cada venta para ti. Una tienda puede acordar contigo otro; lo que vale es lo que figure en tu ficha de vendedor, no lo que diga esta página.

La pieza y sus versiones

En tu panel, en Mis piezas, creas una pieza —un tema o una extensión, con nombre, resumen, descripción, precio, enlace a la demo, licencia y los nichos a los que apunta— y luego le subes versiones.

El paquete es un .zip, y se comprueba por sus dos primeros bytes, no por el nombre: un .rar renombrado se rechaza al subirlo en vez de gastarle la tarde a quien revisa. Tiene que quedar por debajo de 60 MB (la tienda puede cambiar ese tope). Cada versión lleva su número y sus notas, y las notas son lo que de verdad leen tus compradores.

El número se compara como SemVer, no como texto. Tiene que ser mayor que cualquiera que ya hayas publicado: 1.10.0 va después de 1.9.0, y una preversión va por debajo de su versión, así que 1.4.0-beta.1 < 1.4.0-rc.1 < 1.4.0. Los metadatos de compilación detrás de un + no cuentan para nada.

Las capturas —hasta ocho— son lo que vende la cosa, y la primera es la que sale en el listado, así que pon delante la mejor. Las medidas sobre las que está montado el mercado son 2340 × 1560 para la portada, en 3:2 y nunca por debajo de 1170 px de ancho, y 1170 px de ancho para las de la galería, con 1500 de alto como máximo. Sácalas de un escaparate de verdad, con contenido de verdad. Una captura de una interfaz que no existe es una devolución con retraso.

Para mandar una pieza a revisión hace falta paquete subido, resumen escrito y precio — cero también es un precio. Mientras está en la cola no la puedes tocar: lo que se revisa es lo que se publica, y ese es justo el sentido del congelado.

La revisión, y lo que sale de ella

Tres finales, y en los tres te llega un correo. Publicada, y se pone a la venta. Cambios, con lo que hay que cambiar por escrito; lo arreglas y reenvías la misma pieza, no empiezas de cero. Rechazada, con su motivo — ninguna de las dos últimas se puede guardar sin él, así que no te vas a quedar adivinando.

Al publicarse, la pieza pasa a ser un producto: la tienda lo crea, lo ata a ti, convierte tu paquete en su descarga y tu primera captura en su imagen. Esa atadura es la que te abona tu parte cuando alguien compra. A partir de ahí el dinero sigue las reglas de siempre —30 días de espera, mínimo de 50 € y un perfil de cobro que rellenas tú—, contadas en Pagar a autores y vendedores.

Publicar una versión nueva

Una versión nueva sustituye el fichero, no añade un segundo. Todo el que ya lo compró se descarga el nuevo sin pagar otra vez, recibe un correo con tus notas y se le renueva el cupo de descargas.

Lo que deja una cosa en tus manos, y falla en silencio: si renombras o quitas un ajuste, dilo en migraciones dentro de theme.json. La personalización de una tienda se guarda aparte de tu tema, por clave. Renombra un token de color sin declarar el cambio y el tema pregunta por una clave que nadie tiene, se queda con el valor de fábrica, y el lunes la web de alguien es de otro color y te jurará que no ha tocado nada. El manifiesto acepta renombra, elimina y anade, cada bloque desde una versión desde — una lista de lo que pasó, no un guion, porque nada de lo que trae un tema se ejecuta.

El soporte, y lo que dice de ti

Cada compra incluye seis meses de soporte tuyo, y va por hilos privados uno a uno, no por un foro: en un foro la pregunta del enfadado se la lee el siguiente que se lo estaba pensando.

Para abrir uno hace falta una clave de licencia. Si el soporte se le ha acabado el hilo se abre igual, marcado, y decides tú si lo coges — cerrarle la puerta a quien te pagó es peor negocio que contestar. Un hilo esperando más de dos días sale marcado como tarde, y uno que ya has contestado se cierra solo catorce días después si el comprador no vuelve.

Al cerrarse se le hace una sola pregunta al comprador: si le sirvió. Esa respuesta alimenta los dos números de tu ficha pública —qué parte de los hilos valorados se resolvieron y tu mediana de horas hasta la primera respuesta, en los últimos 60 días— y el porcentaje no aparece hasta que han contestado tres, para que un mal día no te deje un 0 % al lado del nombre. Esos dos números los calcula la plataforma y no los editas, y por eso valen algo.

El resto de la ficha es tuyo: nombre, presentación, web, país, enlaces, logo y la lista de lo que vendes. Los enlaces tienen que empezar por https://.

4. Venderlo fuera

Dónde

Los mercados grandes con revisión están organizados por plataforma, y ninguno tiene todavía un estante de pcreative Commerce. Lo que deja dos respuestas honestas.

Tu propia tienda. Tienes en la mano una plataforma de comercio, y el mercado de autores no es un servicio que alojemos nosotros: es maquinaria que corre en cada instalación, también en la tuya. Publica tu tema como pieza en tu propia tienda y tienes las mismas descargas, versiones, licencias, correos de compra e hilos de soporte de arriba, en tu dominio y sin que ningún mercado se lleve una parte. El lado del panel es Vender temas y extensiones de otros; las reglas de entrega están en Vender productos descargables.

Un mercado generalista que acepte código independiente —plantillas, aplicaciones, esqueletos de proyecto— en vez de complementos de una sola plataforma. Te da su tráfico y juegas con sus reglas.

Cómo suelen ser esas reglas

Esto es lo que medimos en los mercados grandes con revisión mientras diseñábamos el nuestro, en septiembre de 2026. No son universales y cambian, pero se repiten lo suficiente como para planificar con ellas:

La revisión la hace una persona y tarda hasta unas dos semanas. Los rechazos vienen de dos clases y la diferencia importa: el blando trae explicación y reenvías, el duro no la trae y no se reenvía. El alta y los datos fiscales van desacoplados a propósito, así que puedes estar vendiendo antes de tener el papeleo hecho, pero no cobrando. Los pagos salen por umbral y por calendario fijo, no a petición. Los reembolsos se imputan en dos meses distintos —la venta en el mes en que fue, la devolución en el mes en que volvió—, que es por lo que tu informe de ingresos y tu extracto no cuadran nunca. Y un contracargo invalida el código de compra, que es el mercado diciéndote que el derecho a soporte se muere con el pago.

Qué pinta tiene un techo de precio

El precio es una propiedad del mercado, no del producto, y quien te dé un número sin decir de qué mercado y de cuándo está adivinando. Aun así hay una medición que merece la pena llevarse, porque habla de cómo está construido un producto y no de cómo se vendió.

En un mercado público de otra clase de software —paneles de control, no tiendas— los productos de pago de una categoría se partían limpiamente en dos en septiembre de 2026. Los construidos como complementos del framework de otro promediaban algo menos de 12 $, y ni uno solo pasaba de 17 $. Los que eran dueños de su propio render promediaban unos 21 $, y el más caro se quedaba justo por debajo de 54 $. Mismo mercado, mismos compradores, mismo mes.

La lectura no es que un número sea el correcto. Es que un producto cuyo techo lo pone lo que su framework anfitrión le deja cambiar se paga como un añadido, y un producto que decide lo que pinta se paga como un producto. Un tema de pcreative Commerce está en el segundo lado de esa raya por construcción: es una aplicación independiente que resulta que habla con una tienda por HTTP, y puede valer lo que valga su diseño. Eso es una lectura de septiembre de 2026, de una categoría y de un mercado. No la lleves por ahí como si fuera una ley.

Sobre las claves de licencia, con franqueza

theme.json tiene un bloque license_check, quien te compra pega una clave en la tarjeta del tema dentro de su panel, la verificación funciona después sin red contra una clave pública embebida, y una licencia nunca apaga un escaparate: lo único que puede negar es publicar, con el dueño delante.

Lo que todavía no existe es justo la parte que necesitarías como tercero: la activación y la renovación hablan con el servicio de licencias de pcreative, y no hay forma autoservicio de que un autor emita claves de su producto a través de él. El campo endpoint del manifiesto está reservado para apuntar a otro sitio y hoy no se lee. Así que no le prometas a quien te compra una activación por clave que no puedes emitir. Si vendes fuera de nuestro mercado, o lo acuerdas antes con nosotros, o entregas sin license_check y dejas que la entrega del propio mercado sea la prueba de compra.

5. Lo que hace que te tumben la ficha

Todo lo de arriba es el paquete. Esto es la página que lo vende, que es donde pasan de verdad casi todos los rechazos.

La portada se lee en tamaño miniatura. En una rejilla de listado son un par de cientos de píxeles de ancho, así que cuatro o cinco palabras enormes son todo el presupuesto. Los mercados suelen estampar el precio encima de una de sus esquinas, así que esa esquina se deja vacía. Y el titular dice lo que el tema hace, no cómo se llama: el nombre ya lo escribe el propio sitio debajo de la tarjeta.

Las capturas son el producto. Escaparate de verdad, productos de verdad, contenido de verdad. Imágenes de una interfaz que no existe son la forma más rápida que hay de convertir una venta en una devolución y en una reseña.

Declara tus dependencias donde el mercado las pide, en su campo, no enterradas en la descripción. Ese campo se lo leen quien revisa y quien compra; cualquier cosa que haga falta y no venga incluida —una clave de licencia tuya, una versión concreta, acceso al servidor— va ahí. Un requisito que se descubre después de pagar es una reseña de una estrella con la razón de su parte.

Y escribe como si una persona hubiera hecho una cosa. Las revisiones las hacen personas, y quien revisa tumba lo que parece hecho en cadena. Lo que lo delata casi nunca es un fichero suelto: es la uniformidad — los mismos bloques, la misma estructura y el mismo relleno repetidos idénticos entre varios productos del mismo autor. Nada de esto te pide escribir con menos cuidado. Te pide no entregar cinco veces lo mismo escrito con cuidado y el color cambiado.

6. Antes de darle a publicar: abre el paquete

Construye el .zip, ábrelo y mira dentro. Son dos minutos y es el último punto en el que algo se puede echar atrás: una descarga que ya se ha descargado no se puede retirar.

pack hace casi todo esto por ti, y conviene saber qué mitad es cuál. La lista de permitidos deja fuera categorías enteras por nombre: .env y todo lo que empieza por ahí, .pem, .key y almacenes de claves, node_modules, .git, los compilados, un licencia.json ya emitido y cualquier cosa que simplemente no forme parte de un tema. El rastreo por contenido es la otra mitad: lee línea a línea todos los ficheros de texto que están a punto de viajar, buscando claves privadas, credenciales de proveedores, cadenas de conexión con contraseña dentro y secretos asignados a mano, y para la orden en seco en vez de avisar.

Ese reparto es toda la lección. Se busca por contenido, nunca por nombre de fichero. Una lista de nombres que borrar solo te protege de las fugas que ya se te habían ocurrido, y un patrón de esa lista que no encaja con nada tiene exactamente la misma pinta que uno que funciona.

Dos sitios más donde mirar, porque un paquete limpio no es un proyecto limpio. El texto de la ficha se pega entero en algún sitio público: léelo como lo leería un desconocido. Y si publicas el código en alguna parte, el historial se lleva todo lo que se commiteó alguna vez, aunque después borres el fichero; quitarlo del commit de hoy no cambia nada, y lo único que arregla de verdad una credencial commiteada es rotarla.

7. Ofuscar: no

Sale cada vez que alguien le pone precio a su primer tema, así que aquí está el razonamiento, y es concreto de cómo viajan los temas aquí, no una opinión general.

Un tema se entrega en fuente y se construye en la máquina de quien lo compra. No hay ningún paso de compilación entre tú y él donde esconder nada: lo que ofusques es lo que instala, lo que le toca depurar y lo que se suponía que iba a poder personalizar.

Nuestro propio instalador trata la ofuscación como un ataque, y no sabe distinguir la tuya de la de nadie. audit bloquea eval, new Function y las cadenas largas en base64 descodificadas al vuelo, con el motivo escrito en pantalla: así es como se esconde una carga útil. Un tema ofuscado no vende mal, es que no instala.

Y no impide que te copien: solo le sube el precio en unas horas de trabajo a alguien que no te iba a pagar de todas formas. Lo que sí ayuda es aburrido al lado: la firma, para que una copia alterada se vea alterada y el panel lo diga en voz alta, y —donde el canal lo permita— una marca por descarga, para que un fichero que aparezca donde no debe se pueda atribuir a la copia de la que salió. Las dos necesitan ficheros legibles para funcionar. La ofuscación juega en su contra.

8. Licencias: qué emite el sistema de verdad

Para las piezas vendidas en el mercado de autores se emite una licencia por línea de pedido, cuando se cobra el pago. Un aviso de pago que llega dos veces no emite dos claves.

La clave es la credencial: no hay usuario ni contraseña. Tu producto, ya instalado en el sitio de quien te compró, habla con la tienda donde se compró usándola: POST /licencias/activar la ata a un sitio, /licencias/comprobar pregunta si sigue valiendo y /licencias/soltar libera ese sitio. La respuesta va firmada, así que tu producto puede saber que viene de la tienda donde se compró y no de algo que lo aparenta.

Una licencia, un sitio, salvo que lo diga la variante comprada — una «licencia para tres sitios» es otra variante, no otra clase de clave. La dirección se normaliza antes de contar nada, así que http://Ejemplo.com/, https://www.ejemplo.com y ejemplo.com son el mismo sitio y el puerto no cuenta; sin eso una sola web gasta tres activaciones y el comprador acaba en tu bandeja. Reinstalar el mismo sitio no cuesta. Y localhost, los rangos privados, .local, .test, staging. y dev. tampoco, porque un desarrollador que se queda sin licencia antes de publicar escribe a soporte en vez de publicar.

Reembolsa el pedido entero y sus licencias se anulan; reembolsa una parte y siguen en pie.

El soporte caduca. El derecho de uso no. La fecha de soporte va guardada en la licencia y la comprobación la devuelve junto con si sigue vigente, y eso es todo lo que gobierna. Pasada esa fecha, la licencia sigue valiendo y las versiones nuevas siguen llegando. Apagarle el producto a alguien porque se le cerró la ventana de soporte es una petición de reembolso con la mecha encendida, y no es lo que hace este sistema.

Los errores que se repiten

sign se niega diciendo que hay compilados → está hecho para eso. Firma empaquetando: pack --key … --publisher ….

audit bloquea con «no hay fichero de bloqueo» → dentro de este repositorio, añade --monorepo. Fuera de él, pasa antes npm install.

Construye en tu portátil y muere en el servidor de quien compró → casi siempre una fuente que se descarga al construir. El panel construye sin red.

Rechazan una versión por ser menor que la publicada → las versiones se comparan como SemVer, y una preversión va por debajo de su versión. 1.4.0-rc.1 no puede ir después de 1.4.0.

No puedes editar tu pieza → está en la cola de revisión, y se congela a propósito hasta que la revisión acabe.

Al subir dice que no es un .zip → se comprueba por el contenido, así que un archivo de otra clase renombrado se caza en la puerta.

Las tiendas cambiaron de color después de tu actualización → un ajuste renombrado sin su entrada en migraciones. El valor viejo sigue guardado con la clave vieja; el tema está preguntando por la nueva.

El tema se instala avisando de que no se sabe quién lo hizo → va sin firmar. Empaquétalo con --key y --publisher.

Ver también

• Crear un tema
• Escribir un plugin
• Contrato de tema
• Seguridad de los temas
• Pagar a autores y vendedores
• Vender temas y extensiones de otros — el mismo mercado, visto desde el panel