Tu programa funciona porque eres su único usuario

Construiste el programa que siempre quisiste.

Hablando con un modelo, en tardes sueltas, sin pedirle permiso a nadie. Resuelve un problema que tenías de verdad. Lo abres todos los días. Funciona.

Y entonces alguien te dice lo que era inevitable: esto lo podrías vender.

Tiene razón en algo importante. Construiste algo que a ti te sirve, y eso es más de lo que consigue casi toda la gente que solo habla de sus ideas. Lo que viene no va de si eres capaz. Va de una diferencia concreta entre lo que tienes y lo que estás a punto de prometer.

Tu programa funciona porque tiene exactamente un usuario, y ese usuario eres tú.

Nunca escribiste en ninguna parte que quien lo usa es quien lo programó, que confía en él, que no tiene ningún motivo para atacarlo, que los datos guardados le pertenecen, que si se cae puede levantarlo, y que sabe perfectamente qué debería estar haciendo. No hacía falta escribirlo. Lo cumplías tú, todos los días, sin darte cuenta de que lo estabas cumpliendo.

Venderlo es dejar de cumplirlo todo a la vez.

El día que entra alguien que no eres tú

En tu programa, esta consulta está bien:

SELECT * FROM notas WHERE id = ?

Está bien porque todas las notas son tuyas. No hay frontera entre dueños porque hay un solo dueño.

El día que existen dos cuentas, esa misma consulta es una filtración. Cualquiera puede mandar cualquier número y recibir la nota de otra persona. La versión que no filtra lleva una condición más:

SELECT * FROM notas WHERE id = ? AND usuario_id = ?

Parece un detalle menor. Es el artículo entero.

Porque no basta con acertar una vez. Hay que acertar en todas las consultas, en las que escribas el mes que viene, y en las que escriba el modelo cuando le pidas una función nueva y ya no revises el SQL porque las diez anteriores salieron bien.

Una sola consulta a la que le falte esa condición no expone los datos de un cliente. Expone los de todos.

Antes de seguir leyendo, abre el proyecto y cuenta cuántas de tus consultas filtran por el dueño del dato. Si la respuesta no es “todas”, ya sabes en qué vas a trabajar esta semana.

La primera vez que tocas algo que no es tuyo

Tu modelo de datos no se diseñó. Se fue sedimentando.

Son cuarenta conversaciones en las que pediste un cambio, el modelo lo hizo, funcionó y seguiste adelante. Quedaron columnas que ya nadie escribe, tablas que significan una cosa en las filas viejas y otra en las nuevas, y decisiones de marzo que contradicen a las de junio.

Mientras el dato es tuyo, eso es deuda tuya. La pagas cuando quieras, o no la pagas nunca y no pasa nada.

Cuando el dato es de alguien que te paga, cambia de naturaleza. Una migración mal hecha ya no te arruina la tarde: le pierde información a una persona que confió en ti. Y responder “lo restauro del respaldo” da por hecho tres cosas seguidas: que tienes respaldos, que alguna vez probaste restaurar uno, y que sabes cuánto se pierde entre el último respaldo y el accidente.

Intenta escribir en una hoja qué significa cada tabla, sin abrir el código. Las que no puedas explicar en una línea son exactamente las que te van a doler.

El sábado a las tres de la mañana

En tu máquina, cuando algo falla, te enteras porque lo estás usando. Cierras y vuelves a abrir. Para un usuario es una estrategia de operación perfectamente razonable.

Con clientes, la pregunta cambia de forma. Ya no es qué haces cuando se cae. Es cómo te enteras de que se cayó.

Si la respuesta es “porque lo abro y no carga”, tus clientes lo saben antes que tú. Tu primer aviso de que algo va mal llega dentro de un correo escrito por alguien que está molesto y que además te está pagando.

Apágalo a propósito un día cualquiera y mide cuánto tardas en notarlo sin mirarlo. Ese número es tu tiempo de reacción real, y nunca lo mediste porque hasta ahora no hacía falta.

Las decisiones que nunca tomaste

Este es el punto que más se subestima, y el que peor se cuenta por ahí.

La versión que circula dice que el modelo eligió SQLite y que para un SaaS necesitas Postgres. La segunda mitad no siempre es cierta: SQLite corre cargas de producción reales y hay productos serios construidos encima.

El defecto no es SQLite. El defecto es que nadie decidió SQLite.

Un default que aceptaste sin evaluar sigue siendo un defecto aunque la respuesta resulte correcta de casualidad, porque no puedes defenderlo, no sabes bajo qué condiciones deja de servir, y no vas a ver venir el día en que deje de hacerlo.

Eso es lo que pasa cuando le pides a un modelo un programa completo. No toma malas decisiones. Hace que los defaults parezcan decisiones. Te entrega algo que funciona, y lo que funciona no se cuestiona.

Haz la lista de las decisiones técnicas de tu proyecto y escribe al lado de cada una por qué. Base de datos, autenticación, dónde corre, cómo se despliega. Las que no puedas completar no son decisiones tuyas: son defaults del modelo, y ahora te pertenecen igual.

Lo que esto no dice

Si el programa se va a borrar, nada de lo anterior aplica. Un prototipo que cumple su función y muere es un buen uso de la herramienta, y prepararlo para producción sería desperdicio. El problema aparece cuando el prototipo no se borra, que es de lo que trata este texto.

También existe una posición legítima que sostiene que buena parte de este aparato sobra. Dan North lleva años argumentando, contra los principios SOLID, que la respuesta suele ser escribir código simple en lugar de añadir estructura. Si tiene razón, parte de lo que aquí echo de menos también sobra. No lo tengo resuelto y no voy a fingir que sí.

Y no estoy diciendo que necesites contratar a alguien. Sería muy conveniente para mí, y no es lo que observo.

Yo fallé en la mitad contraria

Escribí hace un mes que llevaba quince años construyendo software y cero ventas. El diagnóstico honesto fue que nunca construí la otra mitad.

Tenía todo lo que este artículo describe. Sabía diseñar el modelo de datos, sabía desplegarlo, sabía dónde estaban los agujeros. No me sirvió de nada, porque nunca aprendí a poner eso delante de alguien dispuesto a pagarlo.

Tú tienes la mitad que a mí me faltaba. Construiste algo que resuelve un problema y tuviste el impulso de enseñarlo.

Ninguna de las dos mitades sola es un producto. Yo lo aprendí tarde y por el lado caro. Este texto existe para que la otra mitad te salga más barata de lo que me salió a mí la mía.

Lo que hay medido

Esto es una posición mía, no el informe de un incidente que yo haya vivido. Lo que sí está medido es lo siguiente, con sus límites puestos.

DORA, el programa de investigación de Google sobre entrega de software, encontró algo que encaja incómodamente bien con todo lo anterior: a mayor adopción de IA, mejor rendimiento de entrega y peor estabilidad, las dos cosas a la vez. Su explicación es que la aceleración no crea los problemas, los destapa. Expone las debilidades que ya estaban más abajo en la cadena. Conviene añadir que la propia fuente lo presenta como correlación, no como causa.

La encuesta de Stack Overflow del mismo año llega al mismo sitio por otro camino. La frustración más citada, por dos tercios de quienes respondieron, son las soluciones de IA “casi correctas, pero no del todo”. Es percepción declarada y no medición de defectos, y quien contesta esa encuesta suele ser gente ya muy involucrada con esa comunidad.

GitClear, que analiza repositorios, reporta que la duplicación de bloques de código casi se duplicó desde 2023 mientras la refactorización se desplomaba. Con dos advertencias que su propio informe no hace: es un proveedor de analítica midiendo repositorios de sus clientes, y no distingue correlación de causalidad.

Ninguna de las tres demuestra que tu programa vaya a fallar. Lo que muestran juntas es que el problema no está en la calidad del código generado. Está en que la velocidad de producción subió y todo lo que viene después siguió costando exactamente lo mismo.

Por dónde empezar

No por reescribirlo.

Por el filtro de las consultas, que es lo único de aquí capaz de hacerte daño de verdad esta semana. Después, la lista de decisiones con su porqué al lado.

Ese documento de una página es toda la diferencia entre un programa que funciona y un programa que entiendes. Y es lo único de este artículo que no puede escribirte un modelo, porque la mitad de las respuestas no están en el código.