Lanza tu código feo

Productos en producción: kepplifinance.com · capturioo.com

He leído el ensayo de Joel Spolsky sobre Netscape. Conozco el consejo habitual: no deseches software que funciona, refactoriza de forma incremental, elimina el código antiguo. Sabía todo esto antes de abrir mi editor y escribir la primera línea de código de Keppli Finance.

De todas formas lo lancé con código feo.

Cómo empezó

Keppli Finance arrancó como un experimento. Una app de finanzas personales para Latinoamérica, construida en mis ratos libres para aprender y mejorar. Sin hoja de ruta formal. Sin fecha de lanzamiento. Solo un lugar donde explorar ideas.

El problema con los experimentos es que, si la idea es buena, dejan de ser experimentos.

En algún punto la app empezó a tener sentido. Las funciones encajaban. El producto era real. Decidí lanzarlo.

Fue entonces cuando abrí el código fuente y me incomodé.

Lógica de negocio mezclada con lógica de presentación. Funciones que hacían tres cosas distintas. Nombres de variables que solo yo entendía a las 2 a.m. cuando los escribí. No era un desastre absoluto —funcionaba—, pero cada nueva feature era una operación de cirugía sin historial clínico.

El consejo habitual (y por qué lo ignoré)

La respuesta obvia era reescribir. Empezar con una arquitectura limpia, buenas convenciones, cobertura de tests desde el día uno.

Pero todos los artículos sobre reescritura están escritos desde la perspectiva de equipos. Empresas con ingenieros, presupuesto y stakeholders. Asumen que se puede mantener dos sistemas en paralelo mientras se migra.

Yo era solo yo. Trabajando en esto entre proyectos de clientes, en huecos de tiempo que a veces duraban cuatro horas y a veces cuatro días.

La situación es diferente cuando estás solo.

Así que hice lo que cualquier desarrollador sensato haría en mi lugar: lo lancé.

Los primeros días

El lanzamiento fue sin fanfarria. Compartí el link, esperé.

Los primeros 10 usuarios llegaron. Luego 50. Luego 100.

Y con cada usuario llegaban cosas que ningún test cubre: flujos que yo consideraba obvios pero que nadie más entendía, bugs en casos límite que nunca imaginé, preguntas de soporte que revelaban vacíos en el producto que el código perfecto jamás hubiera detectado.

El código era feo. El producto era real. Y eso cambió todo.

Porque de repente tenía algo que antes no tenía: retroalimentación de usuarios reales haciendo cosas reales.

La parte de la que nadie escribe

Cada artículo sobre código limpio y refactorización habla de deuda técnica en términos de rendimiento, escalabilidad, mantenibilidad. Son conceptos reales, pero hay otro riesgo que nadie menciona cuando eres un desarrollador independiente trabajando en un proyecto paralelo:

La motivación.

He abandonado proyectos antes. No porque la idea fuera mala ni porque el código estuviera roto, sino porque la distancia entre donde estaba y donde quería estar parecía infinita, y me faltaba energía para recorrerla. Reescribir duplica esa distancia. No avanzas; reconstruyes terreno ya recorrido, solo que más limpio.

La reescritura no falla porque el código nuevo sea peor. Falla porque nunca se termina.

Lanzar con código feo no fue una decisión técnica. Fue una decisión de supervivencia del proyecto.

Cómo mejoré el código (con usuarios presionando)

Lo que hice en cambio fue más aburrido y más efectivo: mejoras incrementales, guiadas por la presión real de los usuarios.

Tres reglas simples:

1. Cualquier nueva feature se escribe con los estándares que quiero tener.
2. Cuando toco código viejo para una fix o una feature, lo dejo mejor de como lo encontré.
3. Cuando algo duele tanto que frena el desarrollo, ahí sí lo refactorizo con dedicación.

No fue glamoroso. Pero funcionó.

Con Keppli, el código de los primeros meses nada tiene que ver con el de hoy. No hubo un momento de reescritura total —hubo cientos de momentos pequeños donde cada vez que abría un archivo, salía un poco mejor.

Cuando lancé Capturioo, la segunda app, ya cometía menos errores de diseño desde el día uno. No porque hubiera estudiado arquitectura de software, sino porque había sufrido las consecuencias de no hacerlo.

Qué pasó

Hoy, Keppli Finance tiene más de 1.000 usuarios activos. Capturioo, que es mucho más nueva, ya supera los 40 usuarios y crece semana a semana.

Esos números no los generó el código limpio. Los generó haber lanzado.

Y el código que existe hoy —imperfecto, mejorable, con partes que todavía me dan vergüenza— es infinitamente mejor que el código perfecto que hubiera escrito si me hubiera quedado refactorizando antes del lanzamiento. Porque ese código perfecto no tendría usuarios. No habría sobrevivido lo suficiente para mejorar.

Lo que hace que el código mejore no es tener tiempo para refactorizar. Es tener usuarios que te obligan a hacerlo.

Lo que realmente aprendí

El mayor riesgo para un desarrollador independiente no es la mala arquitectura. Es no llegar nunca al mercado.

Todos los desarrolladores tenemos el instinto de reescribir. Leemos código desordenado y lo primero que pensamos es: “Empecemos de nuevo”. Ese instinto se vuelve más fuerte cuando tienes las herramientas para hacerlo bien. Frameworks modernos, linters, test runners, agentes de IA que te ayudan a generar código impecable. Hacen que una reescritura limpia parezca muy factible.

Y técnicamente, lo es. Pero “técnicamente factible” y “realmente se va a terminar” son dos cosas distintas.

Refactoriza lo que ya tienes. Lánzalo. Pruébalo con usuarios reales. Deja que la arquitectura evolucione bajo la presión de personas reales haciendo cosas reales. El código no será perfecto. No tiene que serlo.

Solo tiene que existir.

Lanza tu código feo.