Lo que aprendí al operar un negocio durante 4 años en un mercado SaaS ferozmente competitivo

xguru · 2025-04-14T11:01:01+09:00

OnlineOrNot, fundada por Max Rozen, comenzó en un mercado donde ya existían más de 200 productos competidores Al principio, muchos productos eran difíciles de usar, y después aparecieron muchísimos competidores que desaparecieron rápidamente Algunos competidores recibieron financiamiento de VC y fueron adquiridos por grandes empresas, lo que llevó a un deterioro gradual de la experiencia de usuario OnlineOrNot apunta a ser un negocio sostenible a largo plazo operado con fondos propios El autor sigue manteniendo un trabajo de tiempo completo mientras desarrolla su SaaS de forma constante Escribe una retrospectiva cada año, y algunas lecciones que aprendió en el pasado con el tiempo demostraron estar equivocadas Principios que no han cambiado Aunque ha aprendido mucho sobre cómo operar un negocio a lo largo de los años, todavía hay principios clave que siguen intactos Invertir 2 horas cada día laborable Desde antes de empezar OnlineOrNot, dedicaba 2 horas cada mañana antes de ir al trabajo a proyectos personales Aprovechó ese tiempo para completar cientos de textos, un libro y varios proyectos de software Más importante que cuánto inviertes en un solo día es el esfuerzo constante todos los días Para asegurar ese tiempo, se despierta 2 horas más temprano y ajusta su rutina No hacer otros side projects Como dice el refrán, “el que mucho abarca, poco aprieta”: se enfoca en una sola cosa Algunas personas excepcionales logran sacar adelante varios proyectos, pero reconoce que él no es así Considera que el tramo de $0 a $500 de MRR es el más difícil y que no vale la pena repetirlo Se concentra en un modelo que ya funciona, y elige su forma de hacer marketing con esa misma lógica Lo primero es resolver el dolor del cliente Cuando un usuario se registra, se le envía un email automático preguntando: “¿Por qué te registraste?” Lee todos los correos y responde personalmente, y eso se convierte en una fuente clave de insights para mejorar el producto Identifica lo que les incomoda a los usuarios y lo resuelve de verdad Iterar y mejorar con persistencia Si alguna tarea no puede desplegarse en 2 horas, reduce el alcance y la lanza primero No siempre logra ajustarse exactamente a 2 horas, pero prefiere lanzar rápido una primera versión y luego expandir la funcionalidad Si intenta construir todo antes de desplegar, termina perdiendo motivación y enfoque Completar funciones gradualmente detrás de feature flags resulta mucho más efectivo Lecciones aprendidas Leer unos pocos libros y luego ponerse a construir Al empezar, leyó decenas de libros de negocios para cometer menos errores Pero al final se dio cuenta de que la forma más efectiva de aprender es equivocándose uno mismo Ejemplo: llegó a la portada de Hacker News y recibió 6000 visitas, pero solo una cantidad de un solo dígito llegó realmente hasta la app Solo en el formulario de registro abandonaba el 75% → con una sola opción de login por OAuth, la tasa de abandono mejoró hasta 50% Si volviera a empezar, solo leería estos tres libros y arrancaría de inmediato: The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Si necesitas detalles prácticos sobre operar un SaaS, también recomienda The SaaS Playbook (Rob Walling) Antes que vender suscripciones, resolver problemas El objetivo de un SaaS no es vender suscripciones, sino resolver el dolor del cliente Hace falta cambiar la mentalidad de “si sigo construyendo funciones, algún día la gente las usará” a “resolvamos los problemas frustrantes del trabajo del usuario” El SaaS es solo una manera de resolver problemas; también se puede abordar con screencasts, documentación, escritura, libros, talleres, muestras de código y más Construir pequeño y desplegar seguido Los usuarios proponen ideas de funciones, pero en la práctica casi no las usan Quien empieza por primera vez con un SaaS puede emocionarse solo por hablar con alguien y terminar construyendo funciones sin pensar demasiado Hay que preguntar cómo usarían esa función e investigar cómo otros usuarios resuelven ese problema, y luego implementarla primero con la mínima funcionalidad posible para validar la reacción Más importante que crear una “función copo de nieve” que solo usa una persona es tener un enfoque estratégico para construir funciones que use mucha gente Duele eliminar una función en la que invertiste unas horas, pero duele mucho más eliminar una en la que invertiste meses Lanza primero y preocúpate por escalar después La primera versión de OnlineOrNot salió rápido sin optimización arquitectónica De hecho, había un bug que limitaba el sistema a unas 100 verificaciones, y cuando ocurría un problema, la UI solo mostraba “Error!”, así de incompleto estaba Aun así, el autor prefirió recibir críticas por una UI incompleta antes que construir funciones innecesarias Como no había garantía de que llegarían miles de usuarios desde el principio, era más importante validar rápido Como solución temporal, subió la base de datos a un plan superior para aumentar la capacidad de verificaciones En pocas horas, refactorizó la estructura para procesar millones de verificaciones y también mejoró la pantalla de error Operar un programa de early access En las primeras etapas del desarrollo del producto, la mayoría de los usuarios es relativamente tolerante con funciones incompletas Con el tiempo, aumenta la cantidad de usuarios que espera un producto más maduro Para resolver eso, agregó a cada cuenta de usuario una casilla de “participar en el programa de early access” Quienes participan prueban primero las funciones nuevas todavía no terminadas y dan feedback Funciona bien como una forma de equilibrar pruebas y retroalimentación Introduce la prueba gratuita lo antes posible Hoy en día es común el consejo de “los planes gratuitos son demasiado difíciles de equilibrar, así que mejor no los hagas” Sin embargo, al principio el plan gratuito fue efectivo para el boca a boca y la adquisición de usuarios La desventaja es que, si el plan gratuito difiere mucho de las funciones pagadas, necesitas una forma de probar las buenas funciones Recién 11 meses después del inicio agregó en el onboarding la pregunta “¿Quieres iniciar una prueba gratuita?” En realidad eso significa lo siguiente: > “¿Quieres probar las buenas funciones durante 14 días y luego decidir, o prefieres usar durante meses una versión limitada y terminar decepcionado?” Después, como experimento, empezó a ofrecer la prueba gratuita por defecto a todos los usuarios, y solo ese experimento hizo que la tasa de crecimiento mensual se duplicara con creces Conclusión: El mensaje “este es un servicio de pago; para seguir usando las buenas funciones necesitamos tu información de pago” es mucho más efectivo para el negocio que “este es un servicio gratuito; tal vez sea de pago si lo usas mucho” La documentación es parte del producto Antes era común decir “los desarrolladores no leen documentación”, pero eso es completamente falso Algunos de sus clientes ideales elogiaron la documentación de OnlineOrNot, y eso lo llevó a invertir seriamente en ella También construyó por su cuenta la documentación de la API para tener control total de la experiencia de usuario Al observarlo con herramientas de analítica de producto, vio lo siguiente: Si el usuario tiene un problema en la UI, revisa la documentación y encuentra la función, sigue usando el producto Si no encuentra la información que busca, no crea verificaciones y abandona La calidad de la documentación está directamente ligada a la retención de usuarios Diseña el producto pensando en móvil Contra lo que mucha gente cree, los usuarios de SaaS B2B también empiezan su trabajo desde el smartphone De hecho, alrededor del 50% de los usuarios empieza a usar el producto desde móvil Crean una cuenta, registran algunas páginas y luego vuelven a revisar desde la PC Durante los primeros 6 meses no tuvo en cuenta el entorno móvil, y la mayoría de quienes se registraban desde móvil se iba Después, al introducir una UI responsive, la retención de usuarios móviles aumentó de forma visible Pregunta directamente a los usuarios de dónde vienen Uno de los cambios de código más valiosos que introdujo a mitad del primer año fue agregar en el registro la pregunta “¿Dónde conociste OnlineOrNot?” Entender los canales de adquisición es muy importante para maximizar la eficiencia del marketing Existen decenas de canales de marketing, pero los recursos para enfocarse son limitados Cuando identificas un canal que funciona, invierte en él con foco y sigue haciéndolo hasta que deje de responder No usar herramientas de analítica intrusiva Al principio introdujo session tracking y herramientas de análisis de funnel como cualquier producto SaaS común, pero su efectividad fue baja Puede ser útil para equipos grandes, pero en servicios pequeños es fácil confundir resultados aleatorios con señales reales Como fundador solo, con apenas 2 horas cada mañana, en vez de analizar montañas de datos, le resultó más efectivo pedir opinión directamente a un grupo de usuarios de confianza (inner-circle) Recibía feedback más intuitivo sobre funciones o problemas y mejoraba el producto con juicio basado en sensibilidad Habla con prospectos aunque todavía no tengas la función Un día, un CTO le preguntó si soportaban cierta función Su idea original era responder “lo siento, todavía no”, pero por curiosidad preguntó qué problema estaban enfrentando y qué objetivo querían lograr también le preguntó a usuarios del inner-circle si tenían ese mismo problema compartió ideas sobre cómo podría diseñarse esa función Como resultado, ese CTO se convirtió en cliente de pago al día siguiente y sigue siéndolo hasta hoy Esa función también ha sido útil para otros usuarios Pasé más tiempo construyendo la plataforma que resolviendo el problema Durante los últimos 4 años, más de la mitad del tiempo de desarrollo se fue en construir la plataforma SaaS El objetivo original, “comprobar si un sitio web está caído y enviar alertas”, era solo una parte Las funciones que realmente hacían falta eran: distintos métodos de autenticación y gestión de usuarios pruebas, onboarding tareas repetitivas de DB, gestión de equipos, manejo de facturas emails de lifecycle, etc. Algunas cosas se externalizaron con servicios como Stripe, pero muchas otras requerían manejo directo o personalización, así que terminó implementándolas por cuenta propia Poner precios es realmente difícil Si el precio es demasiado alto, suben las expectativas o la gente ni siquiera se registra Si el precio es demasiado bajo, puede pasar que un usuario que paga $9 exija que le adaptes toda la app a su gusto La solución: a los clientes difíciles se les devuelve el dinero y se les deja ir se sube el precio y se sigue adelante especialmente al principio, a medida que expandes funciones, es indispensable experimentar continuamente con precios No te obsesiones solo con el MRR MRR (Monthly Recurring Revenue) puede ser una métrica inadecuada para medir el desempeño del negocio Como lo que hiciste hace semanas o meses impacta el MRR de hoy, es difícil medir efectos en tiempo real En algunos productos SaaS, desde que un usuario se registra hasta que realmente paga pueden pasar más de 60 días Por eso conviene usar otras métricas para saber si realmente están usando el producto y si están recibiendo valor Por ejemplo: número de imágenes generadas, formularios enviados y otras métricas de éxito basadas en comportamiento Nunca ofrezcas “ilimitado” Siempre existe el usuario whale que explotará al máximo lo “ilimitado” Ejemplo: clientes que pagan solo $250 al mes y consumen una cantidad enorme de recursos Si la unidad que ofreces como ilimitada genera un costo, vas a perder dinero sí o sí Este consejo también aplica a los lifetime deals Si prometes uso de por vida por $100, durante años pueden seguir exigiendo nuevas funciones Y si usaste un marketplace de terceros, quizá en realidad solo recibas el 30% de ese ingreso Al final, terminas invitando no a clientes reales, sino a usuarios que buscan beneficio de corto plazo y se quedan amarrados durante mucho tiempo Todo recurso pagado debe tener rate limits Si usas APIs pagadas como IA, SMS o envío de email, limitar el uso es obligatorio “Pero si son clientes de pago, ¿no deberían poder usarlo sin límite?” → puede haber excepciones, pero en la mayoría de los casos eso implica riesgo de costos descontrolados o de que el proveedor te marque como spam Caso real: un servidor que alojaba cientos de sitios WordPress sufrió errores por falta de RAM como resultado, se enviaron automáticamente miles de alertas por SMS, generando un costo enorme Si de verdad un cliente necesita un volumen masivo, te va a contactar directamente No intentes explicarlo todo en una sola página > “Si intentas decirle todo a todos, no le terminas diciendo nada a nadie” Esta frase aplica especialmente bien al copywriting de landing pages Cada vez que OnlineOrNot añadía una función, seguía agregando explicaciones a la landing principal, y eso hizo que el mensaje se volviera confuso y la comprensión del usuario bajara por ejemplo, Slack notifications fue la segunda función que creó, pero mucha gente ni siquiera sabía que existía Solución: crear landing pages separadas para cada función Principal: https://onlineornot.com/ Monitoreo de uptime: https://onlineornot.com/website-monitoring Monitoreo de API: https://onlineornot.com/api-monitoring Status pages: https://onlineornot.com/status-pages Monitoreo de cron jobs: https://onlineornot.com/cron-job-monitoring Así, cada página tiene suficiente espacio para comunicar claramente la función Aumentar el tráfico es difícil; mejorar la conversión sí puede hacerse hoy Llamar la atención en internet es una carrera de fondo y muy lenta incluso con content marketing constante y de calidad, pasar de 1 o 2 visitas a cientos puede tomar meses o años No es fácil aumentar el tráfico en sí En cambio, sí puedes cambiar hoy mismo el comportamiento de quienes ya llegaron por ejemplo, agregar una opción de login con OAuth al formulario de registro: una mejora aplicable hoy que puede subir la conversión Los competidores no importan tanto La razón por la que en todo este texto casi no se habla de competidores es que en realidad no tienen tanto impacto Claro, necesitas tener las funciones básicas para entrar en consideración, pero el verdadero competidor es que el usuario ni siquiera sepa que este producto existe Más que las funciones, los factores competitivos clave son la visibilidad y la accesibilidad

(maxrozen.com)

74 puntos por xguru 2025-04-14 | 4 comentarios | Compartir por WhatsApp

OnlineOrNot, fundada por Max Rozen, comenzó en un mercado donde ya existían más de 200 productos competidores
Al principio, muchos productos eran difíciles de usar, y después aparecieron muchísimos competidores que desaparecieron rápidamente
Algunos competidores recibieron financiamiento de VC y fueron adquiridos por grandes empresas, lo que llevó a un deterioro gradual de la experiencia de usuario
OnlineOrNot apunta a ser un negocio sostenible a largo plazo operado con fondos propios
El autor sigue manteniendo un trabajo de tiempo completo mientras desarrolla su SaaS de forma constante
Escribe una retrospectiva cada año, y algunas lecciones que aprendió en el pasado con el tiempo demostraron estar equivocadas

Principios que no han cambiado

Aunque ha aprendido mucho sobre cómo operar un negocio a lo largo de los años, todavía hay principios clave que siguen intactos

Invertir 2 horas cada día laborable

Desde antes de empezar OnlineOrNot, dedicaba 2 horas cada mañana antes de ir al trabajo a proyectos personales
Aprovechó ese tiempo para completar cientos de textos, un libro y varios proyectos de software
Más importante que cuánto inviertes en un solo día es el esfuerzo constante todos los días
Para asegurar ese tiempo, se despierta 2 horas más temprano y ajusta su rutina

No hacer otros side projects

Como dice el refrán, “el que mucho abarca, poco aprieta”: se enfoca en una sola cosa
Algunas personas excepcionales logran sacar adelante varios proyectos, pero reconoce que él no es así
Considera que el tramo de $0 a $500 de MRR es el más difícil y que no vale la pena repetirlo
Se concentra en un modelo que ya funciona, y elige su forma de hacer marketing con esa misma lógica

Lo primero es resolver el dolor del cliente

Cuando un usuario se registra, se le envía un email automático preguntando: “¿Por qué te registraste?”
Lee todos los correos y responde personalmente, y eso se convierte en una fuente clave de insights para mejorar el producto
Identifica lo que les incomoda a los usuarios y lo resuelve de verdad

Iterar y mejorar con persistencia

Si alguna tarea no puede desplegarse en 2 horas, reduce el alcance y la lanza primero
No siempre logra ajustarse exactamente a 2 horas, pero prefiere lanzar rápido una primera versión y luego expandir la funcionalidad
Si intenta construir todo antes de desplegar, termina perdiendo motivación y enfoque
Completar funciones gradualmente detrás de feature flags resulta mucho más efectivo

Lecciones aprendidas

Leer unos pocos libros y luego ponerse a construir

Al empezar, leyó decenas de libros de negocios para cometer menos errores
Pero al final se dio cuenta de que la forma más efectiva de aprender es equivocándose uno mismo
Ejemplo: llegó a la portada de Hacker News y recibió 6000 visitas, pero solo una cantidad de un solo dígito llegó realmente hasta la app
Solo en el formulario de registro abandonaba el 75% → con una sola opción de login por OAuth, la tasa de abandono mejoró hasta 50%
Si volviera a empezar, solo leería estos tres libros y arrancaría de inmediato:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Si necesitas detalles prácticos sobre operar un SaaS, también recomienda The SaaS Playbook (Rob Walling)

Antes que vender suscripciones, resolver problemas

El objetivo de un SaaS no es vender suscripciones, sino resolver el dolor del cliente
Hace falta cambiar la mentalidad de “si sigo construyendo funciones, algún día la gente las usará” a “resolvamos los problemas frustrantes del trabajo del usuario”
El SaaS es solo una manera de resolver problemas; también se puede abordar con screencasts, documentación, escritura, libros, talleres, muestras de código y más

Construir pequeño y desplegar seguido

Los usuarios proponen ideas de funciones, pero en la práctica casi no las usan
Quien empieza por primera vez con un SaaS puede emocionarse solo por hablar con alguien y terminar construyendo funciones sin pensar demasiado
Hay que preguntar cómo usarían esa función e investigar cómo otros usuarios resuelven ese problema, y luego
- implementarla primero con la mínima funcionalidad posible para validar la reacción
Más importante que crear una “función copo de nieve” que solo usa una persona es tener un enfoque estratégico para construir funciones que use mucha gente
Duele eliminar una función en la que invertiste unas horas, pero duele mucho más eliminar una en la que invertiste meses

Lanza primero y preocúpate por escalar después

La primera versión de OnlineOrNot salió rápido sin optimización arquitectónica
De hecho, había un bug que limitaba el sistema a unas 100 verificaciones, y
- cuando ocurría un problema, la UI solo mostraba “Error!”, así de incompleto estaba
Aun así, el autor prefirió recibir críticas por una UI incompleta antes que construir funciones innecesarias
Como no había garantía de que llegarían miles de usuarios desde el principio, era más importante validar rápido
Como solución temporal, subió la base de datos a un plan superior para aumentar la capacidad de verificaciones
En pocas horas, refactorizó la estructura para procesar millones de verificaciones y también mejoró la pantalla de error

Operar un programa de early access

En las primeras etapas del desarrollo del producto, la mayoría de los usuarios es relativamente tolerante con funciones incompletas
Con el tiempo, aumenta la cantidad de usuarios que espera un producto más maduro
Para resolver eso, agregó a cada cuenta de usuario una casilla de “participar en el programa de early access”
- Quienes participan prueban primero las funciones nuevas todavía no terminadas y dan feedback
Funciona bien como una forma de equilibrar pruebas y retroalimentación

Introduce la prueba gratuita lo antes posible

Hoy en día es común el consejo de “los planes gratuitos son demasiado difíciles de equilibrar, así que mejor no los hagas”
Sin embargo, al principio el plan gratuito fue efectivo para el boca a boca y la adquisición de usuarios
La desventaja es que, si el plan gratuito difiere mucho de las funciones pagadas, necesitas una forma de probar las buenas funciones
Recién 11 meses después del inicio agregó en el onboarding la pregunta “¿Quieres iniciar una prueba gratuita?”
- En realidad eso significa lo siguiente:
  > “¿Quieres probar las buenas funciones durante 14 días y luego decidir, o prefieres usar durante meses una versión limitada y terminar decepcionado?”
Después, como experimento, empezó a ofrecer la prueba gratuita por defecto a todos los usuarios, y
- solo ese experimento hizo que la tasa de crecimiento mensual se duplicara con creces
Conclusión:
- El mensaje “este es un servicio de pago; para seguir usando las buenas funciones necesitamos tu información de pago”
- es mucho más efectivo para el negocio que “este es un servicio gratuito; tal vez sea de pago si lo usas mucho”

La documentación es parte del producto

Antes era común decir “los desarrolladores no leen documentación”, pero eso es completamente falso
Algunos de sus clientes ideales elogiaron la documentación de OnlineOrNot, y eso lo llevó a invertir seriamente en ella
También construyó por su cuenta la documentación de la API para tener control total de la experiencia de usuario
Al observarlo con herramientas de analítica de producto, vio lo siguiente:
1. Si el usuario tiene un problema en la UI, revisa la documentación y encuentra la función, sigue usando el producto
2. Si no encuentra la información que busca, no crea verificaciones y abandona
La calidad de la documentación está directamente ligada a la retención de usuarios

Diseña el producto pensando en móvil

Contra lo que mucha gente cree, los usuarios de SaaS B2B también empiezan su trabajo desde el smartphone
De hecho, alrededor del 50% de los usuarios empieza a usar el producto desde móvil
- Crean una cuenta, registran algunas páginas y luego vuelven a revisar desde la PC
Durante los primeros 6 meses no tuvo en cuenta el entorno móvil, y la mayoría de quienes se registraban desde móvil se iba
Después, al introducir una UI responsive, la retención de usuarios móviles aumentó de forma visible

Pregunta directamente a los usuarios de dónde vienen

Uno de los cambios de código más valiosos que introdujo a mitad del primer año fue
- agregar en el registro la pregunta “¿Dónde conociste OnlineOrNot?”
Entender los canales de adquisición es muy importante para maximizar la eficiencia del marketing
Existen decenas de canales de marketing, pero los recursos para enfocarse son limitados
Cuando identificas un canal que funciona, invierte en él con foco y sigue haciéndolo hasta que deje de responder

No usar herramientas de analítica intrusiva

Al principio introdujo session tracking y herramientas de análisis de funnel como cualquier producto SaaS común, pero su efectividad fue baja
Puede ser útil para equipos grandes, pero en servicios pequeños es fácil confundir resultados aleatorios con señales reales
Como fundador solo, con apenas 2 horas cada mañana,
- en vez de analizar montañas de datos, le resultó más efectivo pedir opinión directamente a un grupo de usuarios de confianza (inner-circle)
Recibía feedback más intuitivo sobre funciones o problemas y mejoraba el producto con juicio basado en sensibilidad

Habla con prospectos aunque todavía no tengas la función

Un día, un CTO le preguntó si soportaban cierta función
Su idea original era responder “lo siento, todavía no”, pero
- por curiosidad preguntó qué problema estaban enfrentando y qué objetivo querían lograr
- también le preguntó a usuarios del inner-circle si tenían ese mismo problema
- compartió ideas sobre cómo podría diseñarse esa función
Como resultado, ese CTO se convirtió en cliente de pago al día siguiente y sigue siéndolo hasta hoy
Esa función también ha sido útil para otros usuarios

Pasé más tiempo construyendo la plataforma que resolviendo el problema

Durante los últimos 4 años, más de la mitad del tiempo de desarrollo se fue en construir la plataforma SaaS
- El objetivo original, “comprobar si un sitio web está caído y enviar alertas”, era solo una parte
Las funciones que realmente hacían falta eran:
- distintos métodos de autenticación y gestión de usuarios
- pruebas, onboarding
- tareas repetitivas de DB, gestión de equipos, manejo de facturas
- emails de lifecycle, etc.
Algunas cosas se externalizaron con servicios como Stripe, pero
- muchas otras requerían manejo directo o personalización, así que terminó implementándolas por cuenta propia

Poner precios es realmente difícil

Si el precio es demasiado alto, suben las expectativas o la gente ni siquiera se registra
Si el precio es demasiado bajo, puede pasar que un usuario que paga $9 exija que le adaptes toda la app a su gusto
La solución:
- a los clientes difíciles se les devuelve el dinero y se les deja ir
- se sube el precio y se sigue adelante
- especialmente al principio, a medida que expandes funciones, es indispensable experimentar continuamente con precios

No te obsesiones solo con el MRR

MRR (Monthly Recurring Revenue) puede ser una métrica inadecuada para medir el desempeño del negocio
Como lo que hiciste hace semanas o meses impacta el MRR de hoy, es difícil medir efectos en tiempo real
En algunos productos SaaS, desde que un usuario se registra hasta que realmente paga pueden pasar más de 60 días
Por eso conviene usar otras métricas para saber si realmente están usando el producto y si están recibiendo valor
- Por ejemplo: número de imágenes generadas, formularios enviados y otras métricas de éxito basadas en comportamiento

Nunca ofrezcas “ilimitado”

Siempre existe el usuario whale que explotará al máximo lo “ilimitado”
Ejemplo: clientes que pagan solo $250 al mes y consumen una cantidad enorme de recursos
Si la unidad que ofreces como ilimitada genera un costo, vas a perder dinero sí o sí
Este consejo también aplica a los lifetime deals
- Si prometes uso de por vida por $100, durante años pueden seguir exigiendo nuevas funciones
- Y si usaste un marketplace de terceros, quizá en realidad solo recibas el 30% de ese ingreso
Al final, terminas invitando no a clientes reales, sino a usuarios que buscan beneficio de corto plazo y se quedan amarrados durante mucho tiempo

Todo recurso pagado debe tener rate limits

Si usas APIs pagadas como IA, SMS o envío de email, limitar el uso es obligatorio
“Pero si son clientes de pago, ¿no deberían poder usarlo sin límite?” → puede haber excepciones, pero
- en la mayoría de los casos eso implica riesgo de costos descontrolados o de que el proveedor te marque como spam
Caso real:
- un servidor que alojaba cientos de sitios WordPress sufrió errores por falta de RAM
- como resultado, se enviaron automáticamente miles de alertas por SMS, generando un costo enorme
Si de verdad un cliente necesita un volumen masivo, te va a contactar directamente

No intentes explicarlo todo en una sola página

> “Si intentas decirle todo a todos, no le terminas diciendo nada a nadie”

Esta frase aplica especialmente bien al copywriting de landing pages
Cada vez que OnlineOrNot añadía una función, seguía agregando explicaciones a la landing principal, y eso hizo que
- el mensaje se volviera confuso y la comprensión del usuario bajara
- por ejemplo, Slack notifications fue la segunda función que creó, pero mucha gente ni siquiera sabía que existía
Solución: crear landing pages separadas para cada función
- Principal: https://onlineornot.com/
- Monitoreo de uptime: https://onlineornot.com/website-monitoring
- Monitoreo de API: https://onlineornot.com/api-monitoring
- Status pages: https://onlineornot.com/status-pages
- Monitoreo de cron jobs: https://onlineornot.com/cron-job-monitoring
Así, cada página tiene suficiente espacio para comunicar claramente la función

Aumentar el tráfico es difícil; mejorar la conversión sí puede hacerse hoy

Llamar la atención en internet es una carrera de fondo y muy lenta
- incluso con content marketing constante y de calidad, pasar de 1 o 2 visitas a cientos puede tomar meses o años
No es fácil aumentar el tráfico en sí
En cambio, sí puedes cambiar hoy mismo el comportamiento de quienes ya llegaron
- por ejemplo, agregar una opción de login con OAuth al formulario de registro: una mejora aplicable hoy que puede subir la conversión

Los competidores no importan tanto

La razón por la que en todo este texto casi no se habla de competidores es que en realidad no tienen tanto impacto
Claro, necesitas tener las funciones básicas para entrar en consideración, pero
- el verdadero competidor es que el usuario ni siquiera sepa que este producto existe
Más que las funciones, los factores competitivos clave son la visibilidad y la accesibilidad

4 comentarios

thenewseason 2025-04-22

Desde la perspectiva de quien opera un servicio, me identifico mucho con muchas de las cosas que dice.
Yo también llegué a desarrollar quitándome horas de sueño, pero mi salud se deterioró...

Lo que me da curiosidad preguntarles a quienes han pasado por algo parecido es si esta inversión de tiempo es posible mientras se cría a los hijos.
Como el tiempo de traslado al trabajo, las horas que uno permanece en la empresa y el tiempo en casa con los niños ocupan casi la mayor parte del día, para crear y operar un servicio así uno termina teniendo que renunciar a algo más, y ojalá que eso no sea la familia ni la salud...

tsboard 2025-04-15

De verdad es un texto del que se puede aprender mucho. ¡Increíble que aprovechara 2 horas cada mañana para escribir y además terminar varios proyectos...!

ethanhur 2025-04-14

Es un texto del que se aprende mucho. Al final, no hay que olvidar que SaaS también es un producto que el cliente contrata para resolver un problema.

xguru 2025-04-14

Lo que aprendí tras operar un SaaS yo solo durante 1 año
Ya pasaron 3 años, jaja. ¡Compárenlo viendo qué cosas cambiaron!