Cuando decidí construirla
En el capítulo anterior conté cómo una pregunta comenzó a convertirse en algo mucho más grande:
¿Y si las iglesias pudieran tener una infraestructura tecnológica y financiera diseñada realmente para ellas?
La pregunta era interesante.
Pero había un pequeño problema.
Todavía no existía nada.
Y llega un momento en la vida de cualquier idea en que tienes que decidir si seguirá siendo una conversación o si estás dispuesto a hacer el trabajo necesario para convertirla en realidad.
Yo decidí construirla.
Del papel a la pantalla
Hasta ese momento podía imaginar perfectamente cómo debería funcionar Cleus.
Podía pensar en las iglesias.
En las donaciones.
En los fondos.
En los pagos.
En los distintos países.
Incluso podía imaginar una plataforma enorme funcionando algún día.
Pero imaginar un producto es muy fácil.
Construirlo es otra historia.
Porque cuando empiezas a construir aparecen preguntas mucho menos románticas.
¿Cómo represento una iglesia dentro del sistema?
¿Cómo registro una persona?
¿Cómo funciona una donación?
¿Quién puede acceder a la información?
¿Cómo se administran los fondos?
¿Qué pasa cuando una donación falla?
¿Dónde se guarda todo?
Y, sobre todo:
¿Por dónde empiezo?
No tenía todas las respuestas.
Así que hice lo único que podía hacer.
Empecé por lo más básico.
Una línea de código a la vez
Cleus comenzó como comienzan prácticamente todos los productos de software:
con una pantalla vacía y muchas ganas de que esa pantalla dejara de estar vacía.
Empecé a construir la base.
Usuarios.
Iglesias.
Fondos.
Donaciones.
Autenticación.
Paneles.
Formularios.
Poco a poco, las piezas comenzaron a encajar.
No era bonito.
No era perfecto.
Y definitivamente no era la plataforma que imaginaba en mi cabeza.
Pero había algo importante:
ya existía.
Podía abrirlo.
Podía entrar.
Podía hacer clic.
Podía crear información.
Podía ver cómo una idea que antes solamente existía en mi cabeza comenzaba a convertirse en software.
Ese momento parece pequeño desde afuera.
Para mí no lo era.
Porque hasta ese momento Cleus podía desaparecer simplemente dejando de trabajar en él.
Ahora tenía algo que podía mejorar.
Y eso cambia completamente la relación con una idea.
El primer problema: construir algo que realmente sirviera
Construir una aplicación es relativamente sencillo si solamente piensas en funcionalidades.
Puedes hacer una lista interminable:
- usuarios;
- iglesias;
- donaciones;
- reportes;
- métricas;
- configuraciones;
- notificaciones;
- pagos;
- suscripciones.
Y seguir agregando cosas hasta que el producto tenga cientos de funcionalidades.
Pero esa no era la meta.
La pregunta que había detrás de todo era otra:
¿Esto realmente le sirve a una iglesia?
Y esa pregunta empezó a cambiar la forma en que construía.
Una funcionalidad podía ser técnicamente interesante y, aun así, no resolver ningún problema importante.
Otra podía parecer pequeña y terminar siendo fundamental.
Así fui entendiendo que construir Cleus no consistiría simplemente en programar.
Consistiría en descubrir.
Construir.
Probar.
Equivocarme.
Corregir.
Y volver a construir.
La idea empezó a enfrentarse con la realidad
Y entonces ocurrió algo inevitable.
Hasta ese momento podía pensar en las donaciones de una manera bastante sencilla:
Una persona quiere donar.
Ingresa el monto.
Paga.
La iglesia recibe el dinero.
Fin.
Pero eso era solamente lo que veía el usuario.
Por debajo había otra historia.
¿Qué proveedor procesa el pago?
¿Qué ocurre si lo rechaza?
¿Cómo sé que realmente fue aprobado?
¿Cómo recibe Cleus esa información?
¿Qué pasa si el pago queda pendiente?
¿Cómo identifico la transacción?
¿Y qué ocurre con una donación recurrente?
De pronto, aquella idea sencilla comenzó a revelar una complejidad enorme.
Y ahí descubrí algo que cambiaría buena parte del desarrollo de Cleus:
hacer que una persona pueda donar es fácil.
Hacer que todo lo que ocurre detrás de esa donación funcione correctamente es otra historia.
El dinero
Fue ahí cuando Cleus comenzó a entrar en un territorio que inicialmente no había dimensionado.
Los pagos.
Hasta ese momento estaba construyendo software para administrar información.
Ahora tenía que conectarlo con algo mucho más delicado:
dinero real.
Ya no bastaba con que una pantalla funcionara.
Una transacción tenía que funcionar.
Una iglesia tenía que recibir el dinero.
Cleus tenía que registrar correctamente lo ocurrido.
Y si algo fallaba, había que saber exactamente qué había pasado.
Ahí aparecieron conceptos que pronto se convertirían en parte habitual de mi día a día:
APIs.
Webhooks.
Estados de pago.
Transacciones.
Suscripciones.
Donaciones recurrentes.
Comisiones.
Conciliación.
Errores.
Y proveedores de pago.
El primero fue solamente el comienzo.
Porque si realmente quería construir lo que había imaginado en el capítulo anterior, había una decisión que todavía tenía que resolver:
¿Debía construir Cleus alrededor de un único proveedor de pagos o hacer que pudiera conectarse con distintos sistemas?
La respuesta a esa pregunta terminaría cambiando la arquitectura del producto.
Y probablemente también su futuro.
En el próximo capítulo:
04 — El dinero
La primera vez que intenté conectar Cleus con un proveedor de pagos entendí que recibir una donación no era simplemente agregar un botón.
Era entrar en un mundo completamente distinto.
Y ahí comenzó una de las partes más difíciles —y más interesantes— de construir Cleus.
