# Dirac Core > For companies in Colombia and Latin America that already run software and overpay for it: we audit your infrastructure, lower your cloud bill and build what's missing. Initial audit at no cost. ## ES - [Inicio](https://dirac-core-web.vercel.app/es) - [Blog](https://dirac-core-web.vercel.app/es/blog) - [Seis fugas de dinero en AWS que se arreglan en una tarde](https://dirac-core-web.vercel.app/es/blog/fugas-de-dinero-en-aws): Las facturas de nube no se disparan por una decisión grande, sino por seis pequeñas que nadie revisa. Dónde mirar y qué cuesta cada una. ### Seis fugas de dinero en AWS que se arreglan en una tarde Cuando una empresa nos llama porque «la nube se volvió cara», casi nunca hay una decisión grande detrás. Hay seis pequeñas, tomadas hace dos o tres años, que nadie volvió a mirar. Esta es la lista que revisamos primero en una auditoría. Ninguna exige reescribir código ni migrar nada: son cambios de configuración que un equipo puede hacer en una tarde y que se notan en la siguiente factura. Los precios son los de lista de AWS en `us-east-1` a septiembre de 2026. Cámbialos por los de tu región antes de hacer cuentas: en São Paulo, por ejemplo, casi todo cuesta más. ## 1. Discos gp2 que deberían ser gp3 Los volúmenes EBS de tipo `gp2` cuestan USD 0,10 por GB-mes. Los `gp3`, USD 0,08. Mismo disco, misma durabilidad, 20 % menos. La diferencia real suele ser mayor. Con `gp2`, las IOPS van atadas al tamaño: 3 IOPS por GB. Para llegar a las IOPS que pedía la base de datos, muchos equipos pidieron un volumen de 1 TB cuando les bastaban 200 GB. En `gp3` las IOPS se contratan aparte y vienen 3.000 de base, así que además de pagar menos por GB puedes reducir el tamaño. El cambio es en caliente, sin reiniciar la instancia. Empieza por los volúmenes de más de 100 GB. ## 2. Direcciones IPv4 públicas que nadie usa Desde febrero de 2024 AWS cobra USD 0,005 por hora por **cada** dirección IPv4 pública, esté asociada o no. Son unos USD 3,65 al mes por IP. Suena a nada hasta que cuentas. Cada instancia con IP pública, cada NAT Gateway, cada balanceador, cada Elastic IP olvidada de un proyecto que se apagó en 2023. Hemos visto cuentas con más de cincuenta IPs vivas de las que se usaban doce. Public IP Insights, en la consola de VPC, te da la lista en dos clics. ## 3. NAT Gateway procesando tráfico que no debería Un NAT Gateway cuesta USD 0,045 por hora más USD 0,045 por cada GB procesado. El GB procesado se suma al de salida a internet, así que el tráfico que sale de una subred privada hacia internet termina costando alrededor de USD 0,135 por GB. El problema no es el NAT: es lo que pasa por él. Si tus instancias privadas hablan con S3 o con DynamoDB, ese tráfico no tiene por qué salir a internet. Los *gateway endpoints* de VPC para esos dos servicios **no cuestan nada** y sacan ese tráfico del NAT. En cargas que mueven mucho a S3 (backups, ETL, imágenes) esto solo ya cambia el orden de magnitud de la factura de red. ## 4. Volúmenes y snapshots huérfanos Un volumen EBS sin instancia asociada sigue cobrándose igual. Un snapshot de hace cuatro años, también. La causa casi siempre es la misma: alguien terminó una instancia sin marcar «eliminar al terminar», o un script de respaldo que nunca tuvo política de retención. Es dinero puro, sin contrapartida. Antes de borrar nada: etiqueta, avisa y espera una semana. Un snapshot huérfano cuesta poco; borrar el que alguien necesitaba cuesta mucho. ## 5. Logs guardados para siempre Por defecto, los grupos de logs de CloudWatch tienen retención **infinita**. Nadie lo decide; viene así. La consecuencia es que estás pagando almacenamiento por los logs de depuración de un servicio que se apagó, y por cada línea que tu aplicación escribió en modo `debug` durante el mes que a alguien se le olvidó bajarlo. Define retención por grupo: 7 días para depuración, 30 para aplicación, lo que exija tu normativa para auditoría. Si necesitas guardar más, exporta a S3 con reglas de ciclo de vida: ahí el almacenamiento cuesta una fracción. ## 6. Todo a precio de demanda El precio bajo demanda es el precio de no comprometerse. Está bien para lo que no sabes si seguirá existiendo el mes que viene; es caro para lo que lleva dos años encendido sin parar. Dos palancas, de menor a mayor esfuerzo: - **Savings Plans.** Te comprometes a un gasto por hora durante uno o tres años. El plan Compute llega a 66 % de descuento y deja cambiar de familia, tamaño y región. El de EC2 Instances llega a 72 %, pero te ata a una familia y una región. - **Graviton.** Los procesadores ARM de AWS ofrecen hasta 40 % mejor relación precio-rendimiento. Si tu carga es Python, Node, Java o Go y corre en contenedores, el cambio suele ser recompilar y desplegar. | Fuga | Dónde mirar | Precio de referencia | | --- | --- | --- | | Discos gp2 | EC2 → Volúmenes, filtro por tipo | 0,10 vs. 0,08 USD/GB-mes | | IPs públicas | VPC → Public IP Insights | 0,005 USD/hora cada una | | NAT Gateway | VPC → NAT Gateways, métrica de bytes | 0,045 USD/hora + 0,045 USD/GB | | Huérfanos | EC2 → Volúmenes «available» | Precio completo del volumen | | Logs | CloudWatch → Grupos de logs, columna de retención | Almacenamiento sin tope | | Demanda | Cost Explorer → Recomendaciones | Hasta 72 % de descuento | ## Cómo medirlo sin discutir Antes de tocar nada, saca una foto. En Cost Explorer, agrupa por **tipo de uso** y mira los últimos tres meses. Esa tabla es la que vas a comparar después, y es la que convierte «creo que bajó» en un número. Dos reglas que nos ahorran problemas: 1. **La primera semana no se apaga nada.** Se etiqueta, se mide y se avisa. Apagar rápido es como se tumba producción y como se pierde la confianza del equipo para la segunda ronda. 2. **Un cambio por despliegue.** Si mueves gp3, retención y Savings Plans el mismo día, no sabrás cuál de los tres explicó la diferencia. Ninguna de estas seis fugas es un error de arquitectura. Son ajustes que nadie tuvo tiempo de revisar porque el equipo estaba entregando funcionalidad, que es su trabajo. Por eso funcionan tan bien como primer paso: se arreglan solas en una tarde y compran el tiempo para las decisiones grandes. - [Qué automatizar primero (y qué no automatizar nunca)](https://dirac-core-web.vercel.app/es/blog/que-automatizar-primero): Un criterio simple para elegir el primer proceso a automatizar, y las tres señales de que un proceso todavía no está listo para serlo. ### Qué automatizar primero (y qué no automatizar nunca) La conversación sobre automatización casi siempre empieza por la herramienta: si Zapier o n8n, si un agente o un script, si conviene meter un modelo de lenguaje. Es la pregunta equivocada, y se nota seis meses después, cuando hay cuatro automatizaciones a medias y alguien sigue copiando datos a mano. La pregunta correcta es cuál proceso. Y para eso hay un criterio que funciona mejor que la intuición. ## El criterio: frecuencia por dolor, dividido entre variación Ordena los procesos candidatos por tres números que cualquiera de tu equipo puede estimar en diez minutos: - **Frecuencia.** Cuántas veces al mes ocurre. - **Dolor.** Cuántos minutos consume cada vez, contando las interrupciones que genera. - **Variación.** Cuántas excepciones tiene por cada diez ejecuciones. Los dos primeros se multiplican: un proceso de cinco minutos que pasa 200 veces al mes duele más que uno de tres horas que pasa una vez. El tercero divide, y es el que la mayoría ignora. Un proceso con poca variación se automatiza una vez y se olvida. Uno con mucha variación se automatiza, falla en el caso 11, alguien lo parchea, falla en el caso 23, y acaba costando más mantenimiento que el trabajo manual que reemplazó. ## Qué suele ganar En las empresas con las que trabajamos, los primeros puestos casi siempre los ocupan procesos poco glamurosos: - **Conciliaciones.** Cruzar el extracto bancario con la facturación, los pagos de la pasarela con los pedidos, el inventario del sistema con el del almacén. Alta frecuencia, reglas claras, dolor concentrado en un par de personas. - **Informes recurrentes.** El reporte que alguien arma el primer lunes de cada mes pegando cuatro exportaciones en una hoja de cálculo. - **Altas y bajas.** Crear usuarios en cinco sistemas cuando entra alguien, y quitarlos cuando se va. Aquí lo que se gana no es solo tiempo: es cerrar el agujero de seguridad de las cuentas que nadie desactivó. - **Traslado de datos entre sistemas.** El CRM que no habla con la facturación y que alguien concilia a mano cada viernes. Lo que tienen en común: reglas explicables en una página, entradas y salidas estructuradas, y un resultado que se puede verificar automáticamente. ## Las tres señales de que un proceso no está listo **Nadie sabe describirlo entero.** Si para entender el proceso hay que preguntarle a tres personas y cada una cuenta una versión distinta, no tienes un proceso: tienes una costumbre. Automatizar una costumbre congela los errores y los hace más rápidos. Primero escríbelo; a veces, al escribirlo, descubres que la mitad de los pasos sobraban. **La excepción es la norma.** Si más de tres de cada diez ejecuciones necesitan criterio humano, lo que tienes no es un proceso repetitivo, es un trabajo. Automatiza la parte que sí se repite —traer los datos, prellenar el formulario, dejarlo listo para que alguien decida— y deja la decisión donde está. **No hay forma de saber si salió bien.** Toda automatización falla en silencio alguna vez. Si no puedes definir una comprobación automática («los totales cuadran», «hay tantas filas como pedidos»), vas a enterarte del fallo por el cliente. Si no puedes definir la comprobación, todavía no entiendes el proceso lo suficiente. ## Dónde encaja la IA (y dónde no) Un modelo de lenguaje es excelente leyendo texto desordenado: una factura en PDF que cada proveedor maqueta distinto, un correo de un cliente del que hay que sacar cuatro datos, una descripción de producto que hay que clasificar. Es mal candidato para decidir. No porque no acierte, sino porque no acierta **siempre**, y en conciliaciones, pagos o inventario el 98 % de acierto significa que alguien tiene que revisar el 100 % para encontrar el 2 %. La regla que usamos: el modelo **extrae y propone**, las reglas deterministas **validan y ejecutan**. El modelo saca del PDF el NIT, el total y la fecha; una regla comprueba que el NIT existe en la base y que el total cuadra con la orden de compra. Si cuadra, sigue sola. Si no, va a una bandeja para revisión humana con el documento al lado. Así el error del modelo se convierte en trabajo, no en un asiento contable equivocado. ## Empieza por uno, y mídelo Una automatización terminada y medida vale más que cuatro a medias. Terminada significa: corre sola, avisa cuando falla y alguien sabe qué hacer cuando avisa. Antes de empezar, anota dos números: cuántos minutos consume hoy el proceso al mes y cuántos errores tuvo el trimestre pasado. Sin esa foto previa la conversación de después es sobre sensaciones, y las sensaciones no defienden un presupuesto. Después de un mes ya sabes si el criterio funcionó. Y si funcionó, el segundo proceso se elige exactamente igual. - [Cuándo conviene software a medida y cuándo no](https://dirac-core-web.vercel.app/es/blog/software-a-medida-cuando-conviene): Cuatro preguntas para decidir entre comprar, configurar o construir, y por qué el costo de un desarrollo a medida no está donde se suele mirar. ### Cuándo conviene software a medida y cuándo no Nos dedicamos a construir software a medida, así que lo honesto es empezar por lo otro: la mayoría de las veces **no** conviene. Un ERP, un CRM o una herramienta de facturación ya existen, cuestan una fracción y vienen con soporte, actualizaciones y certificaciones que tú tendrías que conseguir aparte. Construir tu propia versión de un producto maduro es una de las formas más caras de perder dos años. Hay casos en los que sí conviene. Estas son las cuatro preguntas con las que los separamos. ## 1. ¿Es esto lo que te hace ganar? Separa tus procesos en dos montones. En uno, aquello por lo que tus clientes te eligen a ti y no al de al lado. En el otro, todo lo demás: nómina, contabilidad, correo, soporte, control de accesos. El segundo montón se compra. Siempre. No importa lo particular que te parezca tu forma de llevar la contabilidad: no es por eso que te compran. El primer montón es el candidato. Si tu ventaja es cómo enrutas los pedidos, cómo cotizas, cómo programas las rutas o cómo priorizas la producción, un producto de catálogo te va a obligar a trabajar como trabajan los demás. Que es exactamente lo contrario de lo que te dio la ventaja. ## 2. ¿Cuánto llevas peleándote con la herramienta? Un producto de catálogo que no encaja no se nota como un error. Se nota como una capa de trabajo alrededor: la hoja de cálculo paralela, el campo «observaciones» donde en realidad va el dato importante, el paso manual entre dos sistemas, la persona que se sabe el truco. Esa capa tiene un costo y casi nunca está en ningún presupuesto. Antes de decidir nada, mídela: cuántas horas al mes, de cuánta gente, y qué pasa cuando esa persona se va de vacaciones. Si la respuesta son dos horas al mes, aguanta. Si son dos personas a jornada completa, ya estás pagando un desarrollo a medida todos los años; solo que sin quedarte con nada. ## 3. ¿Es estable lo que quieres construir? El software a medida funciona bien cuando las reglas cambian despacio. Si el proceso se está inventando todavía, cualquier cosa que construyas va a ir un trimestre por detrás. En esos casos preferimos empezar por lo más barato que resuelva: una configuración, una integración, una automatización sobre las herramientas que ya tienes. Cuando el proceso se asiente —y se nota, porque dejan de cambiar las reglas y empiezan a cambiar solo los volúmenes— se construye. Construir antes de que el proceso esté estable es la razón número uno por la que un proyecto a medida se entrega tarde y llega desactualizado. ## 4. ¿Quién lo mantiene el año que viene? Aquí es donde se decide de verdad el costo, y es lo que menos se mira. Un desarrollo a medida no termina cuando se entrega. Necesita actualizaciones de dependencias, parches de seguridad, un sitio donde correr, alguien que atienda cuando falle un martes a las 11 de la noche. Un producto de catálogo incluye todo eso en la suscripción. Si vas a construir, el presupuesto tiene que incluir el mantenimiento desde el primer día, y la respuesta a «quién» tiene que ser un nombre, no «ya veremos». Sin eso, el sistema que te dio ventaja en el año uno es deuda en el año tres. ## La opción intermedia que casi nadie considera Comprar o construir no son las únicas dos casillas. Entre medias está **construir solo la pieza que te distingue** y comprar el resto. Usar la facturación de catálogo, pero con tu motor de cotización encima. Mantener el ERP como fuente de verdad, y construir la aplicación de campo que tus técnicos usan de verdad. Integrar, no reemplazar. Sale más barato, se entrega antes y se puede deshacer. Y casi siempre resuelve el 80 % del dolor, que es lo que estabas buscando. ## Cómo lo decidimos con un cliente No hacemos esta conversación en abstracto. La secuencia que seguimos: 1. **Medir la capa de trabajo alrededor** de la herramienta actual: horas, personas, errores. 2. **Escribir el proceso** en una página. Si no cabe, el problema no es la herramienta. 3. **Mirar el catálogo otra vez**, ahora con el proceso escrito delante. A veces sí existe, y simplemente nadie lo había buscado con las palabras correctas. 4. **Si no existe, acotar la pieza mínima** que hay que construir y qué se integra con lo que ya está. 5. **Poner número al mantenimiento** antes de empezar, no después. Si al final del paso 3 la respuesta es comprar, lo decimos. Perdemos el proyecto y ganamos la conversación siguiente, que suele ser más interesante. ## EN - [Home](https://dirac-core-web.vercel.app/en) - [Blog](https://dirac-core-web.vercel.app/en/blog) - [Six AWS money leaks you can fix in an afternoon](https://dirac-core-web.vercel.app/en/blog/aws-money-leaks): Cloud bills rarely blow up because of one big decision. They blow up because of six small ones nobody revisits. Where to look, and what each costs. ### Six AWS money leaks you can fix in an afternoon When a company calls us because "the cloud got expensive", there is almost never one big decision behind it. There are six small ones, made two or three years ago, that nobody looked at again. This is the list we check first in an audit. None of it requires rewriting code or migrating anything: these are configuration changes a team can make in an afternoon and see on the next invoice. Prices are AWS list prices in `us-east-1` as of September 2026. Swap in your own region before doing the math: in São Paulo, for instance, almost everything costs more. ## 1. gp2 volumes that should be gp3 EBS volumes of type `gp2` cost $0.10 per GB-month. `gp3` volumes cost $0.08. Same disk, same durability, 20% less. The real gap is usually wider. With `gp2`, IOPS are tied to size: 3 IOPS per GB. To reach the IOPS the database needed, many teams provisioned a 1 TB volume when 200 GB would have done. With `gp3` you buy IOPS separately and get 3,000 as a baseline, so on top of the lower per-GB price you can shrink the volume. The change is live, with no instance restart. Start with volumes over 100 GB. ## 2. Public IPv4 addresses nobody uses Since February 2024, AWS charges $0.005 per hour for **every** public IPv4 address, whether it is attached to anything or not. That is about $3.65 per IP per month. It sounds like nothing until you count. Every instance with a public IP, every NAT Gateway, every load balancer, every Elastic IP left over from a project that was shut down in 2023. We have seen accounts with more than fifty live IPs where twelve were in use. Public IP Insights, in the VPC console, gives you the list in two clicks. ## 3. A NAT Gateway processing traffic it shouldn't A NAT Gateway costs $0.045 per hour plus $0.045 for every GB processed. The processed GB stacks on top of the internet egress charge, so traffic leaving a private subnet for the internet ends up costing around $0.135 per GB. The problem is not the NAT — it is what goes through it. If your private instances talk to S3 or DynamoDB, that traffic has no business going out to the internet. VPC **gateway endpoints** for those two services are **free** and take that traffic off the NAT. For workloads that move a lot of data to S3 (backups, ETL, images), this one change moves your network bill by an order of magnitude. ## 4. Orphaned volumes and snapshots An EBS volume with no instance attached is billed exactly the same. So is a snapshot from four years ago. The cause is almost always identical: someone terminated an instance without "delete on termination" checked, or a backup script that never had a retention policy. It is pure cost with nothing on the other side. Before deleting anything: tag it, announce it, wait a week. An orphaned snapshot costs little; deleting the one somebody needed costs a lot. ## 5. Logs kept forever By default, CloudWatch log groups have **infinite** retention. Nobody decides that; it ships that way. The consequence is that you are paying storage for the debug logs of a service that was switched off, and for every line your application wrote in `debug` mode during the month someone forgot to turn it down. Set retention per group: 7 days for debugging, 30 for application logs, whatever your compliance rules require for audit. If you need to keep more, export to S3 with lifecycle rules — storage there costs a fraction. ## 6. Everything at on-demand price On-demand is the price of not committing. It is fine for anything you are not sure will still exist next month; it is expensive for anything that has been running non-stop for two years. Two levers, easiest first: - **Savings Plans.** You commit to an hourly spend for one or three years. Compute Savings Plans go up to 66% off and let you change family, size and region. EC2 Instance Savings Plans go up to 72%, but lock you to a family and a region. - **Graviton.** AWS's ARM processors offer up to 40% better price-performance. If your workload is Python, Node, Java or Go and runs in containers, the move is usually rebuild and deploy. | Leak | Where to look | Reference price | | --- | --- | --- | | gp2 volumes | EC2 → Volumes, filter by type | $0.10 vs. $0.08 per GB-month | | Public IPs | VPC → Public IP Insights | $0.005 per hour each | | NAT Gateway | VPC → NAT Gateways, bytes metric | $0.045/hour + $0.045/GB | | Orphans | EC2 → Volumes in "available" | Full volume price | | Logs | CloudWatch → Log groups, retention column | Uncapped storage | | On-demand | Cost Explorer → Recommendations | Up to 72% off | ## How to measure it without arguing Before you touch anything, take a snapshot. In Cost Explorer, group by **usage type** and look at the last three months. That table is what you will compare against afterwards, and it is what turns "I think it went down" into a number. Two rules that save us trouble: 1. **Nothing gets switched off in week one.** It gets tagged, measured and announced. Switching off fast is how production goes down, and how you lose the team's trust for round two. 2. **One change per deploy.** If you move to gp3, set retention and buy Savings Plans on the same day, you will not know which of the three explained the difference. None of these six leaks is an architecture mistake. They are adjustments nobody had time to revisit because the team was busy shipping features, which is their job. That is exactly why they work so well as a first step: they fix themselves in an afternoon and buy you the time for the big decisions. - [What to automate first (and what never to automate)](https://dirac-core-web.vercel.app/en/blog/what-to-automate-first): A simple way to pick the first process worth automating, and the three signs that a process is not ready to be automated yet. ### What to automate first (and what never to automate) Conversations about automation almost always start with the tool: Zapier or n8n, an agent or a script, whether a language model belongs in there. It is the wrong question, and you find out six months later, when there are four half-finished automations and somebody is still copying data by hand. The right question is which process. And for that there is a test that works better than intuition. ## The test: frequency times pain, divided by variation Rank your candidate processes by three numbers anyone on your team can estimate in ten minutes: - **Frequency.** How many times a month it happens. - **Pain.** How many minutes it takes each time, counting the interruptions it causes. - **Variation.** How many exceptions it has per ten runs. The first two multiply: a five-minute process that runs 200 times a month hurts more than a three-hour one that runs once. The third divides, and it is the one most people ignore. A low-variation process gets automated once and forgotten. A high-variation one gets automated, breaks on case 11, someone patches it, breaks on case 23, and ends up costing more maintenance than the manual work it replaced. ## What usually wins At the companies we work with, the top spots are almost always unglamorous: - **Reconciliations.** Matching the bank statement against invoicing, gateway payments against orders, system inventory against the warehouse. High frequency, clear rules, pain concentrated on one or two people. - **Recurring reports.** The report someone assembles on the first Monday of the month by pasting four exports into a spreadsheet. - **Onboarding and offboarding.** Creating users in five systems when someone joins, and removing them when they leave. What you gain here is not only time: it is closing the security hole of accounts nobody deactivated. - **Moving data between systems.** The CRM that does not talk to billing, reconciled by hand every Friday. What they have in common: rules you can explain on one page, structured inputs and outputs, and a result you can verify automatically. ## Three signs a process is not ready **Nobody can describe the whole thing.** If understanding the process means asking three people and each tells a different version, you do not have a process — you have a habit. Automating a habit freezes the mistakes in place and makes them faster. Write it down first; sometimes, writing it down, you find half the steps were unnecessary. **The exception is the rule.** If more than three in ten runs need human judgement, what you have is not a repetitive process, it is a job. Automate the part that does repeat — fetch the data, pre-fill the form, set it up for someone to decide — and leave the decision where it is. **There is no way to tell whether it worked.** Every automation fails silently at some point. If you cannot define an automatic check ("the totals match", "there are as many rows as orders"), you will hear about the failure from your customer. And if you cannot define the check, you do not understand the process well enough yet. ## Where AI fits (and where it doesn't) A language model is excellent at reading messy text: a PDF invoice each supplier lays out differently, a customer email you need four fields out of, a product description that needs classifying. It is a poor candidate for deciding. Not because it gets things wrong, but because it does not get them right **every** time, and in reconciliation, payments or inventory, 98% accuracy means somebody has to review 100% to find the 2%. The rule we use: the model **extracts and proposes**, deterministic rules **validate and execute**. The model pulls the tax ID, the total and the date out of the PDF; a rule checks that the tax ID exists in the database and that the total matches the purchase order. If it matches, it goes through on its own. If not, it lands in a review queue with the document next to it. That way a model error becomes work, not a wrong ledger entry. ## Start with one, and measure it One finished, measured automation is worth more than four half-built ones. Finished means: it runs on its own, it alerts when it fails, and someone knows what to do when it alerts. Before you start, write down two numbers: how many minutes the process costs per month today, and how many errors it produced last quarter. Without that baseline, the conversation afterwards is about impressions, and impressions do not defend a budget. After a month you will know whether the test held. And if it did, you pick the second process exactly the same way. - [When custom software is worth it, and when it isn't](https://dirac-core-web.vercel.app/en/blog/when-custom-software-is-worth-it): Four questions to decide between buying, configuring and building, and why the cost of custom software is not where people usually look for it. ### When custom software is worth it, and when it isn't We build custom software for a living, so the honest way to start is with the other side: most of the time it is **not** worth it. An ERP, a CRM or an invoicing tool already exists, costs a fraction, and comes with support, updates and certifications you would otherwise have to earn yourself. Building your own version of a mature product is one of the most expensive ways to lose two years. There are cases where it is worth it. These are the four questions we use to tell them apart. ## 1. Is this the thing you win on? Split your processes into two piles. In one, whatever makes customers pick you over the company next door. In the other, everything else: payroll, accounting, email, support, access control. The second pile you buy. Always. It does not matter how particular your way of doing accounting feels: that is not why anybody buys from you. The first pile is the candidate. If your edge is how you route orders, how you quote, how you schedule routes or how you prioritise production, an off-the-shelf product will force you to work the way everyone else does — which is the exact opposite of what gave you the edge. ## 2. How long have you been fighting the tool? An off-the-shelf product that does not fit does not look like a failure. It looks like a layer of work around it: the parallel spreadsheet, the "notes" field where the important data actually lives, the manual step between two systems, the person who knows the trick. That layer has a cost and it is almost never in anyone's budget. Before deciding anything, measure it: how many hours a month, from how many people, and what happens when that person goes on holiday. If the answer is two hours a month, live with it. If it is two full-time people, you are already paying for custom software every year — you just have nothing to show for it. ## 3. Is what you want to build stable? Custom software works well when the rules change slowly. If the process is still being invented, anything you build will run a quarter behind. In those cases we prefer to start with the cheapest thing that resolves it: a configuration, an integration, an automation on top of the tools you already have. When the process settles — and you can tell, because the rules stop changing and only the volumes do — you build. Building before the process is stable is the number one reason a custom project ships late and arrives out of date. ## 4. Who maintains it next year? This is where the cost is actually decided, and it gets the least attention. Custom software does not end at delivery. It needs dependency updates, security patches, somewhere to run, and someone to answer when it breaks on a Tuesday at 11 p.m. An off-the-shelf product bundles all of that into the subscription. If you are going to build, the budget has to include maintenance from day one, and the answer to "who" has to be a name, not "we'll see". Without that, the system that gave you an edge in year one is debt by year three. ## The middle option almost nobody considers Buy or build are not the only two boxes. In between sits **building only the piece that sets you apart** and buying the rest. Use off-the-shelf invoicing, with your own quoting engine on top. Keep the ERP as the source of truth, and build the field app your technicians actually use. Integrate rather than replace. It is cheaper, it ships sooner and it can be undone. And it usually resolves 80% of the pain, which is what you were after. ## How we decide it with a client We do not have this conversation in the abstract. The sequence we follow: 1. **Measure the layer of work** around the current tool: hours, people, errors. 2. **Write the process down** on one page. If it does not fit, the tool is not the problem. 3. **Look at the market again**, now with the written process in front of you. Sometimes it does exist and nobody had searched with the right words. 4. **If it does not exist, scope the smallest piece** worth building, and what it integrates with. 5. **Put a number on maintenance** before starting, not after. If the answer at the end of step 3 is "buy", we say so. We lose the project and win the next conversation, which is usually the more interesting one.