La primera vez que alguien me preguntó cuánto cobraba por una página web, improvisé un número en el momento. No tenía ninguna estructura detrás, ninguna lógica de costos, nada. Dije un número que me pareció razonable, el cliente aceptó, y ese número se convirtió, sin que yo lo planeara, en mi tarifa de referencia durante los siguientes meses.
Desde ese primer número improvisado hasta la estructura de precios que tiene hoy Halcones Hub pasaron tres versiones completamente distintas. Cada cambio nació de un error o de una incomodidad real, no de una clase de marketing ni de un curso de pricing. Quiero contar esas tres versiones tal cual fueron.
Versión 1: cobrar por hora, sin decirlo
Como mencioné en otra nota, mi primera lógica de precios era pensar en horas, aunque nunca lo formalicé como una tarifa por hora explícita. Calculaba mentalmente cuánto tiempo me iba a llevar un proyecto, le asignaba un valor a mi hora — un valor que, honestamente, también inventaba sin mucho criterio — y ese era el precio.
El problema de esta lógica, además del que ya mencioné sobre castigar la experiencia, era que generaba precios completamente inconsistentes entre proyectos parecidos. Un cliente exigente, que pedía muchas reuniones y mucha comunicación, terminaba costándome muchas más horas reales que otro con el mismo tipo de proyecto pero más autónomo. Como mi precio estaba atado a mi estimación inicial de horas, no al valor real entregado, terminaba subsidiando a los clientes más demandantes con el mismo precio que cobraba a los más simples.
Versión 2: paquetes fijos, sin diferenciación
El segundo intento fue crear tres paquetes con precios fijos: básico, intermedio y completo. Esto resolvió parte del problema de inconsistencia — al menos ahora todos los proyectos de "paquete básico" costaban lo mismo, sin importar cuánto tiempo me llevaran realmente.
Pero apareció un problema distinto. Los tres paquetes eran genéricos, definidos solo por cantidad de páginas o funcionalidades técnicas, sin considerar el contexto del cliente. Un comercio chico y un estudio jurídico, ambos pidiendo el mismo "paquete intermedio", recibían exactamente el mismo precio — aunque el valor que esa web representaba para cada uno fuera completamente distinto. El estudio jurídico, con un ticket promedio de cliente mucho más alto, podía generar el retorno de esa inversión con un solo cliente nuevo conseguido a través de la web. El comercio chico necesitaba muchos más clientes nuevos para justificar la misma inversión.
Estaba cobrando lo mismo por cosas que valían objetivamente distinto para cada cliente, solo porque técnicamente eran similares de construir.
Versión 3: precio por valor, con paquetes como punto de partida
La versión actual, la que uso hoy, mantiene los paquetes como estructura base — siguen existiendo niveles claros, porque eso ayuda a que el cliente entienda rápido las opciones disponibles. Pero el precio final de cada proyecto ahora considera, además del paquete técnico, el contexto específico del negocio: qué rubro es, qué ticket promedio maneja, qué tan competitivo es el mercado en el que opera, y qué tan crítico es para ese negocio en particular tener una presencia digital efectiva.
En la práctica, esto significa que dos proyectos con la misma estructura técnica — mismas páginas, mismas funcionalidades — pueden tener precios distintos según el contexto del cliente. No es arbitrario: está basado en una conversación inicial donde entiendo el negocio antes de cotizar, no solo la lista de funcionalidades que pide.
Cómo explico esta diferencia de precio sin que se sienta injusta
Esto podría sonar a que estoy cobrando "lo que el cliente puede pagar", que no es la intención ni la lógica real. La diferencia no está en la capacidad de pago del cliente — está en el valor que esa web genera para ese negocio específico. Un estudio jurídico que puede conseguir un cliente nuevo de alto valor a través de su web tiene un argumento de retorno de inversión mucho más fuerte que un comercio con margen bajo y alta competencia de precio.
Cuando explico esto en la reunión inicial, casi siempre el cliente lo entiende y lo acepta sin fricción, porque tiene sentido lógico: no estoy cobrando un número arbitrario, estoy alineando el precio con el valor real que el proyecto representa para su negocio puntual.
El mantenimiento mensual: el cambio que más costó incorporar
Algo que no formaba parte de mi estructura original, y que hoy es un componente fijo de cada propuesta, es el mantenimiento mensual. Al principio no lo cobraba — entregaba la web y ahí terminaba mi relación con el proyecto, salvo que el cliente quisiera contratar un cambio puntual más adelante.
El problema era doble. Por un lado, sin mantenimiento activo, muchas webs quedaban desactualizadas, con problemas de seguridad sin resolver, o directamente caídas por falta de renovación de hosting — y eso, aunque técnicamente no fuera mi responsabilidad después de la entrega, terminaba reflejando mal en mi trabajo cuando el cliente asociaba el problema con "la web que me hizo Thomas". Por otro lado, sin un ingreso recurrente, todo mi negocio dependía de conseguir proyectos nuevos constantemente, sin ningún ingreso base predecible mes a mes.
Incorporar el mantenimiento mensual como parte estándar de cada propuesta resolvió ambos problemas a la vez. Hoy es una parte no negociable de cómo trabajo, explicada desde la primera conversación como parte natural del servicio, no como un agregado opcional.
Lo que aprendí de este recorrido
Si hay una lección que me llevo de estas tres versiones, es que el precio correcto no es un número que se calcula una sola vez y queda fijo para siempre. Es algo que se ajusta a medida que entendés mejor tu propio negocio, el valor real que entregás, y los errores que cada estructura anterior dejó expuestos.
Si todavía estás en la versión uno o dos de tu propia estructura de precios — cobrando por hora sin decirlo, o con paquetes genéricos sin diferenciación — no te preocupes. Es parte normal del proceso. Lo importante es estar atento a las señales de que algo no funciona, como yo lo estuve, y animarte a cambiar la estructura cuando esas señales aparecen, en lugar de quedarte con un sistema que ya demostró sus límites solo porque "siempre se hizo así".
Las señales que indican que tu estructura de precios necesita cambiar
Mirando hacia atrás, hay señales concretas que en cada versión anterior me avisaban, sin que yo las escuchara a tiempo, que algo no estaba funcionando. La primera señal, en la versión de cobrar por hora mental, era sentir resentimiento hacia proyectos que se estiraban en tiempo sin que el precio se ajustara — esa sensación de "estoy regalando mi tiempo" es casi siempre un síntoma de que el precio no refleja bien el valor real del trabajo.
La segunda señal, en la versión de paquetes fijos, era notar que clientes con proyectos claramente más valiosos para su negocio pagaban exactamente lo mismo que clientes con proyectos de menor impacto, solo porque coincidían técnicamente en el mismo paquete. Si sentís que estás cobrando lo mismo a clientes que claramente no están recibiendo el mismo valor, esa es una señal clara de que tu estructura necesita un ajuste.
La tercera señal, más general y aplicable a cualquier etapa, es la dificultad para explicar con claridad por qué tu precio es el que es. Si te cuesta justificar tu propio precio frente a un cliente que pregunta, probablemente sea porque ese precio no está bien anclado a una lógica clara — y esa falta de claridad interna, tarde o temprano, se nota también hacia afuera, en cómo presentás tu propuesta.
Por qué decidí compartir esto abiertamente
Sé que hablar de precios y de cómo se calculan es, para muchos emprendedores, un tema incómodo de hacer público. Decidí escribir esta nota igual porque creo que la mayoría de la confusión que veo en otros emprendedores de Santa Rosa sobre cómo poner precio a su trabajo viene de no tener ninguna referencia real de cómo otros lo resolvieron — solo fórmulas genéricas de internet que no consideran el contexto local ni la evolución natural que cualquier estructura de precios necesita atravesar con el tiempo.