Segunda entrega del ciclo en el que os cuento cómo montar un negocio desde cero a tiempo real. Hoy toca hablar del socio programador, de las decisiones técnicas iniciales y del software que usaré para construir el proyecto.
Pero antes recordemos que hoy tengo dos clases nuevas del curso de Bootstrap, en las que os cuento el uso de los Glyphicons y de las tablas, dos elementos muy útiles para montar interfaces de forma rápida y consistente.
Hoy cuento con Edu Salado, el socio programador del nuevo negocio que estoy montando a partir de Blinkist, pero en español. Con él os hablo de una de las decisiones más importantes cuando quiero lanzar un negocio online con una base tecnológica: con quién lo construyo y cómo planteo la parte técnica desde el principio.
Edu explica por qué este proyecto le encajó especialmente. Por un lado, porque él mismo se veía como usuario potencial: alguien que quiere leer más libros de los que puede asumir y que valora poder acceder a buenos resúmenes. Por otro, porque veía claramente cómo podía aportar desde la parte de desarrollo. Esa combinación entre entender la necesidad como usuario y saber construir la solución es precisamente lo que hace que un socio técnico pueda aportar muchísimo más que una simple ejecución por encargo.
También os hablo de por qué no usaré WordPress como base principal de la aplicación. No porque WordPress no pueda hacer muchas cosas, sino porque en este caso necesito una plataforma limpia, flexible y pensada específicamente para resúmenes, audios, usuarios, suscripciones y futuras aplicaciones móviles. WordPress podría tener sentido para un blog o una parte de marketing, pero no necesariamente para el corazón del producto.
La idea es empezar con algo sencillo, bien enfocado y fácil de mejorar. A veces el problema no es que falten funcionalidades, sino que sobran demasiadas cosas que no necesito. Y cuando quiero ir lean, conviene construir solo lo imprescindible.
Edu plantea desarrollar la aplicación sin partir de un framework comercial, sino usando su propia base de trabajo, creada a lo largo de años de experiencia. Gestión de usuarios, seguridad, formularios, permisos o acceso a datos pueden convertirse en una base reutilizable que permite avanzar rápido sin depender siempre de herramientas externas.
A partir de ahí entro en cómo organizar técnicamente el proyecto. El primer paso será definir las fases de desarrollo y compartirlas con todo el equipo de forma visual, para que marketing, contenidos, diseño y programación sepan qué está pendiente, qué está en marcha y qué está listo. No todo el mundo necesita entender cada detalle técnico, pero sí saber cuándo puede empezar a trabajar su parte.
La primera gran pieza será la base de datos. Antes de diseñar pantallas hay que entender qué entidades tendrá el proyecto: usuarios, libros, resúmenes, audios, contenidos, suscripciones y relaciones entre todos esos elementos. Edu propone usar MariaDB, una evolución abierta de MySQL que ya está disponible en los servidores con los que trabaja y que ofrece buen rendimiento para este tipo de aplicación.
Después vendrá el back-end, la zona privada desde la que se gestionarán los contenidos. Y aquí insisto en algo que muchas veces se olvida: el back-end también necesita diseño. Si varias personas van a introducir resúmenes, audios y datos de libros, la herramienta debe ser clara, usable y sencilla. Un panel pensado solo para ingenieros acaba limitando el crecimiento del proyecto.
Otro punto clave será preparar una API. Aunque inicialmente la plataforma pueda arrancar con una web, el objetivo es que también tenga aplicaciones móviles y que los datos puedan consumirse desde otros entornos. No hace falta construirlo todo el primer día, pero sí tomar decisiones que no cierren puertas.
También comento la elección de Stripe como sistema de pago. Edu lo destaca porque es sencillo de implementar, competitivo en costes y permite integrar el pago dentro de la propia web, sin sacar al usuario de la página. Desde el punto de vista de conversión, esa diferencia puede ser muy importante frente a alternativas más pesadas o menos integradas.
En cuanto a infraestructura, la conclusión es prudente: para la primera fase, un servidor será suficiente. Pero como el objetivo es que el proyecto pueda escalar, conviene tener en mente distintas opciones: varios servidores, servicios cloud como Amazon Web Services o Azure, separación de recursos, contenido estático, apps móviles, staging y despliegues. La clave es no complicarse antes de tiempo, sino empezar simple, medir, aprender y escalar cuando toque.
Finalmente, Edu me cuenta dónde puedo encontrarle. Su proyecto principal es Softuit, comparador de software que desarrolla junto a Luis Soler, y también acaba de estrenar su blog en edusalado.com, donde habla de desarrollo, proyectos y negocios online.
En definitiva, hoy os cuento una parte fundamental de cualquier proyecto tecnológico: la importancia de sumar perfiles complementarios. Marketing, contenido, diseño, desarrollo, sistemas y estrategia aportan cosas distintas. Y cuando el producto depende tanto de la tecnología, tener a alguien técnico dentro del equipo no solo acelera el desarrollo, sino que mejora la calidad de las decisiones desde el minuto cero.
Como ya sabéis, cada semana analizaré un punto de este nuevo negocio. A veces hablaré de marketing, otras de programación, otras de contenido, sistemas, decisiones estratégicas o herramientas concretas. La idea es verlo todo paso a paso, de forma transparente, para que podáis aplicar estos aprendizajes a vuestros propios proyectos.
Gracias por vuestras valoraciones de 5 estrellas en iTunes, vuestros me gusta y comentarios en iVoox, y por estar al otro lado. Nos escuchamos mañana jueves a las 07:07 con un invitado muy especial. Hasta entonces, muy buenos días :D
