Cómo evolucionar un proyecto #nocode que factura +1M€
🇺🇸🇬🇧 First. Do you want read this article in English? Check it here.
Antes que nada, vamos a situarnos, este artículo es una como un “Parte II” del primer artículo que hablábamos sobre montar un proyecto #nocode, si no lo has leído aún te recomiendo leerlo antes 👇
Han pasado ya algunos meses desde esa validación de nuestro proyecto. Edify, con #nocode, unos meses de caos, de aprendizaje y sobretodo… crecimiento, sin duda alguna hay 4 puntos clave que hemos aprendido con #nocode.
- Creatividad al poder → Si quieres, puedes. Solo hay que tener algo de creatividad en el formato de “explicarle” al #nocode que quieres.
- Todo por duplicado → Y cuando digo por duplicado no me refiero a hacer x2 de trabajo, me refiero a tener un backup de lo que vaya a ejecutarse. Quiero mucho a Zapier, pero puede fallar y no podemos perder un lead de +300K€ por un “error de Zapier”.
- No mires debajo de la alfombra mucho → Es normal meter algo de ruido o procesos “extra” que normalmente no harías si hicieras un desarrollo personalizado.
- Validar es sencillo, escalar es complicado → #Nocode es una forma fantástica de validar ideas, procesos y servicios sin duda, pero cuando quieres escalar, ahí es algo más complicado.
Y por ese último punto, estoy escribiendo estas lineas.
¿Cómo hemos podido escalar un producto que factura +1M€ con herramientas #nocode?
Parece que cuando entras con una tecnología en particular como es el caso de #nocode a menos que tengas que un gran equipo de tecnología te tienes que casar con esta tecnología, las típicas frases de:
“Déjalo, si funciona no lo toques”
Son más comunes de lo que me gustaría y durante un tiempo yo mismo tuve esa percepción. Hey! Estamos vendiendo, estamos facturando. ¿Qué necesidad hay de cambiar este flujo?
El problema radicaba básicamente en escalar y mantener la estructura, con #nocode.
#Nocode es una forma fantástica de validar ideas, procesos y servicios, pero cuando quieres escalar tienes limitaciones.
Recordemos nuestro flujo inicial, este flujo ha estado operativo prácticamente hasta Diciembre de 2021.
Este flujo era totalmente operativo y funcional con él hemos superado en 2021 el +1,2M€ de facturación, y sobre el papel es muy funcional y operativo. Reducíamos aproximadamente un 40–50% del tiempo en la creación de oportunidades (leads) pero a más oportunidades que nos venían, más teníamos que mantener (vaya… qué sorpresa 🙃).
Nos encontramos con un problema de mantenimiento, no podíamos dar un buen servicio a todos los clientes porque los procesos de mantenimiento eran costosos con #nocode.
Particularmente con la gestión de ese “maravilloso” dashboard del cliente, al final donde centralizamos toda la información de su nuevo hogar, viviendas visitas, estado, galería de imágenes, etc…. A la que teníamos algunas decenas de clientes, teníamos overbooking de trabajo, los agentes comerciales no podían con el volumen de trabajo. Teníamos un problema de escalabilidad.
Estuvimos algún tiempo haciendo diferentes test, probamos diferentes herramientas para llevar un control de las reformas y que actuara de enlace para comunicarle al cliente. Webflow y su CMS se nos quedaba muy justo y limitado.
Los primeros test fueron muy “dispares” desde probar a que el dashboard fuera una simple página en Notion. (Funcional, pero demasiado simple para el nivel que buscábamos) hasta crear con Retool un panel con diferentes opciones.
El problema es que no podíamos crear nada tan “impersonal” pues al final era comunicar y el nuevo hogar de ese cliente. Además yo soy muy MAP (Minimum Awesome Product), personalmente teníamos que mostrar una experiencia un poco más personalizada. Obviamente sin tener que invertir un dineral en un equipo técnico (el cual en ese momento aún NO teníamos).
Esos fueron los primeros indicios de decirnos a nosotros mismos, que necesitamos YA equipo técnico (desarrolladores).
Durante el proceso de hiring, (que por la pandemia y situación del mercado es casi más fácil encontrar un unicornio que contratar programadores), investigando diferentes herramientas me encuentro con algo nuevo, algo que no había visto. Strapi.
Era un gestor de contenidos, pero enfocado en API, en vez de gestionar y obtener una interfaz (al estilo Webflow) lo que obtenías era un API con objetos en JSON.
Parecía interesante, es decir yo era el dueño del contenido, obtenía un simple JSON con el que poder manejar la información y “pintarla” a mi gusto y necesidades, sin las limitaciones de Webflow.
*Mencionar que por formación soy ingeniero y además front-end, así que no era nada “nuevo” he trabajado con este formato y me sentía bastante cómodo trabajando con él.
Parecía interesante, estuve viendo bastantes videos de Youtube, leyendo algunos post o artículos (Os recomiendo este). Y me decidí a instalarlo en localhost para probar.
En menos de 5 minutos tenía el entorno funcionando en local, creando un simple endpoint en otros 2 minutos.
El planteamiento es sencillo. Instalas el paquete
Configuras los 2–3 pasos y tendrás acceso a un panel para empezar a configurar tus colecciones, crear la estructura de estas, con variable ilimitadas, procesos ilimitados, tamaño ilimitado… un backend-as-a-service!
Configurando todas las variables necesarias que necesitábamos nos generaba un directorio de endpoints (APIs) con las que trabajar… solo teníamos que pintar esos datos que recibíamos en JSON para tener una experiencia más personalizada.
Strapi nos podía solucionar ese proceso de escalabilidad (o al menos validar más puntos críticos) a un coste que tendía a 0, sin tener que invertir en un “back-end” era plenamente autónomo.
Así que nos decidimos a crear un pequeño servicio en AWS con una instancia muy simple. Con Docker (que gran invento por dios!) lo montamos en apenas 10min. Ya teníamos nuestro “backend” funcionando 💪
El siguiente paso era crear una base para trabajar creando esos primeros endpoints, dado que nuestro principal pain era la comunicación de las obras y mantener esa comunicación ese fue nuestro punto inicial de trabajo.
Creamos algunas collections para hace algunas pruebas la interfaz de creación es realmente sencilla, lo único que requiere algo más de “estudio” es la funcionalidad de los Componentes y como se puede reutilizar de forma recursiva dentro de un mismo endpoint, pero una vez lo tienes claro es simple.
Con ello nos generaba una documentación de la API, en formato Swagger, y a partir de ahí con esos endpoints disponibles podíamos crear, editar, eliminar todo lo de ese “backend” a tiro de endpoint. Easy.
La parte más complicada estaba completada, con Strapi, teníamos un gestor de CMS vía API el cual podíamos escalar un poco más, next step, pintar datos.
Justo en ese momento contratamos a la primer persona del equipo técnico, un Front-end con mucha experiencia con React, así que empezamos a darle forma a esos datos.
Con ello creamos un pequeño sistema de gestión de tareas para las reformas y nuestros procesos.
Todo esto mediante un “simple” JSON que obteníamos de esa llamada, algo parecido a esto:
En apenas 3 días teníamos un sistema de tareas para las reformas desarrollado y listo para probar con clientes.
De cara a integrarlo dentro del sistema que teníamos, se nos ocurrió algo tan tonto como simple… un iframe.
Los clientes disponían de un dashboard montado íntegramente en Webflow, queríamos validar esta funcionalidad pero no queríamos tocar todo ese dashboard del cliente al completo. Así que decidimos integrar un simple iframe dentro de la página del cliente.
Este iframe se integraba dentro de Webflow y hacia que se viera el listado de las tareas que había para ese cliente durante la reforma.
Y no solo eso… Strapi también tiene webhooks, un servicio interno que te permite “notificar” cuando pasa algo. En nuestro caso lo utilizamos cuando una tarea era completada. Mediante mi querido Zapier un email al cliente indicándole “X tarea de la reforma ha sido completada” 👏
Era un 2x1, el equipo de reformas que actualmente tenía un bloqueo importante para tener un control de la reforma, ahora ya no solo tenía control sobre la reforma de forma más sencilla e ilimitada, sino que además le comunicaba al cliente sobre los avances.
Con Strapi hemos ahorrado aproximadamente un 25% del tiempo en la fase de reformas, y lo más importante hemos validado por muy poco funcionalidades y procesos super interesantes.
No puedo decir que ahora seamos super escalables, pero sobretodo hemos podido validar en muy muy poco tiempo ciertas hipótesis que teníamos con los clientes sin tener que invertir una gran cantidad de dinero.
Habíamos empezado la transición de #nocode a custom code, sin que ello fuera un drama gigante.
Teniendo eso en cuenta nuestro “nuevo stack” se quedaba de la siguiente forma:
Desde Hubspot seguimos controlando todo el proceso comercial de ese cliente, pero ahora con Strapi controlamos ese proceso de reformas con la información totalmente centralizada, más fácil para el equipo de reformas y sobretodo… con información más visual, veraz y simple para el cliente.
Win-win.
¿Qué 3 cosas hemos ganado con este proceso de low-code?
- 1️⃣ Mini-automatización → Teniendo el pleno control de ese “backoffice” propio con Strapi hemos podido automatizar condiciones un poco más completas
- 2️⃣ Validar producto API a coste bajo → Hemos creado nuestros primeros modelos y endpoints API, lo cual hemos aprendido algunos puntos críticos a un coste muy bajo antes de irnos a un modelo full-custom-code, además iterar estos modelos es muy muy sencillo.
- 3️⃣ Personalización → Obviamente al ser un producto 100% propio tenemos el pleno control adaptando esos endpoints y APIs a nuestras necesidades y con un front-end que sepa trabajar con JSON podemos hacer cosas muy interesantes con un mayor nivel de personalización sin tener que desarrollar back-end.
Con ello nuestros clientes tienen más información. La cual es critica, pues al final están pagando un ticket medio de 200K€, y es sino la mayor una de las mayores inversiones de sus vidas, necesitan visibilidad de lo que está ocurriendo, a mayor visibilidad, mayor seguridad, a mayor seguridad, más confianza.
En un producto de ticket alto y que encima el proceso tarda semanas o meses, es crucial mantener una comunicación proactiva con el cliente.
El siguiente paso que tenemos encima de la mesa es esa transición final hasta custom-code creando un backoffice completamente personalizado para todas las fases de nuestros clientes, pero hasta ese momento Strapi nos está ayudando a validar y entender que es lo que necesitan nuestros clientes a un coste muchísimo más bajo que desarrollarlo custom desde el principio… pero eso vendrá en la parte 3 👋
Nada es particularmente difícil si lo divides en pequeñas tareas. (Henry Ford)
Nos vemos pronto…
Por cierto si estás estás pensando en comprar y reformar una casa en Valencia o Madrid (España) podemos ayudarte 😃 👇
¿Te ha gustado el post?
¡Dale claps! puedes darle hasta 50 veces al clap, y que mucha más gente encuentre y conozca este post, y claro… no te olvides de compartir.
¡Veamos esos aplausos!
