- Los sistemas de pagos e ingresos son esenciales para monetizar, pero son sistemas centrales complejos que involucran finanzas, producto, soporte al cliente, legal, cumplimiento y ventas, por lo que incluso una falla pequeña puede convertirse en un gran problema operativo
- Las empresas en etapa inicial o los equipos de productos nuevos suelen ver los pagos como un simple problema de ingeniería y tienden a construirlos por su cuenta, pero en realidad las opciones se dividen entre desarrollo propio, terceros e híbridos
- Un sistema de pagos real debe manejar al mismo tiempo idempotencia, manejo de fechas, medición de uso, impuestos, reembolsos, jerarquías de clientes, contratos personalizados, cambios de precios y reconocimiento de ingresos
- Algunos problemas se estabilizan una vez resueltos, pero las reglas fiscales, los errores de clientes, las correcciones manuales y los requisitos de facturación por país siguen creciendo con el crecimiento y la expansión global
- Lo más seguro es enfocarse en las actualizaciones de uso propias del producto y los eventos del ciclo de vida del cliente, y dejar suscripciones, facturación, contabilidad y reconocimiento de ingresos en manos de sistemas de pagos y ERP ya hechos siempre que sea posible
Por qué los pagos no son una función simple
- Los sistemas de pagos e ingresos son indispensables para que un negocio genere ingresos
- Cuando funcionan bien no llaman la atención, pero en realidad son un sistema tipo pulpo que toca al mismo tiempo varias organizaciones y funciones
- Finanzas
- Producto
- Experiencia de usuario
- Soporte al cliente
- Clientes
- Legal
- Cumplimiento
- Ventas
- Si una parte se rompe, los problemas pueden escalar rápidamente hacia las áreas conectadas; y en la práctica se rompen con frecuencia
- Si no puedes cobrar ingresos de forma legal y precisa, los problemas que deben asumir los operadores del negocio aumentan considerablemente
Tres patrones de construcción
- En los sistemas de pagos suele haber tres enfoques
- Desarrollo propio
- Sistema de terceros completo
- Híbrido que mezcla desarrollo propio y terceros
- Las empresas en etapa inicial o los equipos que empiezan un producto nuevo tienden a querer construirlo por su cuenta porque tienen ingenieros y quieren mantenerlo simple
- Si ves los pagos como “poner archivos de cobro en S3 y que una tarea CRON los tome para procesar el pago”, terminas malinterpretando los pagos como un problema solo de ingeniería
- Así como no implementas por tu cuenta la seguridad o el manejo de fechas, conviene no construir todos los pagos desde cero
- El mejor sistema de pagos es el que no tuviste que construir por completo tú mismo
Los 14 dolores de un sistema de pagos propio
-
Idempotencia
- Todas las solicitudes de cobro y recaudación de pagos deben ser únicas e idempotentes
- Este problema aparece al reintentar por límites de API o al aumentar las instancias del sistema de pagos
- Si no se maneja correctamente, surge el riesgo de cobros duplicados
-
Manejo de fechas
- Debes decidir si cobrar cada 30 días o cada mes según la fecha de suscripción
- También debes manejar condiciones como años bisiestos y zonas horarias
-
Prorrateo y saldos restantes
- Debes decidir si aplicar prorrateo solo en upgrades o también en downgrades
- Las opciones incluyen reembolsos, créditos, ignorarlo o bloquear upgrades y downgrades
-
Medición de uso
- Puede haber decenas de formas de calcular el uso
- Puede variar según el tipo de cliente o cambiar con frecuencia
-
Formato de factura
- Puede parecer fácil cuando operas en un solo país
- Al expandirte, debes manejar no solo impuestos sobre ventas, sino también VAT, GST y recargos adicionales por país
- Podrían hacer falta plantillas individuales por mercado
Complejidad que crece en B2B y en la expansión global
-
Jerarquías de clientes complejas
- En especial, los clientes B2B pueden tener subsidiarias y socios, y querer administrar relaciones de facturación
- Hace falta una forma de agregar el uso hacia la entidad que realmente paga
- Estos requisitos suelen aparecer recién después del crecimiento y la expansión
- Si la entidad legal del cliente o la ubicación de uso son diferentes, los impuestos pueden cambiar
- Legalmente puede ser necesario separar estados de cuenta y facturas
- Las reglas relacionadas pueden cambiar cada pocos meses
-
Cobro de pagos y prevención de abandono
- Debes decidir cuándo dejar de reintentar un pago
- Si ocurre un contracargo, debes decidir si cerrar la cuenta, suspenderla o reembolsar
-
Pausa y reanudación
- Cuando un cliente pausa una suscripción, debes decidir qué nivel de acceso permitir
-
Créditos y reembolsos
- Si solo haces reembolsos completos, es relativamente simple
- Si ocurre un error parcial, quizá debas elegir entre reembolsos parciales o créditos de tienda
- También debes decidir por separado si los créditos vencen
Impuestos, contratos y errores humanos
-
Manejo de impuestos
- La complejidad ya aparece con que distintos ítems tengan diferentes tasas impositivas
- A nivel global, las tasas y reglas fiscales cambian con frecuencia
-
Contratos personalizados
- Si solo haces PLG, puede que no sea un problema
- Cuando empiezas a cerrar contratos, rápidamente aparecen excepciones y condiciones especiales que no se pueden configurar fácilmente con los supuestos existentes
-
Errores humanos
- Los clientes cometen errores y se necesitan correcciones derivadas de ellos
- Dentro de la empresa también se puede configurar mal a un cliente y luego tener que corregirlo
- Emitir créditos y volver a emitir facturas consume mucho tiempo
- También deben manejarse los cambios en la información legal del cliente
- Dirección
- VAT ID, etc.
-
Cambios de precio selectivos
- Los cambios de precio muchas veces no se aplican a todos los clientes
- Cuando se aplican solo a clientes nuevos, deben mantenerse distintas versiones de precios para respetar los contratos existentes
-
Reconocimiento de ingresos e ingresos devengados
- Las reglas de reconocimiento de ingresos bajo IFRS-15 tienen una especificación en PDF de 64 páginas
- Si además haces tú mismo integraciones ERP personalizadas, la complejidad aumenta aún más
Problemas que se resuelven una vez y problemas que siguen creciendo
- Algunos problemas cambian con mucha más frecuencia de lo esperado, y otros, una vez resueltos, casi no vuelven a tocarse
- La idempotencia es un ejemplo de problema de ingeniería que, una vez resuelto, rara vez requiere volver a intervenir
- Las reglas fiscales cambian con frecuencia en todo el mundo
- Cuantos más países cubras, más leyes fiscales debes rastrear
- Los errores de clientes ocurren de forma relativamente constante
- A medida que creces, la escala aumenta
- Se necesita más soporte al cliente y más correcciones manuales
- Al principio, los pagos parecen un problema de ingeniería, pero en realidad están arraigados en un espacio de problemas complejo difícil de entender incluso para personas con experiencia en la industria
Áreas que no hace falta construir por cuenta propia
- Conviene delegar tantos problemas de pagos como sea posible a sistemas externos
- Se recomienda adoptar el enfoque de comprar la mayor cantidad posible de soluciones existentes
- Una parte importante de las suscripciones y la facturación puede ser manejada por sistemas de pagos
- Es mejor dejar el reconocimiento de ingresos y la contabilidad a funciones integradas en el ERP que ya usas o en otros sistemas
- El equipo de producto debe enfocarse solo en las partes propias del producto, como las actualizaciones de uso y los eventos básicos del ciclo de vida del cliente
1 comentarios
Opiniones de Hacker News
Es un buen artículo para alguien que tiene que tomar decisiones de facturación pero no tiene mucha experiencia, y también sirve como referencia para quienes ya la tienen.
Dicho eso, me dio mucha risa la frase “¿no se podrían simplemente volcar en S3 los archivos a facturar y hacer que una tarea CRON cobre los pagos?”. Desde la cabeza de un ingeniero, eso no es una buena idea en ninguna situación.
Una decisión de arquitectura de facturación que me gusta es separar al máximo la facturación y los permisos dentro del sistema. Si se trata de una suscripción prepaga, me funcionó bien guardar en los permisos solo la fecha de vencimiento y los detalles de los permisos otorgados durante el período activo, mientras que el sistema de facturación guarda la suscripción y la sincroniza con permisos cuando hace falta. Así es más fácil que una persona facture manualmente, depure y parchee problemas temporales, o agregue una integración con Stripe.
Por supuesto, hay que dejar abierta la posibilidad de escalar a futuro, pero esta decisión en sí no suele limitar demasiado el sistema. No es una idea original mía, pero después de probar otros enfoques con menos éxito, terminé apreciándola especialmente.
Muchos problemas nacen de la diferencia entre pagos y facturación https://www.wingback.com/blog/saas-payment-vs-saas-billing. Cuando recibes tus primeros clientes, basta con cobrar unos cuantos pagos recurrentes, así que es fácil empezar con Stripe o con facturas manuales.
Pero con el tiempo llegan cada vez más clientes empresariales que necesitan permisos más complejos, varios planes, protección para clientes existentes, ciclos de facturación personalizados, condiciones y asignación de permisos a medida. Como la facturación muchas veces no se vuelve un foco técnico, se acumulan pequeños hacks y funcionalidades adicionales, hasta convertirse en un desastre que termina quitándole recursos al desarrollo de producto, frenando ventas o limitando lo que puedes vender.
La complejidad de la facturación tiene muchas trampas y excepciones ocultas, y hoy se volvió aún más compleja porque la mayoría de los planes incluyen múltiples límites y componentes basados en uso, y porque el SaaS se vende en todo el mundo. En empresas de etapa avanzada incluso hay equipos de más de 15 ingenieros dedicados solo a facturación. Estoy de acuerdo en que, si no es el núcleo del producto, no deberías construir tu propio sistema de facturación. Como referencia, soy el CTO de Wingback, una plataforma de facturación para SaaS.
Ahora me dieron ganas de construir un sistema así, y siento que estoy mucho más calificado de lo que pensaba.
https://arnon.dk/why-you-should-separate-your-billing-from-e...
Los clientes guardan los permisos en nuestro sistema y los consultan cuando hace falta; cuando una suscripción se renueva o se elimina del lado del proveedor de pagos, se agregan reglas y permisos. Esto facilita trabajar con uno o varios proveedores de pagos y también deja clara la separación de responsabilidades. Comparto también algunos artículos relacionados, porque encajan mejor en este contexto: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
Un sistema ideal de permisos debería ser dinámico; es decir, las reglas deberían guardarse en la base de datos, debería poder manejar escenarios puntuales como clientes empresariales, y debería tener una capa de políticas encima. Por ejemplo, debería poder soportar casi cualquier escenario, como que el plan Pro permita hasta 5 asientos, o que el plan Growth permita usar cierta función hasta N veces por día.
También es una gran ventaja tener una UI para que personas no técnicas hagan cambios por cliente sin intervención de ingeniería. En roles de ingeniería anteriores, este tipo de cosas siempre terminaba frenando al equipo de desarrollo.
También hay un conjunto de permisos, pero en el medio existe un mecanismo de políticas que decide cuándo aplicar o no aplicar esos permisos. Lo clave es que los permisos no son solo un problema de facturación. El mecanismo de políticas es el pegamento que conecta los permisos con todo lo demás, de modo que puedes conceder permisos a un ejecutivo de tu cliente más grande sin vincularlos a la facturación.
Hace tiempo construí el sistema de facturación y cuentas por cobrar para una pequeña cadena de farmacias, y las aseguradoras a veces enviaban cheques bastante grandes sin ningún aviso.
Aunque no les habíamos facturado nada, llegaban por correo cheques de 150 mil dólares, y recién meses después se daban cuenta del error y pedían que se los devolviéramos. Teníamos una cuenta especial llamada magic money donde se ponía ese dinero. El mundo de la facturación es realmente un barrio de locos.
O sea, ¿no sería que simplemente lo llamaban magic money mientras la deuda de la cuenta individual seguía ahí?
No creo que sea adecuado abordar este tema solo desde el dolor de crear un sistema de facturación propio. Si muchas empresas quieren ir por ese camino, que lo hagan.
Reconozco que los sistemas de facturación son muy complejos. Pero si Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai, etc. tienen ese conocimiento, también se podría reunir en un solo lugar.
Al final, la respuesta correcta es el enfoque que te funcione. Si es un SaaS basado en suscripción, hay una solución adecuada para eso; si es una API basada en uso, hay una solución de facturación adecuada para eso.
En lugar de desalentar la práctica, se podrían reunir en un solo lugar el conocimiento, los enfoques, los paradigmas, los patrones de programación, las buenas prácticas y las mejores prácticas. También hay excepciones de empresas fuera de EE. UU. o Europa que no pueden usar soluciones de facturación como Stripe. Por ejemplo, si eres una empresa venezolana y no puedes crear una cuenta de Stripe, al final tienes que construir tu propia solución de facturación y conectarla a la críptica API SOAP-XML de una pasarela de pagos local.
Por otro lado, “crear tu propio sistema de facturación” se siente parecido a “crear tu propio SIEM” con una configuración de Elastic + Grafana. No lo recomendaría, pero entiendo por qué tantos departamentos de seguridad de TI van por ese camino.
Los sistemas de facturación son menos complejos que aquello con lo que suelen lidiar los desarrolladores. El artículo presenta requisitos legales difíciles como obstáculos, pero en la práctica eso también significa que las especificaciones son fáciles de encontrar y están bien documentadas. Hay partes que cambian con frecuencia, pero suelen estar bien etiquetadas y explicadas.
Estoy de acuerdo en que los SaaS basados en suscripción y las API basadas en uso tienen cada uno una forma de facturación adecuada. Dicho eso, la clave es si vas a permitir que el cliente te traslade la carga de responsabilidad, si los ingresos son lo suficientemente importantes como para validarlos, y si puedes absorber las comisiones o pérdidas.
Una de las cosas que este artículo no cubre es la venta por afiliados, que puede volverse bastante trabajosa según qué tan profundo la implementes.
Es un sistema que permite que otras personas reciban pagos basados en comisión por ventas dentro de la plataforma.
Hay que rastrear el código de afiliado hasta la venta y el usuario, enviar pagos al proveedor de pagos configurado por el afiliado y, si quieres hacerlo bien, también ofrecer una UI para ver métricas de visitantes, tasas de conversión e historial de pagos.
Por suerte, la mayor parte se puede construir de forma gradual. Basta con vincular un código único a un usuario y ese código a ventas con una tasa de comisión específica; el resto se puede manejar manualmente u omitir. Por ejemplo, yo pago a los afiliados una vez al mes por Zelle o PayPal, y no me toma ni 10 minutos. No tengo frontend de seguimiento de conversiones, y nadie ha rechazado participar como afiliado por eso.
Lo que me pareció realmente impresionante fue la necesidad de poder hacer funcionar al revés toda esta máquina de Rube Goldberg.
Quieres mantener la “orden” lo más estática posible, y la “factura” incluso tiene obligaciones legales.
Por ejemplo, supongamos que alguien compró 5 unidades y obtuvo un descuento, pero solo quiere 3, y además había errores tipográficos en el nombre y la dirección. Sin problema: cancelas la factura, creas una nueva por el mismo monto con el nombre y la dirección corregidos, esperas a que llegue la devolución y sea inspeccionada, vuelves a emitir un crédito y creas otra factura nueva.
El envío de devolución queda durante un tiempo en un estado ambiguo, el cliente pide 5 unidades más, una llega rota y quiere reembolso en vez de reemplazo. Como las fechas de envío se dividen en 2, el sistema no aplica el descuento por 5 o más unidades. Lo que al principio parecía ser solo 2 órdenes simples se convierte de golpe en una gran cantidad de transacciones y documentos. El cliente también olvidó su contraseña y creó una cuenta nueva con otro correo. Un año después, al mirar los logs, es difícil entender por qué recibió un descuento si solo compró 3 unidades.
No estoy tan seguro de este consejo. Puede que no necesites la mitad de las funciones que menciona el artículo, y puedes ir construyéndolas de forma gradual a medida que el negocio crece.
Hay que entender conceptos como facturas, créditos, periodos fiscales y cambios prorrateados. Pero ese conocimiento no es una razón para externalizar o comprar sí o sí; es material para tomar mejores decisiones de construir vs. comprar.
La única API externa que necesita un SaaS es un procesador de tarjetas de crédito; si quieres ponerte elegante, quizá dos. Claro que después del primer año habrá mucho trabajo manual, el contador te señalará errores tontos y también aprenderás mucho de contabilidad.
Aun así, si hoy empezara un negocio nuevo, compararía varias soluciones, pero tengo la certeza de que hacerlo uno mismo no da tanto miedo.
Construir el sistema siempre parece fácil, y el primer día de hecho lo es. Pero pronto vas a pasar mucho tiempo explicándole al responsable de finanzas por qué los reportes están totalmente hechos un desastre, y al equipo de soporte por qué falló una factura, por qué se cobró mal el precio de una suscripción y otras muchas excepciones cuya existencia ni siquiera conocías.
Después tendrás que cumplir con regulaciones que cambiaron, o puede que el gateway que elegiste no soporte la región en la que estás creciendo.
Antes de decir “pues solo hay que hacerlo mejor”, recuerda que eso también es tiempo. Tiempo que no se dedica al producto, tiempo que no se dedica a mejorar el modelo de precios, y tiempo que se gasta corriendo en el mismo lugar en vez de hacer crecer el negocio.
Lo demás se puede ignorar, pero si más adelante no puedes calcular impuestos o terminas incumpliendo leyes de conocimiento del cliente (KYC), vas a sufrir de verdad.
Además, que un sistema sea más caro de lo esperado y lo usen muchas empresas que parecen inteligentes no significa que sirva para tu propósito. Mucho menos garantiza que sirva para el propósito que tú quieres. Comprar no significa que ya no tengas que investigar.
El objetivo de quien maneja esta facturación es simple: darle al equipo de ventas las opciones adecuadas para que pueda cerrar contratos. Hay que colaborar con ventas para encontrar cuál es la zona “lo bastante fácil de implementar y suficiente para cerrar el contrato”.
No se puede enfatizar esto lo suficiente. El equipo de ventas sí está generando ingresos. No hay que quejarse porque el sistema de facturación no sea perfecto. Puede sonar chocante, pero cuando hay una relación de negocio en juego, a veces toca arremangarse y hacerlo a mano.
Hay que hacerlo de la forma más simple posible, pero con un sistema que otros equipos de la empresa puedan leer y entender, y que permita ajustes manuales fáciles incluso si hay automatización funcionando. El 80% de por qué Stripe se siente agradable de usar está aquí. Los ajustes manuales son parte de la vida y, aunque en algunos negocios sean raros, tarde o temprano hacen falta.
Prorrateos, calendarios de facturación distintos, pruebas gratis, pruebas de precios nuevos, precios regionales, impuestos regionales, listar paquetes en varias monedas y desplegar precios nuevos de pronto se convierten en una combinación de 6 monedas × X regiones × Y productos × Z calendarios de facturación × L idiomas.
A eso súmale agregar suscripciones nuevas, fusionar planes de suscripción, retirar planes antiguos y mover suavemente a los clientes a planes alternativos nuevos, comunicándolo bien con ellos. Si eres SaaS, casi todo tiene que estar bien automatizado, ser de autoservicio y estar bien probado; si no, te vas a ahogar en soporte al cliente y churn.
Desplegar cambios de precios puede tomar de 3 días a 2 meses, y lidiar con los rastros de contratos personalizados de los inicios es una pesadilla. Si no se puede automatizar fácilmente, no se puede hacer. Consume demasiado tiempo.
Si hubiéramos basado la facturación en algo como los productos mencionados aquí, probablemente podríamos manejar mucho mejor los contratos personalizados por segmento de cliente y el despliegue de cambios de precios.
Hay 2 problemas que no se tratan aquí pero que sí he tenido que manejar directamente.
El primero es el cierre de fin de mes y de trimestre. El artículo habla de un libro mayor de cuentas, pero cuando empiezas a tratar con empresas públicas que tienen que reportar cifras, hay momentos de cierre estrictos y todo debe fluir sin problemas.
El segundo es la contabilidad de efectivo en tránsito. Este artículo asume que el procesador de pagos es 100% exacto y que no hay ningún problema. Cuando creces lo suficiente, debes poder conciliar todo el dinero que entra a la cuenta bancaria con una factura o un ítem de cobro específico. También debes encontrar facturas que no tengan una línea correspondiente en el estado de cuenta bancario y, al revés, manejar casos en los que entra dinero que no está conectado con ningún ítem de factura. También es importante la capacidad de manejar créditos en la cuenta bancaria que no estén vinculados con una factura de cobro.
Se podría decir que todo esto es problema del departamento de contabilidad, pero está muy acoplado al sistema, así que ambos equipos deben trabajar juntos para que no haya discrepancias entre los libros.
Los contadores de verdad tienen que quedarse repetidamente hasta medianoche por el cierre, y la gente de tecnología o negocio vive la situación de necesitar algo del equipo de contabilidad mientras, durante el periodo de cierre, parece que ese equipo hubiera desaparecido de la faz de la Tierra. Incluso vivirlo como familiar es igual.
La contabilidad interna y la cuenta bancaria se van desalineando poco a poco, y el contador ya no sabe por dónde empezar a buscar el problema.
Me da curiosidad qué usa todo el mundo para la gestión de permisos. Si usan un sistema de feature flags, un SaaS separado como Stigg, o si tienen un sistema interno aparte.
Llegué a HN esta mañana porque escribí un artículo sobre usar feature flags para la gestión de permisos: https://prefab.cloud/blog/modeling-product-entitlements-with.... También me inspiró el artículo de Arnon sobre el formato de SKU.
Los feature flags no parecen el lugar perfecto para la gestión de permisos, pero en mi experiencia, al abordar este tipo de problemas, a menudo eran la mejor herramienta disponible. Me gustaría escuchar otras opiniones.
Esos límites y flags se asignan a un “plan”, y el plan se puede asignar a una cuenta. Si se combinan planes, los valores numéricos toman el valor mayor y las etiquetas se combinan como una unión. Además, se pueden sobrescribir o agregar valores por cuenta, de modo que si un cliente necesita PlanX pero una cuota de API personalizada, basta con sobrescribir directamente ese único valor en la cuenta.
Llámenme anticuado, pero no veo por qué habría que subcontratar esto a un tercero.
La solución básica se puede hacer con feature flags, pero los permisos relacionados con facturación y precios, por ejemplo la organización y los cambios de planes y ediciones, se vuelven complejos con el tiempo por la cantidad de requisitos alrededor. Piensen en distintas combinaciones de funciones, asientos, estrategias basadas en uso y medición, suscripciones de equipo, migraciones de planes, planes enterprise únicos, clientes con múltiples suscripciones, periodos promocionales y suscripciones por niveles, agregación de uso, upselling automático, etc.
Como se ve en el artículo, los límites se pueden expresar con flags que tengan valores numéricos, pero la infraestructura de seguimiento de uso igual la tiene que implementar el negocio. En cambio, imaginen exportar ese uso a un servicio de permisos y que los permisos basados en uso se actualicen en tiempo real también entre equipos. Además, otros permisos que dependan de esos también podrían actualizarse. Al acercarse al límite o superarlo, se puede elegir entre un límite blando que permite seguir usando pero avisa al equipo de ventas, o un límite duro que muestra una invitación a actualizar.
En línea con la idea del artículo original, nosotros funcionamos junto con soluciones de facturación existentes en lugar de reinventar la facturación. Estamos bootstrappeando con una salida exitosa anterior y trabajando con clientes iniciales, así que si alguien solo quiere conversar sobre este tema, puede escribirme a trent at planship.io.
Se puede construir todo con feature flags: despliegues beta, autorización basada en roles, permisos de facturación, hasta solicitudes puntuales de clientes. Los mejores feature flags incluso pueden llevar valores opcionales, así que los límites de planes de API también pueden ser feature flags.
¿Es lo mejor? Para cada caso de uso en particular, probablemente no. Pero una vez que los construyes, la tentación de usarlos en todas partes es grande.
Los permisos deben estar claramente conectados con funciones visibles para el cliente y, conceptualmente, son bloques de funcionalidad mucho más grandes. La dificultad de este enfoque es que todavía hay que considerar muchos aspectos relacionados con la facturación. Manejo de clientes morosos, cargos por excedente al superar ciertos límites, varios modelos de precio para la misma función, reinicio o traslado de contadores de uso al cambiar o actualizar planes, etc., van sumando mucha complejidad con el tiempo.
Por eso en Wingback decidimos ofrecer permisos de funciones separados, estrechamente integrados con la cadena de facturación y la medición. Como referencia, soy el CTO. Al final, creo que ambos enfoques pueden funcionar bien según la complejidad de los planes y cuánto hayan invertido ya en feature flags. Tener gating de funciones para clientes facilita mucho el aprovisionamiento de cuentas de clientes y la oferta de paquetes personalizados.
Me cuesta aceptar la estructura general del argumento de “el sistema X es muy complejo, así que no lo construyas tú mismo y usa una solución ya hecha”.
La solución general para X puede ser tremendamente difícil y compleja, pero mi caso de uso solo necesita ciertas partes de esa complejidad. Por eso puedo construir una solución propia que maneje solo la complejidad necesaria, y puede ser mucho más simple que una herramienta ya hecha.
Yo adopto completamente esta postura para fechas y horas. Mi enfoque de fechas y horas solo requiere que una biblioteca ofrezca dos llamadas de función: una que convierta el tiempo epoch en una cadena de hora en formato ISO de una zona horaria específica, y su inversa. No toco ningún otro código de la biblioteca, y el resto de la manipulación de tiempo la manejo en mi propio código con base en esas dos funciones.
Desde el principio hay que entender qué hacer y qué no hacer en el manejo de datos personales, los ciclos y el ciclo de vida de distintas opciones de facturación, límites de reembolsos, soporte de idempotencia, una gestión razonable de transacciones de base de datos con un modelo adecuado para la tarea, emisión de facturas y exposición al cliente, etc.
No necesitas todo de una vez, pero incluso la primera implementación funcional necesita al menos la mitad.
Tiene un aire a “Los 14 sufrimientos de cruzar la calle y por qué deberías comprar y leer mi libro”.
Mucha gente cree que lo mejor es cerrar los ojos y empezar a caminar, y por eso termina con lesiones prematuras o muerta.
Las reglas para cruzar la calle cambian de un país a otro, incluso de una ciudad a otra. Quizá aún no lo sepas, pero hay que mirar a ambos lados. Mucha gente no sabe que es daltónica, no puede distinguir entre rojo y verde, y termina muerta o herida. Miraste a ambos lados, ¿pero miraste hacia arriba? En la ciudad caen objetos de las ventanas; en el campo pueden volar pájaros sobre tu cabeza; y cada vez cae más basura espacial a la Tierra. Los objetos pueden venir de varias direcciones.
No digo que este artículo sea tan malo, pero habría sido mejor si estuviera estructurado como un artículo metodológico. Leería con muchas más ganas algo así que un texto planteado en negativo.
Es el ideal de un proyecto de broma tipo “¿qué tan difícil puede ser?”, pero el problema es que todo es cierto.
Hay innumerables ejemplos, pero si abordas mal el problema, pronto te toparás con la pregunta “¿cuánto debe pagar el cliente?”, seguida de “¿por qué le cobramos esta cantidad y no otra?”. Si esto ocurre con demasiada frecuencia, el equipo de finanzas vendrá a preguntar qué hiciste para que los reportes operativos de la empresa, incluso los reportes que deciden despidos, ya no sean confiables.