Cero superficie de red, y por qué eso decide el modelo de negocio
Cero superficie de red: una utilidad de escritorio sin código de conexión, y por qué el pago único se deriva de la arquitectura y no del marketing.
- copy-on-select
- arquitectura
- privacidad
- escritorio
- producto
- microsoft store
Dos gestos para algo que hago cientos de veces al día
Copiar texto son dos gestos: seleccionar y pulsar la combinación de teclas. Parece trivial y lo es, hasta que cuentas cuántas veces al día lo haces. El coste no está en el gesto: está en la interrupción, en confirmar con la mano algo que ya habías decidido al soltar la selección.
El mercado resuelve el problema de al lado. Los gestores de portapapeles atacan el historial —qué copiaste antes, cómo recuperarlo— y no el gesto. Y la mayoría sincroniza lo copiado con un servidor, porque el historial compartido entre dispositivos es la función que justifica la suscripción.
Ahí está el verdadero problema de diseño, y no es de usabilidad. El portapapeles es una de las superficies más sensibles de un equipo: por ahí pasan contraseñas, identificadores fiscales, números de cuenta, documentos privados y código con credenciales dentro. Cualquier producto que se engancha ahí tiene que resolver la confianza antes que la funcionalidad. Si no la resuelve, la función no importa: es un keylogger con buenas intenciones.
Con eso, el requisito principal de Copy-on-Select no fue "que copie al seleccionar", sino que un usuario razonablemente desconfiado pudiera instalarlo sin fiarse de mi palabra.
Cuatro decisiones, y una que restringe a las otras tres
Cero red, verificable por ausencia
La aplicación no tiene código de conexión. Ninguno. No hay cliente HTTP, no hay socket, no hay telemetría, no hay comprobación de licencia contra un servidor, no hay "buscar actualizaciones".
Esto no es una política de privacidad: es una propiedad estructural. Lo que copias no puede salir de tu máquina porque no existe la ruta de salida. La diferencia con la formulación habitual es enorme y no es de marketing. "No enviamos tus datos" y "sincronización desactivada por defecto" trasladan la confianza a mi palabra y a un interruptor, y obligan a creer que ese interruptor seguirá haciendo lo que dice en la próxima versión. "No hay código de conexión" es comprobable desde fuera: cualquiera puede inspeccionar el paquete o monitorizar el tráfico de la máquina sin preguntarme nada.
Trade-off aceptado: renuncio a todo lo que la red regala —telemetría, retención medida, actualizaciones silenciosas, control de licencia, sincronización— a cambio de una afirmación que el usuario puede verificar. Trabajo a ciegas sobre el comportamiento de mis usuarios: es un precio alto y lo pago entero, porque en este dominio la confianza es la funcionalidad.
Sin interfaz, sin atajo, sin configuración
La utilidad no tiene ventana. No hay panel de ajustes, ni icono con menú, ni atajo que memorizar. Se instala y el comportamiento del sistema cambia: al soltar la selección, el texto está en el portapapeles.
El razonamiento es directo: si el producto existe para eliminar un gesto, añadir gestos para gestionarlo lo invalida. Una pantalla de ajustes habría quedado mejor en la ficha de la tienda y habría sido un producto peor.
Trade-off aceptado: pierdo casos límite legítimos (excluir una aplicación, desactivarlo un rato) y material visual para vender, a cambio de que no exista superficie de configuración que aprender, mantener ni documentar. Cero configuración también significa cero soporte por configuración mal puesta.
El pago único se deriva de la arquitectura
Este es el punto que más me interesa, y suele contarse al revés. Lo habitual es decidir primero el modelo de negocio —queremos ingresos recurrentes— y buscar después la función que lo justifique. En un gestor de portapapeles esa función es casi siempre la sincronización: si hay servidor, hay coste recurrente; si hay coste recurrente, hay cuota defendible.
Aquí el orden es el inverso: la arquitectura decidió el precio. Una utilidad que corre en el equipo del propio usuario, sin servidor porque no hay servidor, no tiene coste recurrente que justifique una cuota recurrente. Cobrar suscripción sería cobrar por nada, y eso obliga tarde o temprano a inventar la función de servidor que la justifique: a romper la decisión anterior. Precio: 4,99 USD, 5,29 €, pago único.
Trade-off aceptado: renuncio a ingresos recurrentes y al valor que se les asocia, a cambio de coherencia entre lo que el producto es y lo que cobra. La consecuencia es que mi ingreso depende de altas nuevas y no de retención: sin distribución, la curva se aplana. Es exactamente lo que pasó.
Empaquetado firmado y distribución por la tienda oficial
Para una utilidad que se engancha al portapapeles del sistema, la firma digital y el canal oficial no son burocracia: son la única prueba de procedencia que el usuario puede comprobar antes de instalar. Un ejecutable descargado de una web, con la misma promesa de privacidad, es indistinguible de una versión modificada por un tercero.
Trade-off aceptado: la comisión, los tiempos de revisión y quedar sujeto a cambios de política que no controlo, a cambio de que la cadena instalación-firma-editor sea verificable.
El diagrama, donde lo importante es lo que no aparece
En este diagrama no hay que mirar los nodos. Hay que mirar la ausencia de flechas que cruzan el límite de la máquina. Todo el flujo ocurre dentro del recinto cerrado. El nodo de red está dibujado suelto, sin una sola arista que lo conecte con nada, porque no existe el código que la dibujaría.
Equipo del usuario · límite cerrado
Qué descarté y por qué
Sincronización opcional desactivada por defecto. El modelo estándar del sector. Si el código de red existe, la garantía depende de un interruptor y de que el usuario se fíe de mí. Un interruptor es una promesa de política; la ausencia de código es una propiedad.
Historial de portapapeles. La función que todo el mundo espera. Ataca un problema distinto, y guardar en disco el histórico de todo lo copiado crea justo el activo sensible que la arquitectura de cero red existía para evitar. No sirve de nada no tener salida a internet si dejas el material listo en un fichero local.
Comprobación de licencia en línea y telemetría. Cualquiera de las dos, por sí sola, convierte "no hay ruta de salida" en falso y tira el argumento entero.
Suscripción. Incoherente con una arquitectura sin coste recurrente.
Web propia como canal principal. Elimina la prueba de procedencia justo en la categoría donde el usuario más necesita comprobarla.
Estado real
Copy-on-Select está publicado y facturando. Nada de esto es diseño ni propuesta. Y aquí conviene separar dos cifras que es facilísimo confundir, porque van en la misma pantalla de la tienda:
- Ingreso del producto: 8,58 USD netos, 2 ventas. Eso es todo lo que ha facturado Copy-on-Select desde que se publicó, el 21 de junio de 2026. Tres semanas de vida, sin una sola acción de distribución. No impresiona a nadie y no pretende hacerlo: lo relevante es que factura solo.
- Payout de la cuenta: 423,18 USD liquidados el 15 de julio de 2026. Esa cifra no es de esta aplicación: es el pago acumulado de una cuenta de vendedor con 266 productos, incluido atraso retenido que se liberó al resolverse una disputa. Atribuirla a Copy-on-Select sería multiplicar por 49 el ingreso real de un producto, y cualquiera con acceso al informe lo desmiente en un minuto.
- Precio: 4,99 USD / 5,29 €, pago único, sin suscripción.
- Disponible aquí: apps.microsoft.com/detail/9pcvrvr3qqks
- Primera submission a un directorio externo enviada el 1 de agosto de 2026: la primera acción de distribución fuera de la tienda en toda la vida del producto.
Y un dato propio al lado del trade-off del canal oficial: en mi cuenta de vendedor hay 263 aplicaciones publicadas y solo 23 quedaron visibles. La tienda ocultó 240 al aplicar su política contra el repaquetizado. Esa es la factura real de depender de un canal que no controlas, y no es la comisión: es que el 91% de tu catálogo puede desaparecer de los resultados por un cambio de criterio ajeno, sin que nada de tu producto haya cambiado.
Lecciones transferibles
Restringir la arquitectura puede ser la mejor decisión de producto. "No tiene código de red" es una frase que un usuario entiende en cinco segundos, puede comprobar por sí mismo y convence más que nueve párrafos de política de privacidad. Quitar capacidad al sistema fue lo que hizo el producto vendible.
Prefiere propiedades estructurales a promesas de política. Cuando puedas convertir una garantía en algo que se cumple por construcción —porque no existe el código que la violaría— hazlo. Sobrevive al siguiente refactor y a tu tentación de añadir "solo una métrica".
Deriva el modelo de negocio de la arquitectura, no al revés. Si tu producto no tiene coste recurrente, cobrar una cuota recurrente te empuja a construir la pieza que la justifique, y esa pieza suele ser la que habías decidido no tener. El precio es consecuencia del sistema, no una capa encima.
Un canal con procedencia verificable es también un canal con poder sobre ti. Hay que elegir sabiendo las dos cosas. 23 de 263 es el precio que llevo pagado.
La lección incómoda. A este producto no le faltaba desarrollo: le faltaba distribución. Se publicó en junio, facturó solo, y no recibió una sola acción de distribución hasta el 1 de agosto; en ese tiempo dediqué las horas a proyectos con cero canal, cero producto acabado y cero ingresos. Un producto abandonado no factura; uno desatendido factura solo, y muy por debajo de su techo porque nadie lo empuja. Eso es más caro que un fallo de arquitectura, y no se arregla escribiendo código.
Versión corta en LinkedIn: Le quité el código de red a una utilidad, y eso decidió el precio (linkedin.com/in/carlosdelatorre-ai)