Un Departamento Tecnológico Externo es un equipo de desarrollo, diseño, arquitectura y gestión de proyectos que trabaja como extensión del área de tecnología de una empresa, sin que esta tenga que contratar cada perfil por separado. Acompaña el proyecto desde entender el problema hasta el diseño, el desarrollo, las pruebas, la implementación, la garantía y el mantenimiento. Conviene cuando el proyecto necesita varias especialidades y continuidad en el tiempo; para un desarrollo puntual y pequeño, un freelancer suele ser suficiente. Automatizar procesos, desarrollar aplicaciones, conectar sistemas o construir herramientas internas cambia la productividad de una empresa. Pero cuando llega el momento de hacerlo, aparece una pregunta que no es técnica sino de estructura: ¿montamos nuestro propio departamento de tecnología o contratamos un equipo que funcione como si lo fuera? En los últimos años esa segunda opción dejó de ser un arreglo temporal y se volvió un modelo con nombre propio. Y aunque a primera vista parece tercerización, la diferencia está en la relación: no se trata de contratar a alguien para que programe lo que se le pida, sino de tener un equipo que funcione como la extensión tecnológica de la empresa. Qué es un Departamento Tecnológico Externo Es un equipo especializado que trabaja como parte del área de tecnología de una empresa sin pertenecer a su nómina. En lugar de contratar por separado desarrolladores, diseñadores, alguien de infraestructura y alguien que gestione el proyecto, la empresa contrata una estructura que ya existe, con procesos, herramientas y experiencia acumulada. Lo que lo distingue de un proveedor cualquiera es el alcance en el tiempo. El objetivo no es entregar un software y desaparecer: es acompañar desde entender el problema —antes de que exista una sola línea de código— hasta el diseño, el desarrollo, las pruebas, la implementación, la garantía, el mantenimiento y la evolución del producto. La empresa se concentra en su negocio y el equipo tecnológico se concentra en resolverle los problemas de tecnología. Ese reparto es todo el modelo. ¿Por qué no simplemente contratar un freelancer? Porque muchas veces sí conviene, y hay que decirlo antes que cualquier otra cosa. Para una landing page, una automatización puntual, una integración sencilla o un desarrollo pequeño, contratar a una sola persona suele ser más barato y perfectamente suficiente. Recomendar una empresa para eso es venderle a alguien más de lo que necesita. El problema aparece cuando el proyecto crece. Un freelancer termina haciendo a la vez análisis, diseño, programación, pruebas, infraestructura y soporte. Puede hacerlo muy bien —hay gente extraordinaria trabajando así—, pero el proyecto entero queda apoyado en una sola persona: si el trabajo resulta mayor de lo previsto los tiempos se estiran, si hace falta una especialidad que no domina hay que buscarla aparte, y si deja de estar disponible la continuidad se rompe. Por eso la pregunta no es cuál de los dos cuesta menos. Es qué tipo de solución necesitas: algo puntual y acotado, o algo que va a mantenerse, crecer y cambiar durante años. Montar el equipo interno no es contratar programadores Cuando una empresa decide construir su propio departamento de tecnología, lo primero que calcula son los salarios. El costo real está en todo lo demás: Y hay un costo que no aparece en ninguna hoja de cálculo: el tiempo. Cuánto se tarda en encontrar buenos desarrolladores, cuánto en completar el equipo, cuánto en que entiendan cómo funciona la empresa, cuánto en que encuentren una dinámica de trabajo, cuánto en capacitarlos en las tecnologías del proyecto. Durante todos esos meses el proyecto sigue esperando, y esa espera también cuesta. La ventaja real: la estructura ya existe La empresa no empieza buscando cinco profesionales distintos: contrata un equipo que ya trabaja junto, que tiene sus procesos y una forma de comunicarse que no hay que inventar. Eso permite empezar el proyecto en semanas en lugar de en trimestres. Y cuando el proyecto necesita perfiles distintos, el trabajo se reparte por lo que cada uno hace mejor: Esto no significa que un equipo grande sea mejor que uno pequeño; muchas veces es al revés. Significa que cuando un proyecto necesita conocimientos distintos, tenerlos dentro del mismo equipo elimina buena parte de los riesgos que aparecen cuando una sola persona intenta cubrirlos todos. El problema no siempre es la tecnología Después de varios desarrollos a la medida hay un patrón que se repite. Casi siempre llegan dos tipos de cliente, y con ninguno de los dos el trabajo empieza programando. El que ya sabe qué tecnología quiere, pero todavía no qué necesita Llega con una idea técnica muy concreta: necesito Kubernetes, quiero microservicios, quiero esta tecnología porque es la que usan las empresas grandes. Conocer el nombre de una tecnología no significa que sea la adecuada. Kubernetes es una herramienta extraordinaria y los microservicios son una excelente arquitectura, pero ninguna tecnología debería elegirse porque esté de moda. El orden correcto es al revés: primero se entiende el problema, después se analiza qué lo resuelve y solo al final se decide con qué arquitectura y con qué tecnologías. Nos ha pasado varias veces que algo planteado como un sistema distribuido y complejo se resolvía con una aplicación mucho más sencilla. Decirlo también es parte del trabajo: no se trata de vender la tecnología más cara, sino la que el cliente necesita. El que llega con una aplicación ya construida con IA Cada vez es más frecuente: el cliente trae diseños, código, diagramas o cronogramas generados con herramientas de inteligencia artificial. Es útil de verdad —acelera la exploración de ideas, permite ver un prototipo antes de gastar en él y documenta lo que antes nadie escribía—, pero tener archivos generados por IA no es tener una aplicación lista para producción. Una aplicación no empieza con un HTML ni con una carpeta de código. Empieza entendiendo un problema, sigue con una solución diseñada, continúa decidiendo cómo debe construirse y termina desarrollada, probada, desplegada y mantenida. La IA ayuda muchísimo en ese recorrido, pero no elimina las decisiones de ingeniería: alguien tiene que responder por la arquitectura, la seguridad, las integraciones y lo que pase el día que el sistema tenga usuarios reales. Cómo trabajamos un desarrollo a la medida Nuestro proceso empieza bastante antes de escribir código. Primero queremos entender qué necesita la empresa, quién va a usar el software, qué proceso se quiere mejorar y cuál es el resultado esperado. Después analizamos las soluciones posibles, y ahí entran también el presupuesto disponible, el alcance y la arquitectura que tiene sentido para ese caso concreto. Solo entonces se definen las tecnologías. Si el cliente ya llega con una decidida, la analizamos igual: no asumimos que está mal por venir definida de antes, la evaluamos y verificamos si resuelve el problema que hay sobre la mesa. El resultado debería ser una solución equilibrada entre siete cosas que casi siempre tiran en direcciones distintas: La IA también cambió la relación con el cliente Cuando una empresa llega con requerimientos estructurados, documentación, diagramas o una definición clara del producto, el análisis y la cotización avanzan mucho más rápido. Gana el cliente, que recibe una respuesta antes, y gana el equipo, que invierte menos tiempo en levantar información desde cero. Eso no significa que todo lo que genera un modelo sea correcto. Los requerimientos hay que revisarlos, la arquitectura hay que validarla y la solución hay que contrastarla con el problema real. Pero una idea clara y bien ordenada —la haya escrito una persona o la haya ayudado a ordenar una IA— hace que todo el proceso sea más eficiente. Cómo elegir una empresa de desarrollo confiable Los años en el mercado son un indicador, pero no el único ni el más importante: una empresa puede llevar mucho tiempo funcionando y no ser la adecuada para tu proyecto. Estas cuatro cosas dicen más. 1. Sus casos reales No imágenes bonitas: proyectos. Qué problema resolvieron, qué construyeron y qué pasó después de entregarlo. Un caso que no se puede contar con ese nivel de detalle normalmente es porque no existe. 2. El equipo que está detrás Cualquiera puede decir que tiene un gran equipo. Vale la pena saber quiénes lo componen y qué han hecho. Un equipo pequeño con gente con experiencia rinde más que uno grande sin ella. 3. Su presencia digital Búscala. Google, LinkedIn, Instagram, Facebook, donde sea que deba haber rastro de su actividad. Una empresa de tecnología debería poder demostrar que existe, que trabaja y que tiene experiencia — y si no consigue hacerlo con su propia presencia, es difícil que lo consiga con la tuya. 4. Cómo entiende tus requerimientos Esta es la señal más clara de todas. Una empresa competente no se queda en ¿qué quieres que programemos?; pregunta ¿qué problema quieres resolver?, plantea alternativas, explica ventajas y desventajas y recomienda un camino. La experiencia se nota en una reunión, antes de que se escriba una sola línea de código. ¿Sale más económico tercerizar? No hay una respuesta que sirva para todos los proyectos. Lo que sí es cierto es que al contratar un equipo externo la empresa deja de asumir directamente una lista larga de procesos: El beneficio no es solo económico. Es tiempo y complejidad administrativa que la empresa no tiene que gastar en un área que no es la suya. Quién es el dueño del código fuente Es de las primeras preguntas que debería hacer cualquier empresa antes de contratar un desarrollo, y de las que menos se hacen. La propiedad del código, de la documentación y de todo lo que se construya tiene que quedar establecida en el contrato. En ERK Software esas condiciones se pactan al inicio y quedan por escrito, según el alcance y los pagos acordados. Contratar a una empresa de desarrollo no debería significar quedar amarrado a ella. Cómo evitar la dependencia tecnológica Un buen proveedor no debería intentar volverse imprescindible de forma artificial. La documentación, el acceso al código, las decisiones de arquitectura y las condiciones de entrega se definen desde el principio, precisamente para que el cliente pueda irse si algún día quiere irse. Tampoco tiene sentido construir software innecesariamente complejo para generar más mantenimiento. No recomendamos microservicios porque suenen bien: si un monolito pequeño y bien diseñado resuelve el problema, esa es la respuesta correcta, aunque sea la menos vistosa. No solucionamos problemas que todavía no existen. Seguridad y confidencialidad Cuando una empresa entrega información sobre sus procesos, sus clientes, sus productos o sus ideas, la confidencialidad no es un trámite. Los acuerdos de confidencialidad —los NDA— son parte de las herramientas con las que se protege esa información durante el proyecto, y no protegen solo a la empresa: también obligan a las personas que participan directamente en el desarrollo. Qué pasa después de entregar el software El desarrollo no termina el día de la entrega, y conviene dejar establecido desde el principio qué viene después. Según el proyecto puede haber garantía, mantenimiento, soporte o etapas nuevas de desarrollo. En ERK Software ofrecemos garantías, y su alcance y duración dependen del proyecto y de lo que se haya pactado. Hay una distinción que evita casi todas las discusiones posteriores: un error del software no es lo mismo que una necesidad nueva del negocio. Corregir algo que debía funcionar y no funciona entra en la garantía. Construir una funcionalidad que no estaba contemplada es un desarrollo nuevo, y se cotiza como tal. Lo que hemos aprendido desarrollando para empresas La lección principal es que un software exitoso no es el que tiene más funcionalidades, sino el que resuelve el problema para el que se construyó. Hemos tenido clientes que llegaron con soluciones bastante más complejas de lo que necesitaban, y otros que llegaron con una idea técnica muy avanzada que había que convertir en algo real y sostenible. En los dos casos nuestra responsabilidad no es aceptar la propuesta y ponerse a programar: es analizarla, cuestionarla cuando haga falta, proponer alternativas y construir algo que tenga sentido para el negocio. Por eso preferimos un cliente que siga confiando en nosotros durante años a una venta grande que se acaba con la entrega. Somos una empresa colombiana, con profesionales de distintos niveles de experiencia y una idea común de cómo hacer las cosas. Cuándo conviene este modelo Un Departamento Tecnológico Externo tiene sentido si: Y no lo tiene si lo que necesitas es una landing page, una automatización pequeña o un desarrollo puntual: ahí un freelancer va a costarte menos y va a resolverlo igual de bien. La solución correcta depende del problema, no del tamaño del proveedor. Preguntas frecuentes Encontrar a los profesionales adecuados, entrevistarlos y validar de verdad lo que saben. Contratarlos, con las obligaciones laborales y prestaciones sociales que eso implica en Colombia. Comprar equipos, licencias y herramientas. Definir cómo va a trabajar el equipo: procesos, entregas, control de versiones, despliegues. Darles tiempo para que entiendan el negocio, que es lo que nadie puede hacer por ellos. La necesidad real del negocio. El presupuesto disponible. El tiempo en que se necesita funcionando. La escalabilidad, si el volumen va a crecer. La mantenibilidad, que es quién y cómo lo sostiene después. La seguridad de la información que va a manejar. La complejidad técnica que la empresa puede sostener. Reclutamiento y selección de personal. Equipos de trabajo, licencias y herramientas. Capacitación en las tecnologías del proyecto. Organización y gestión técnica del equipo. Rotación de personal y reemplazos. Incorporación de perfiles nuevos cuando el proyecto los pide. Necesitas un software a la medida y no tienes un área de tecnología propia. Tienes equipo, pero te faltan perfiles o te sobra trabajo. El proyecto requiere varias especialidades técnicas a la vez. Vas a necesitar mantenimiento y evolución durante años, no una entrega y ya. Tienes una idea o un prototipo y necesitas convertirlo en un producto que funcione. Quieres automatizar procesos internos y no sabes por dónde empezar.