design trendsMay 8, 202614 min read

La era del software personal: aplicaciones diseñadas para ti y siete amigos.

El software personal, las aplicaciones a medida creadas por una persona para diez usuarios, están acabando con el SaaS de consumo masivo para casos de uso específicos. Esto es lo que los diseñadores deberían hacer ahora.

By Boone
XLinkedIn
the personal software era

El software para las masas es una fase, no un estado permanente. Los últimos veinte años de SaaS de consumo masivo fueron un desvío temporal provocado por el elevado coste de la distribución, y ese desvío está llegando a su fin.

Por primera vez desde los albores de la informática, una persona puede escribir una aplicación funcional un domingo para nueve usuarios específicos y publicarla antes de acostarse. Esto no es un pasatiempo. Es un cambio estructural en quién crea software, para quién se crea y qué significa incluso el diseño.

Qué es realmente el software personal

El software personal es software creado por una persona, a menudo para sí misma, a veces para diez usuarios específicos, y casi nunca para un mercado. Es personalizado por intención, no por casualidad. El creador conoce a cada usuario por su nombre.

Geoffrey Litt lleva años escribiendo sobre software maleable, la idea de que quienes usan una herramienta también deberían poder modificarla. Linus Lee crea pequeñas herramientas para su propio pensamiento. Maggie Appleton acuñó el término "desarrolladores descalzos" para referirse a la oleada de personas sin formación en ingeniería que ahora pueden lanzar software funcional gracias a la drástica reducción de costes.

Si unimos estos elementos, obtenemos una categoría: software cuyo público objetivo es el creador, junto con un pequeño grupo de amigos, familiares o compañeros, y cuyo valor reside en satisfacer las necesidades de ese reducido grupo con una precisión casi incómoda.

¿Por qué ahora y por qué no en 2015?

Dos cosas cambiaron a la vez. Los asistentes de IA hicieron que fuera económico para una sola persona crear una aplicación real en una tarde. Y los costes de distribución, alojamiento, implementación, pagos y autenticación se redujeron a cero o casi a cero.

En 2015, crear una aplicación de nicho implicaba seis meses de noches y fines de semana, una integración con Stripe que tardaba tres días y una implementación que requería una semana para consolidarse. Los números no cuadraban para nada que no fuera una startup. El amplio abanico de casos de uso era inalcanzable.

En 2026, la misma aplicación se reduce a una sola solicitud, un despliegue de Vercel y un esquema de Convex. El público objetivo mínimo para un software se redujo de decenas de miles a solo tú y siete amigos. Esto no representa una mejora en las herramientas, sino la apertura de una nueva categoría.

El tercer factor es el gusto personal. Una generación de diseñadores y aficionados al software creció con él, se formó opiniones firmes sobre los fallos de las aplicaciones que usaban a diario y ahora cuenta con los medios para solucionarlos por sí mismos sin pedir permiso a nadie.

División de vóxeles: un panel de control SaaS genérico gigante a la izquierda, diez pequeñas aplicaciones personalizadas a la derecha.
División de vóxeles: un panel de control SaaS genérico gigante a la izquierda, diez pequeñas aplicaciones personalizadas a la derecha.

Ejemplos reales, no hipotéticos

Esto no es un experimento mental. El software personal ya se ejecuta en muchos portátiles.

Hay quienes usan Notion como un mini-CMS privado para su hogar, con vistas y plantillas que no tendrían sentido para nadie fuera de la familia. Los proyectos paralelos Replit y Lovable se lanzan en una noche, los usan diez compañeros de trabajo y gestionan discretamente tareas importantes durante años. Planificadores familiares, generadores de facturas personalizados, planificadores de comidas a medida, al estilo de aplicaciones específicas como FoodplanPi, todo ello dirigido a un público de entre cuatro y quince personas.

El movimiento del software flexible está creando herramientas donde el usuario también es el editor. Tana permite a los usuarios crear sus propios sistemas de información en lugar de adaptarse a una plantilla. Capacities ofrece una funcionalidad similar. El ecosistema de plugins de Obsidian es toda una economía de herramientas personales compartidas entre personas con intereses similares.

El patrón: un creador, un público reducido, un ajuste preciso. No se busca escalar. No se comercializa. El software simplemente existe para quienes fue creado, y ese es el objetivo principal.

Diferencias con el software sin código

El software sin código se basaba en plantillas. El software personal se crea a medida. La diferencia radica en la intención.

Una herramienta sin código te da un set de Lego y te pide que construyas una casa idéntica a la del catálogo. La clave está en que miles de personas construyan casas similares en la misma plataforma. La economía depende de ello.

El software personalizado parte de una pregunta diferente: no "¿qué plantilla se ajusta a mis necesidades?", sino "¿qué requiere mi situación real y cómo lo implemento?". El desarrollador no elige entre opciones, sino que describe su intención, a menudo en lenguaje sencillo, a un asistente de IA, y obtiene un código que se ajusta a la perfección.

Esto es importante porque las herramientas basadas en plantillas tienen limitaciones. Todo lo que no se ajusta a la plantilla se modifica o se descarta, mientras que las herramientas personalizadas no tienen esas limitaciones. Si tu contabilidad necesita una columna para "la cantidad que Kyle recibe este mes con su tarifa fija del diez por ciento", simplemente la añades. Sin solicitudes a proveedores, sin retrasos en la implementación, sin esperas.

La cola larga finalmente llega al fondo

Chris Anderson describió la cola larga en 2004, pero el software nunca llegó a comprenderla del todo. El SaaS de mercado masivo podía ser rentable para el segmento superior y medio-alto de la curva de crecimiento. Todo lo que quedaba era un páramo de necesidades insatisfechas que no justificaban la creación de una empresa.

El software personal llena ese páramo. Los casos de uso que nunca fueron lo suficientemente grandes como para sustentar una startup, los flujos de trabajo de nicho, las peculiaridades domésticas, las herramientas para equipos de seis personas, ahora son el hábitat natural de las aplicaciones individuales.

Curva de cola larga de vóxeles con pequeñas aplicaciones que pueblan la cola previamente vacía.
Curva de cola larga de vóxeles con pequeñas aplicaciones que pueblan la cola previamente vacía.

La economía dio un vuelco. Un caso de uso con ocho usuarios era antes imposible de desarrollar. Ahora es trivialmente posible. Multiplique eso por un millón de micronichos y obtendrá una economía del software que no se parece en nada a las listas de las aplicaciones más populares de la App Store.

Qué muere, qué sobrevive, qué crece

No todo el SaaS será absorbido por el software personal. El cambio es desigual, y los ganadores y perdedores son predecibles si se analiza dónde reside realmente el valor.

Lo primero que muere es el SaaS de mercado masivo dirigido a casos de uso de nicho. El segmento de "somos la marca Notion para paseadores de perros". Cualquiera cuyo producto sea una especialización limitada sobre una base genérica ahora compite contra una tarde de domingo y una respuesta inmediata. Esa batalla solo tiene un final.

Lo que sobrevive y crece son las plataformas, las herramientas básicas y la infraestructura. Convex, Vercel, Supabase, Stripe, Clerk, los proveedores de IA, Replit, Lovable. La capa de herramientas básicas se expande a medida que más personas desarrollan software, no se reduce. Lo mismo ocurre con las herramientas básicas del sistema de diseño, las bibliotecas de interfaz de usuario, los conjuntos de iconos y los flujos de autenticación que todos reutilizan.

También sobrevive el software de consumo masivo, cuyo caso de uso es realmente universal. Correo electrónico, calendarios, navegadores, sistemas operativos, búsquedas, redes sociales. El software personal no reemplaza a WhatsApp. Reemplaza la herramienta de gestión de proyectos por la que una agencia de quince personas pagaba ochocientos dólares al mes.

Escena voxel de paneles de control SaaS genéricos desmoronándose por un lado, plataformas de infraestructura creciendo por el otro.
Escena voxel de paneles de control SaaS genéricos desmoronándose por un lado, plataformas de infraestructura creciendo por el otro.

Software como servicio (SaaS) para el mercado masivo vs. software personal, una al lado de la otra

El cambio se aprecia mejor al comparar ambos modelos.

| Dimensión | SaaS para el mercado masivo | Software personal |

|-----------|------------------|-------------------|

| Público objetivo | De miles a millones | De una a unas pocas docenas |

| Posicionamiento | "Para equipos que X" | "Para mí y siete amigos" |

| Distribución | Anuncios pagados, SEO, equipo de ventas | Enviado en un chat grupal |

| Precio | Suscripción mensual por usuario | Tarifa plana, donación o gratis entre amigos |

| Prioridad de diseño | Incorporar a un desconocido en sesenta segundos | Adaptar perfectamente a una persona conocida |

| Personalización | Menú de configuración, indicadores de funciones | Editar el código fuente, solicitar a la IA que lo modifique |

| Objetivo de vida útil | Indefinida, con nuevas funciones constantes | Mientras dure el caso de uso, luego archivado |

| Incentivo para el creador | Capturar un mercado | Resolver un problema específico |

Observe la fila de prioridad de diseño. Ahí es donde el rol del diseñador cambia más.

El nuevo trabajo del diseñador

Si eres diseñador, el trabajo se transforma. El diseño para el mercado masivo se centra en integrar a usuarios desconocidos, minimizar las dificultades en el peor de los casos y nunca presuponer un contexto. El diseño de software personal presupone un contexto, identifica a los usuarios y optimiza la adecuación, no la generalidad.

El nuevo trabajo de diseño se basa en tres pasos fundamentales: Definir el contexto. Aplicar el criterio. Editar.

Definir el contexto consiste en explicar a un asistente de IA o a un equipo pequeño a quién va dirigido el proyecto para que el resultado sea adecuado. No se trata de "diseñar un planificador de comidas", sino de "diseñar un planificador de comidas para una familia de cuatro personas donde una es vegetariana, los niños odian las texturas y quien cocina dispone de treinta minutos entre semana". El briefing es el diseño.

El criterio es el filtro. Cuando el código es económico y las sugerencias son gratuitas, el cuello de botella reside en la calidad del resultado. El trabajo de un diseñador consiste en saber qué aspecto tiene un buen diseño para este público específico y rechazar todo lo que no se ajuste. Menos dibujo, más análisis.

La edición es la iteración. El software personal no se entrega a los ingenieros y se lanza al mercado, sino que se va perfeccionando con el tiempo, a menudo en tiempo real, por el diseñador, quien también es el creador o trabaja codo a codo con él. El archivo Figma ya no es el producto final. La aplicación en funcionamiento sí lo es.

Cómo diseñar para un público de 10 personas

Diseñar para diez personas no es una versión reducida de diseñar para diez mil. Es una disciplina diferente. Aquí tienes siete principios fundamentales.

  1. Identifica a cada usuario. Literalmente, haz una lista. Averigua qué necesita cada persona, qué odia y qué tolera. Si no puedes redactar ese documento, sigues diseñando para una abstracción.

  2. Omite la formación inicial. Tus usuarios no necesitan un tutorial; son tus amigos. Incorpóralos a la aplicación ya configurada para ellos. Dales la respuesta predeterminada en lugar de la pregunta.

  3. Optimiza para lo específico, no para el promedio. El usuario promedio no existe cuando hay diez. Solo están Aaron, a quien le gusta el modo oscuro, y Serina, que necesita el atajo de teclado. Ambos obtienen lo que quieren.

  4. Permite que sea imperfecto en los lugares adecuados. El software personal no necesita un sitio web de marketing, una página de precios ni una ilustración principal. La pantalla de inicio puede ser una lista, la configuración puede ser un archivo JSON. Invierte en lo que se siente, no en lo que se espera.

  5. Hazlo editable. Tus usuarios querrán hacer cambios. Diseña de forma que esos cambios sean fáciles, incluso si eso significa una interfaz ligeramente menos pulida. La adaptabilidad es más importante que el pulido a esta escala.

  6. Diseña para un dispositivo, no para todos. Si tu público usa la aplicación en una computadora portátil, ignora la versión móvil. Si la usan en un teléfono, ignora la versión de escritorio. El diseño responsivo universal es una mentalidad orientada al mercado masivo.

  7. Planifica para el archivo, no para la eternidad. Este software no necesita durar para siempre. Debe funcionar mientras exista el caso de uso. Cuando el caso de uso termine, archívalo sin ceremonias.

Espacio de trabajo de vóxeles con etiquetas de nombre, notas de contexto y una clara idoneidad para un público pequeño.
Espacio de trabajo de vóxeles con etiquetas de nombre, notas de contexto y una clara idoneidad para un público pequeño.

La ola de desarrolladores descalzos

El término "desarrolladores descalzos" de Maggie Appleton capta algo que la industria había pasado por alto. La próxima generación de creadores de software no son ingenieros que aprendieron a diseñar. Son diseñadores, escritores, investigadores, contadores, profesores y operadores que aprendieron a distribuir.

Estas personas nunca iban a acceder a un puesto de ingeniería con un salario de seis cifras. Tienen trabajos, vidas y problemas específicos que quieren resolver. Lo que tienen ahora es la capacidad de describir lo que quieren en inglés, obtener código funcional y ejecutarlo en una computadora portátil o en una implementación gratuita.

Este es el tipo de personas que, en su mayoría, crean software personal. No son fundadores a tiempo completo. Personas con un profundo conocimiento del dominio, escasa experiencia en ingeniería y la paciencia necesaria para iterar con un asistente de IA hasta que funcione. El resultado es software diseñado por personas que realmente comprenden el problema, un tipo de software del que la industria carecía.

Como consecuencia, el criterio de diseño en el software personal tiende a ser más exigente que en el SaaS de consumo masivo. El desarrollador no es un gerente de proyecto junior con una hoja de ruta que defender, sino la persona que vive el problema. Si detecta algún fallo o problema, lo corrige al instante. El ciclo de retroalimentación es tan rápido que un mal diseño no puede sobrevivir ni un fin de semana.

¿Qué cambia en la creación de software?

Cuando el público es reducido y el desarrollador está cerca, la creación de software cambia. Los valores predeterminados se modifican. Las compensaciones se resuelven de forma diferente.

La fiabilidad se vuelve más tolerante. Si la aplicación falla para diez usuarios, el desarrollador se entera en un chat grupal y la soluciona. No hay acuerdo de nivel de servicio (SLA), ni turnos de guardia, ni escalamiento. Esto suena mal hasta que te das cuenta de que la supuesta fiabilidad del SaaS para el mercado masivo suele ser un coste para el usuario.

La personalización se convierte en la opción predeterminada, en lugar de una funcionalidad. El software para el mercado masivo trata la personalización como un menú de configuración, una lista de opciones que el desarrollador añadió a regañadientes, mientras que el software personal la considera fundamental. Si quieres añadir una columna, el desarrollador la añade, y si quieres cambiar los colores, se cambian. El producto no tiene una interfaz fija que se reevalúe con una hoja de ruta trimestral.

La documentación es diferente. Un archivo README para una herramienta con diez usuarios es un párrafo de contexto, una captura de pantalla y el número de teléfono del desarrollador. La base de conocimientos de treinta páginas, el tutorial integrado, los artículos de ayuda, el widget de chat: todo eso supone una carga innecesaria para un público reducido.

Las opciones de rendimiento cambian. Puedes lanzar una aplicación más lenta para diez usuarios de confianza porque te avisarán cuando les resulte molesta. No puedes lanzar una aplicación lenta para un millón de desconocidos. El software personal se libra de muchas optimizaciones prematuras.

¿Qué significa para la ética, las carteras y los precios?

El software personal plantea interrogantes importantes sobre la propiedad de los datos, la dependencia del proveedor y la longevidad, y las respuestas son, en general, mejores que las que nos ofreció el SaaS. Los datos residen donde tú los guardas, a menudo en tu propia base de datos o en un archivo que controlas. La dependencia del proveedor es menor porque el creador está presente, no un proveedor con motivos para mantenerte atrapado.

La longevidad es el aspecto más complejo. El software personal deja de funcionar cuando su creador deja de darle mantenimiento, algo que sucede. La verdad es que esto no supone un problema. La mayoría del software no debería durar para siempre, y la contrapartida de la idoneidad y la propiedad es aceptar que la aplicación pueda durar dos años y luego desaparecer.

El modelo de precios cambia porque la unidad de valor cambia. Las suscripciones mensuales por usuario presuponen un mercado. El software personal tiene clientes, no consumidores, y los clientes pagan de forma diferente.

Tarifas fijas por proyecto, contratos de mantenimiento para revisiones continuas, economía colaborativa entre amigos, pagos por funciones específicas. El creador no gestiona un SaaS. Gestiona un pequeño estudio de software personalizado o desarrolla software gratis para personas importantes. Ambas opciones son económicamente viables hoy en día.

Para los diseñadores que venden sus servicios, la tendencia es pasar de "diseñar un sistema para el lanzamiento de un SaaS" a "diseñar y desarrollar una herramienta a medida para un equipo o familia específicos". El resultado final es la aplicación en funcionamiento, no el archivo Figma. El precio se basa en el valor del problema resuelto, no en las horas facturadas.

En los portafolios, el trabajo tendrá un aspecto más peculiar. Menos sitios web de marketing pulidos y más capturas de pantalla de herramientas internas poco convencionales que resuelven problemas reales para grupos reales. El caso de estudio no es "rediseñamos un panel de control para una startup de la Serie B", sino "creamos una herramienta para organizar excursiones escolares para treinta padres y, de hecho, se utilizó".

Qué deberían hacer los diseñadores este año

El cambio se está produciendo, participes o no. Así es como se ve la estrategia inteligente en 2026.

Empieza a crear para ti mismo. Elige un problema real, en tu vida personal o profesional, y crea la herramienta usando Replit, Lovable, Cursor o simplemente Claude Code y una cuenta Vercel. El objetivo no es aprender las herramientas, sino experimentar lo que se siente al ser el equipo completo de un software.

Empieza a crear para diez personas que conozcas. Después de una herramienta personal, crea una para un grupo pequeño: una familia, un club, un equipo de trabajo. Observa cómo cambian las decisiones de diseño cuando conoces a cada usuario por su nombre.

Deja de centrar tu trabajo de diseño en la perfección para el mercado masivo. Reenfoca tu enfoque. El mercado ya no busca una "incorporación sin fricciones para un público masivo". Busca "adaptación, buen gusto y la capacidad de lanzar el producto final". Demuéstralo en tu portafolio.

Presta atención a la escritura de software flexible. Litt, Lee, Appleton, la comunidad de Ink y Switch, los desarrolladores de herramientas pequeñas en Twitter y Threads. El vocabulario, los patrones, el lenguaje de diseño del software personal se está formando en esas conversaciones ahora mismo. Domínalo.

La era del software personal es lo más interesante que le ha sucedido al diseño de software en quince años. El SaaS para el mercado masivo seguirá existiendo en las categorías donde tenga sentido. Pero el nicho de mercado se ha abierto, y quienes lleguen primero definirán qué significa diseñar para un público de diez personas. Sé uno de ellos.

image-requirements
hero: key: hero prompt: "Voxel illustration. A small house-sized app glowing warmly, with 10 little floating screens around it, each tailored to a different person. Soft pastel. Editorial. The composition does not include any human figures." alt: "Voxel illustration of a small house-sized app glowing warmly with ten tiny tailored screens floating around it" width: 1600 height: 900 inline-1: key: mass-vs-personal prompt: "Voxel split illustration: left, a giant generic SaaS dashboard. Right, ten tiny bespoke apps, each warm and specific. Soft pastel. The composition does not include any human figures." alt: "Voxel split image showing one giant generic SaaS dashboard on the left and ten tiny bespoke apps on the right" width: 1400 height: 900 inline-2: key: distribution-collapse prompt: "Voxel illustration showing a long-tail curve labeled 'use cases' with tiny apps populating the previously-empty tail. Soft pastel." alt: "Voxel long-tail curve labeled use cases with tiny apps filling the previously empty tail" width: 1400 height: 900 inline-3: key: design-for-ten prompt: "Voxel illustration of a designer's workspace tuned for an audience of 10: name tags on the wall, context notes, an obvious local fit. Soft pastel. The composition does not include any human figures." alt: "Voxel designer workspace with name tags and context notes tuned for an audience of ten" width: 1400 height: 900 inline-4: key: what-dies-what-survives prompt: "Voxel illustration: on one side, generic SaaS dashboards crumbling into mist. On the other, infrastructure platforms growing taller. Soft pastel. The composition does not include any human figures." alt: "Voxel illustration of generic SaaS dashboards crumbling on one side and infrastructure platforms growing on the other" width: 1400 height: 900

Want help designing software for ten people instead of ten thousand? Brainy ships personal software with the same craft as our biggest brand work.

Get Started

More from Brainy Papers

Keep reading