Cómo crear un software cuando no eres el programador: el framework de decisión para el founder no técnico

Cuatro decisiones en orden, cinco preguntas para elegir el camino, y qué cambia cuando el software llega a un cliente que paga.

En una reunión de un miércoles pasado, una founder llegó con una libreta abierta, una hoja de cálculo llena de colores, y una frase: “necesito crear un software”. Venía de operaciones. Había resuelto la planilla con automatizaciones de Google Sheets. La planilla se había roto tres veces ese mes. Los clientes empezaban a notarlo. Estaba al día con el problema del negocio. Estaba perdida en cómo construir el software.

“Cómo crear un software” tiene una respuesta diferente según quién pregunte. Un desarrollador que aprende necesita un tutorial: elige un lenguaje, monta el entorno, escribe código, prueba, despliega. Para el founder no técnico, crear un software no es programar. Es tomar cuatro decisiones en orden antes de que exista una sola línea de código. Confundir las dos cosas hace empezar por el lado equivocado, contratar por la razón equivocada, y seis meses después tener dos mil dólares al mes de servidor corriendo algo que nadie usa.

Este artículo es el framework que usamos con founders no técnicos cuando llegan con la planilla rota, el contrato firmado con plazo, o el inversor pidiendo el prototipo. Cuatro decisiones. Cinco preguntas. Un documento de una página.

Las cuatro decisiones antes de empezar

Existe una secuencia. Importa. Tomar la cuarta decisión antes de la primera es la forma más común de quemar tres meses y el presupuesto de la ronda pre-seed.

Decisión 1, alcance real. ¿Qué necesita funcionar el primer día para el primer cliente que paga? No lo que estaría bien tener. No lo que mencionó el inversor. El conjunto mínimo de pantallas y acciones sin las cuales no ocurre la primera venta. Regla práctica: si puedes describir el software en tres frases y cinco pantallas, estás cerca. Si tienes 47 user stories en Notion, no lo has pensado lo suficiente.

Decisión 2, camino. Build vs buy vs no-code vs híbrido. Cada uno tiene un perfil de costo, un techo de funcionalidad, y un tipo de persona que necesita estar de tu lado para que funcione. Volvemos a esto en la próxima sección.

Decisión 3, partner. Quién va a construir. Freelancer, software house, contratación interna, o plataforma no-code con un implementador. Esta decisión depende de la decisión 2. No empieces por aquí.

Decisión 4, contrato y presupuesto. Cómo queda acordado el trabajo. Precio fijo, time and materials, equity, sprint pago. Cómo sale el dinero y qué cuenta como entregado. Esta decisión depende de las tres anteriores.

La mayoría de founders no técnicos que vemos intenta empezar por la decisión 3. “¿Conoces un buen desarrollador?” es la pregunta equivocada antes de resolver la decisión 1. Bueno para qué.

Cómo elegir el camino: build, buy, no-code, o híbrido

La decisión 2 es la que más carga el resto. Define a quién llamas, cómo va a ser el presupuesto, y qué tipo de problema vas a descubrir en el camino.

Buy. Ya existe un software que hace el 80% de lo que necesitas. Salesforce o HubSpot para CRM, Pipefy para flujo, QuickBooks para contabilidad. Buy es la respuesta correcta cuando tu ventaja competitiva no está en el software en sí. Eres una operación inmobiliaria que necesita un CRM, no una proptech construyendo el CRM del mercado. Comprar es más rápido, más barato en el primer año, y te libera para enfocarte en lo que de verdad diferencia el negocio.

No-code. Bubble, Glide, Softr, Retool con módulos. Funciona cuando el flujo es claro, el volumen es bajo (hasta unos miles de transacciones al mes), y el software aún no es el producto que el cliente paga. No-code es la forma más barata de validar una idea. También es el camino del que más gente sale en llamas, normalmente entre el primer contrato relevante y la Serie A. El artículo sobre discovery de producto para founders no técnicos muestra cómo usar no-code para validar sin atarte.

Build. Software a medida, escrito para el problema específico. Tiene sentido cuando el software es parte de lo que el cliente paga, cuando el volumen ya pasó lo que no-code aguanta sin volverse caja negra, o cuando la regulación de tu sector (salud, financiero, jurídico) exige un nivel de control que una herramienta genérica no da. Build es más caro de empezar y más barato de mantener cuando está bien hecho. El artículo sobre cuándo contratar una software house cubre cómo evaluar partners sin fingir profundidad técnica.

Híbrido. Casi todo software de empresa real es híbrido en la práctica. CRM comprado, herramienta interna a medida, integración vía Zapier o API. La pregunta híbrida correcta es “qué parte es nuestra ventaja competitiva y qué parte es commodity”. La ventaja se construye. El commodity se compra. Mezclar mal es caro: construir CRM desde cero cuando HubSpot lo resolvería, o comprar una herramienta de riesgo cuando tu modelo de riesgo ES el producto.

Regla de pulgar: si el software va a estar frente al cliente que paga y es parte del producto que compra, build. Si es interno, transitorio, o en un dominio comoditizado, buy o no-code con plan de salida.

¿Es posible crear un software sin programar?

Sí, en dos formas, y la confusión entre ellas es cara.

La primera es no-code. No escribes código, pero escribes reglas: “cuando el cliente llena este formulario, guarda aquí, manda este email, muestra esta pantalla”. Las reglas se vuelven el software. Funciona hasta un techo previsible: integración que la plataforma no soporta, volumen que pasa el plan, detalle de diseño que la plantilla no permite. El artículo sobre vibe coding vs agentic coding cubre cómo pensar estas decisiones por etapa.

La segunda forma es contratar a quien programa por ti. El “sin programar” es literal, pero el founder sigue siendo dueño de la decisión de alcance, de la revisión de lo entregado, y de la respuesta a “esto es lo que el usuario necesita, esto no”. Quien terceriza la decisión de producto al desarrollador termina con un software que satisface al desarrollador, no al cliente.

La tercera forma, la que no funciona, es pensar que herramientas de IA generativa van a “crear el software” desde el brief. Escriben código. No toman decisiones de producto, no prueban contra el cliente real, y no responden por errores en producción.

Cuánto cuesta crear un software, en la práctica

El rango varía en un orden de magnitud. Buy entrega algo funcionando en horas, cuesta entre 20 y 200 dólares al mes por usuario en suscripción, y el trabajo del founder es configurar y entrenar al equipo. No-code entrega el primer flujo en una a cuatro semanas, cuesta entre 80 y 800 dólares al mes de plataforma más un implementador (entre 1.000 y 3.000 para el primer setup), y exige que alguien (tú o un operador) mantenga las reglas vivas. Build entrega la primera versión en tres a seis meses, cuesta entre 40.000 y 250.000 dólares para un MVP a medida bien acotado, y exige un flujo semanal de revisión entre founder y partner de ingeniería. Para el desglose completo por driver, el artículo sobre cuánto cuesta desarrollar una app abre los seis factores que más mueven el número.

El rango no es el problema. El problema es empezar build sin presupuesto de build, o empezar no-code creyendo que va a quedar barato para siempre. El costo total de no-code en tres años suele superar el costo de un build bien hecho cuando el volumen pasa de algunas centenas de transacciones por día. El costo total de un build mal acotado en seis meses supera el de cualquier plataforma comercial disponible.

Cómo crear un software paso a paso, desde cero

Para el founder no técnico, “crear un software desde cero” no es abrir un editor de código vacío. Es empezar una secuencia de decisiones y entregas que termina en un software corriendo para un cliente que paga.

Semana 1. Escribe en una página qué hace el software, para quién, qué acción hace el cliente, las cinco pantallas mínimas, y lo que NO está en la primera versión. Esta página es tu primera versión de PRD para founder no técnico y va a cambiar tres veces en las próximas dos semanas.

Semana 2. Muestra el documento a cinco potenciales clientes. No vendas. Pregunta qué falta, qué sobra, qué confunde. Cada cliente que dice “esto sería útil” sin comprometerse con suscripción o pago anticipado es señal débil. Cada cliente que dice “si esto existe hoy lo pago” es la señal que mueve el proyecto.

Semana 3. Decisión de camino. Con la página actualizada y cinco conversaciones en el bolsillo, toma la decisión 2 con criterio: qué parte es diferencial competitivo, qué es commodity, cuál es el presupuesto real, cuál es el plazo hasta el primer cliente.

Semana 4. Decisión de partner. Tres conversaciones con candidatos del camino elegido. Para build, tres software houses o uno o dos desarrolladores senior. Para no-code, dos implementadores especializados en la plataforma. Para buy, dos demos con proveedores y dos conversaciones con sus clientes. Compara propuestas con el documento de una página en la mano.

Semanas 5 a 12. Primera versión. El trabajo del founder es mantener la página viva, revisar entregas semanales, y desbloquear decisiones. Cortar alcance es tu trabajo. Agregar alcance es el error más caro de la etapa.

La secuencia funciona para una empresa, una startup pre-seed, una operación validando una vertical, y un equipo modernizando una planilla que empezó a romperse. Lo que cambia es el rango de presupuesto y la sofisticación del partner.

Cinco preguntas para elegir el camino

Antes de firmar con cualquier partner, responde cada una en una frase:

1. ¿Qué problema del cliente resuelve este software, y cuánto paga hoy por evitarlo? Si la respuesta es “todavía no sé”, estás en discovery, no en build. Vuelve un casillero.
2. En tres años, ¿este software es parte del producto que el cliente compra, o es una herramienta interna? Si es interno, el camino empieza en buy o no-code. Si es el producto, build entra a la conversación de inmediato.
3. ¿Cuánto de la operación corre hoy en planilla, papel, o en la cabeza de una persona? Cuanto más alto, mayor el riesgo de tratar de codificar un proceso que aún no es estable. Estabiliza primero, codifica después.
4. ¿Cuál es el presupuesto real para los próximos seis meses, contando mantenimiento post-lanzamiento? Build sin reserva para los meses siete a doce es como mudarse a una casa que solo puedes pagar la mitad. Va a romper en los detalles.
5. ¿Quién en el equipo va a ser dueño de este software cuando salga al aire? Software sin dueño dentro de la empresa se rompe en silencio. Si la respuesta es “el desarrollador que voy a contratar”, el sistema es frágil por diseño.

Las cinco respuestas, escritas en tres líneas cada una, son el brief técnico que separa una conversación seria con un partner de una reunión que termina con “lo pensamos y volvemos”.

Software como producto vs software como atajo

Antes de la decisión 2, internaliza la distinción que más separa presupuesto bien gastado de presupuesto quemado.

Software como producto es lo que el cliente accede, contrata, paga suscripción, recomienda. Es el producto de la fintech, de la healthtech, del marketplace vertical, del SaaS de nicho. Calidad de ingeniería aquí es ventaja competitiva. No-code es zona de validación, no destino. Subestimar el build aparece como churn, soporte caro, y la imposibilidad de cobrar el precio que un producto bien hecho sostiene.

Software como atajo es lo que hace ganar tiempo a tu equipo: herramientas internas, dashboards, automatizaciones de back-office. La primera versión puede ser mucho más simple. No-code suele ser la respuesta correcta por más tiempo. El error más común es construir desde cero lo que ya existe pre-hecho.

Confundirlos cuesta caro. Construir un CRM interno a medida cuando una suscripción de 30 dólares al mes lo resolvería, y quemar seis meses de equipo en esa pieza. O tratar el producto principal de la empresa como atajo, montar en no-code, y descubrir a los 150 clientes pagantes que migrar es un proyecto de ocho meses en el peor momento posible.

El documento de una página, antes de la primera reunión

La pieza que más separa un brief serio de una conversación cara es un documento simple. Cabe en una página. Tiene seis bloques:

Problema. Lo que duele al cliente, en una frase.

Usuario. Quién usa el software, qué cargo, qué nivel técnico.

Cinco pantallas mínimas. El flujo esencial, en orden.

Fuera de alcance. Lo que NO está en la primera versión.

Métrica de éxito. Cómo sabes que funcionó. “Cliente A hace X en Y minutos” supera “aumentar conversión”.

Restricción. Presupuesto, plazo, dependencia regulatoria, integración obligatoria.

Este documento no es un PRD completo, y no necesita serlo. Es la pieza que permite que tres conversaciones con tres partners diferentes sean comparables. Sin él, cada partner define el alcance en su propia propuesta, cada propuesta queda incomparable, y el founder elige por el carisma del vendedor. Con él, la comparación es honesta.

Por qué fallan la mayoría de los primeros softwares

Tres motivos cubren casi todos los fracasos que vemos, en orden de frecuencia.

Alcance equivocado es el primero. El founder construyó el software que él describió, no el que el cliente necesitaba. Corrección: la semana 2 de la secuencia, cinco conversaciones reales antes de la decisión de camino.

Partner equivocado es el segundo. Freelancer barato en el momento equivocado, software house grande en el momento equivocado, contratación de CTO en el momento equivocado. Corrección: casar la decisión 3 con la 2. Para no-code, un implementador. Para build de producto, una software house competente o un desarrollador senior con revisión de código formal. Para buy, un operador interno que va a dominar la herramienta.

Falta de dueño interno es el tercero. El software sale al aire, nadie en la empresa lo entiende lo suficiente para mantenerlo, y el sistema va degradando hasta la próxima crisis. Corrección: decidir, antes de firmar, qué persona del equipo va a ser dueña del software después del lanzamiento. Si la respuesta es “todavía nadie”, el proyecto no está listo para empezar.

Crear un software, para el founder no técnico, es menos sobre montar un equipo de ingeniería y más sobre tomar cuatro decisiones en orden con información suficiente. La primera versión importa menos que la secuencia.

Preguntas frecuentes

¿Qué se necesita para desarrollar un software?
Cuatro decisiones en orden antes de cualquier línea de código: alcance mínimo, camino (build, buy, no-code, o híbrido), partner, y contrato. La semana 1 produce la página de una hoja. Las tres semanas siguientes refinan la página y eligen camino y partner.

¿Es posible crear un software sin saber programar?
Sí, en dos formas: herramientas no-code que escriben reglas en lugar de código, o contratar a quien programa por ti. En ambos casos, el founder sigue siendo dueño de la decisión de alcance, de la revisión de lo entregado, y de la respuesta a “esto es lo que el cliente necesita”.

¿Cuánto cuesta producir un software?
El rango varía en un orden de magnitud. Buy cuesta entre 20 y 200 dólares al mes por usuario en suscripción. No-code cuesta entre 80 y 800 dólares al mes más el setup. Build cuesta entre 40.000 y 250.000 dólares para un MVP bien acotado. Detalle por driver en el artículo sobre cuánto cuesta desarrollar una app.

¿Cómo crear un programa de software paso a paso?
Cuatro semanas: semana 1, escribe la página con problema y cinco pantallas; semana 2, muéstrala a cinco potenciales clientes; semana 3, decide el camino; semana 4, habla con tres candidatos del camino elegido. De la semana 5 en adelante, mantén la página viva y revisa entregas semanales.

¿Cuál es el mejor camino para crear un software gratis?
Gratis en la práctica casi nunca existe. No-code tiene planes iniciales sin costo con límites estrechos. Código abierto quita la licencia pero suma hosting y mantenimiento. Para validación sin presupuesto, no-code en plan gratuito por treinta a noventa días es el camino más común, con claridad de que es zona de prueba, no destino.