BurnRate está consumiendo ingresos con éxito con Blazor

Conozca a Robert McLaws, un veterano de .NET y un empresario experimentado que tiene una pasión por ayudar a las personas a tener éxito. A lo largo de su carrera profesional, McLaws fue testigo de cómo los capitalistas de riesgo y sus cientos de miles de millones de inversiones no pudieron mejorar significativamente las tasas de éxito de startups. Incluso después de 50 años de inversiones de capitalistas de riesgo, al menos el 70 % de las empresas siguen generando errores en cada fase de crecimiento.

Esa estadística alarmó a McCounts, por lo que se preparó para ayudar a los fundadores y líderes de ingresos a sistematizar su proceso de contratación y a trazar su propio curso de crecimiento sin tener que usar fórmulas de hoja de cálculo. Vio una oportunidad para que la tecnología realizara algunos cálculos valiosos y específicos que facilitarían la planeación del crecimiento escalable y fueran más precisos.

Creación de un algoritmo humano

Años atrás, McLaws había creado un marco de trabajo de la aplicación con ASP.NET para crear un producto de análisis financiero en el espacio inmobiliario comercial. La creación de modelos de capacidad para complejos de apartamentos le pone en el camino para profundizar en los modelos de capacidad de ventas de SaaS y cómo la capacidad humana para el trabajo afecta a la capacidad de una empresa para generar ingresos.

En ese momento es cuando surgió la idea de BurnRate, un sistema de planeamiento de nóminas, demandas e ingresos para equipos de comercialización. McLaws consideró que confiar en la intuición y las suposiciones para determinar los niveles de personal de los equipos clave de ingresos, como el marketing, las ventas y el éxito de los clientes, no era un camino sostenible hacia el crecimiento.

En su lugar, consideró que había una ciencia para ello: un algoritmo que podría ayudar a las empresas a crecer de forma más inteligente usando lo que acuñaba el "Algoritmo de la gente". Como declaró, "estos equipos de [éxito de clientes, marketing y ventas] son responsables de traer dinero en primer lugar, por lo que era esencial hacer los cálculos correctamente, y que fuesen lo suficientemente fáciles para que los equipos de ingresos los usasen de forma intuitiva".

Elección de la pila técnica adecuada

La experiencia de McLaws en matemáticas financieras le enseñó que los lenguajes de programación que usan matemáticas de punto flotante, como JavaScript, no eran suficientes para crear sistemas financieros. La base de este algoritmo debe estar en C# para proporcionar resultados de confianza que se puedan validar de forma coherente.

Cuando dejó su empresa anterior para iniciar BurnRate, tuvo que dejar atrás su marco de trabajo de la aplicación y reinventarlo desde cero. La primera versión de .NET Core acababa de publicarse, por lo que era el momento perfecto para recompilarla para una era moderna.

El back-end era lo suficientemente simple, con Azure SQL y Microsoft Restier más que capaz de administrar las necesidades de API consultables del proyecto. En .NET Core, su "Algoritmo de la gente" era muy rápido y capaz de controlar cálculos profundamente complejos a partir de datos altamente estructurados en fracciones de segundo.

Sin embargo, organizar los datos financieros de la empresa de una forma que permita a las empresas crear varios escenarios y cambiar entre ellos requería una profundidad de arquitectura que no esperaba.

"El uso de capas en escenarios, escenarios primarios, escalas de tiempo y resultados planeados frente a [resultados] reales juntos en un modelo fue suficiente para que mi cabeza girase. Le llevó meses de trabajo intenso e intentos repetidos para hacerlo funcionar", indicó. McLaws dijo que el número de pruebas unitarias que BurnRate usa en su algoritmo para garantizar la funcionalidad correcta "es probable que los pedidos de magnitud sean superiores a los que compilan la mayoría de otras empresas con su aplicación. Estamos pidiendo a las empresas que tomen decisiones sobre el futuro de toda su empresa con esta plataforma. No podemos permitirnos que no sea así".

BurnRate creó todo el marco de trabajo de pruebas de código abierto llamado Breakdance para aumentar la productividad de las pruebas unitarias y escribir pruebas más coherentes en menos tiempo.

El front-end presentó diferentes retos. McLaws comenzó a crear prototipos de BurnRate UI con una combinación de Webpack, TypeScript y Knockout, pero superó varios obstáculos. En ese momento, Webpack no tenía definiciones de TypeScript para facilitar la configuración de compilaciones.

"Con JavaScript, un lenguaje donde cualquier cosa puede ser lo que sea y todo se puede intercambiar en tiempo de ejecución; el error es una configuración predeterminada. El éxito debe ganarse, normalmente a través de una angustia mental", Dijo McLaws.

Cuando, por fin, todo funcionaba y tenía su primer prototipo totalmente funcional, el equipo tuvo problemas de escalado, especialmente al generar planes de contratación para empresas con cientos de empleados.

"Cuando intentamos averiguar cómo hacerlo escalar y controlar las actualizaciones de la interfaz de usuario y los cálculos y el lado servidor, [estábamos] retrocediendo", dijo. "Se estaba haciendo más y más errático en el explorador mientras intentaba presentar las cosas".

Cómo Blazor iluminó el camino a la escalabilidad

Blazor entró en Marketplace en este momento y era una nueva tecnología de front-end.

"La promesa de C# de un extremo a otro en el explorador con JavaScript mínimo era demasiado buena para ignorarla", dijo McLaws.

El uso de C# entre el lado cliente y servidor no solo ha hecho que el desarrollo de aplicaciones "sea mucho más fácil", según McLaws, sino que también ha tenido un rol crítico para hacer que la interfaz de usuario de BurnRate sea tan confiable como sus cálculos.

Podemos escribir pruebas unitarias en el mismo lenguaje en el que estamos escribiendo el código de back-end. ¡Eso es enorme! ¿Por qué no querer crear de esa manera? Eliminó miles de líneas de código y era tan intuitiva para cualquier persona que hubiera pasado incluso cinco segundos en el mundo de WPF."

Con Blazor, BurnRate pudo moverse "muy, muy rápidamente". En lugar de tres años, el equipo había creado un prototipo de Blazor en cuestión de semanas y migró completamente varios cientos de miles de líneas de código en menos de un año.

Una buena parte de ese tiempo se dedicó a crear nuevas herramientas de código abierto para que otras compañías también pudieran crear aplicaciones Blazor más rápidamente, un enfoque que se ajusta a los útiles valores de McLaws.

"Las personas suelen olvidar que cuando se está compilando una plataforma como BurnRate, no solo se necesita la aplicación orientada al cliente, sino que también se necesita la aplicación detrás de la aplicación para los cambios de base de datos y la administración del sistema", dijo.

"Por lo tanto, creamos BlazorEssentials, una biblioteca que habilita el estilo arquitectónico Model-View-ViewModel (MVVM) de XAML en Blazor. Nos permite separar limpiamente la adquisición de datos de la visualización de datos en nuestras aplicaciones. Esto aporta un nivel de simplicidad y coherencia a la arquitectura de la aplicación. Ahora el 100 % de nuestro código base se puede probar en un solo lenguaje con patrones predecibles".

El aprovechamiento de Azure DevOps para la integración continua y la entrega continua (CI/CD) altamente automatizadas permite que el equipo de BurnRate se mueva aún más rápido.

\Tanto si se trata de una nueva aplicación como de una nueva utilidad para una aplicación existente, podemos enviarla a producción en cuestión de horas", afirma McLaws.

A medida que BurnRate se escalaba, era necesario para garantizar la estabilidad de su producto para obtener más elementos incrustados en las operaciones diarias principales de sus clientes. McLaws confió en Microsoft.

Entrega de soluciones sin compromiso

"He elegido Microsoft hace mucho tiempo y Microsoft nunca me ha fallado", dijo.

McLaws es un veterano de .NET de 23 años y cinco veces Microsoft MVP, con sus contribuciones de código abierto, que suman un total de más de 1400 millones de descargas. A día de hoy, continúa desarrollando con Microsoft, sabiendo que hay recursos y una comunidad para crear grandes cosas juntos. Con Blazor, el equipo de BurnRate pudo compilar la aplicación y cumplir la visión de McLaws sin compromisos.

Nunca hubo, en su mente, "ninguna plataforma que no fuera .NET que pudiera admitir ese [nivel] de escalabilidad estable", dijo. Según él, Blazor ha desarrollado su equipo eficiente para crear soluciones más inteligentes y rápidas.