Si llegaste buscando cuál es la mejor empresa de desarrollo de software de Santiago, la respuesta honesta es que no existe una mejor, y quien te dé un ranking cerrado tiene intereses en el resultado. Lo que sí existe es una rúbrica que puedes aplicar en una sola reunión: quién dirige técnicamente el proyecto y si es la misma persona que te vende, qué pasa si esa persona se va, si la propiedad del código y del dominio queda por escrito a tu nombre, si el alcance dice explícitamente qué queda fuera, si ves software funcionando cada semana o recién al final, si publican rangos de precio, si la garantía tiene plazo escrito y la mantención se cotiza aparte, si te dan el contacto directo de clientes anteriores, dónde y por quién se escribe el código, y cómo tratan tus datos durante el proyecto. Diez preguntas, diez respuestas que un proveedor serio da sin incomodarse.
Este artículo publica esas diez preguntas con la formulación literal que conviene usar y con la respuesta que debería hacerte dudar. Lo escribe Apollo.TI, que es una de esas empresas: al final está declarado cómo cumplimos cada criterio y, más importante, en qué casos no somos la opción correcta.
Por qué la pregunta “cuál es la mejor” no tiene respuesta
Porque “mejor” no es una propiedad de la empresa, es una relación entre la empresa y tu problema. El equipo que construye una plataforma de 2.000 UF con tres integraciones no es el mismo que resuelve bien una landing con formulario, y al revés: contratar a una software factory para un sitio simple es pagar estructura que no vas a usar.
Y hay una razón menos elegante: la mayoría de los rankings de “las mejores empresas de desarrollo de software en Chile” están escritos por empresas de desarrollo de software, que aparecen en su propio ranking y casi siempre en el primer lugar. No hace falta suponer mala fe para descartarlos como fuente: basta con notar que ninguno declara el criterio de selección ni quién lo aplicó. Un ranking sin metodología publicada es una lista de nombres.
Los directorios internacionales son un escalón mejor. Clutch, Sortlist y GoodFirms verifican al reseñador antes de publicar la reseña —contactan a la persona que dice haber sido cliente— y eso ya filtra el testimonio inventado. Pero tienen dos límites que conviene tener presentes: el orden en que aparecen las empresas depende también de si compran posicionamiento en la plataforma, y una empresa chilena que trabaja solo para el mercado local muchas veces no tiene perfil ahí, no porque sea mala sino porque ese directorio no es donde busca clientes.
La forma correcta de usar todo eso: sacar tres o cuatro candidatos de cualquier fuente —un ranking, un directorio, una recomendación de un colega— y después aplicarles tú la misma rúbrica. El valor no está en la lista, está en las preguntas.
La rúbrica: 10 criterios verificables
Cada criterio trae la pregunta literal que le haces al proveedor y qué respuesta es mala señal. Están ordenados por cuánto duele equivocarse.
1. Quién dirige técnicamente, con nombre y apellido
Pregunta: “¿Quién va a ser el líder técnico de mi proyecto, cómo se llama y en qué otros proyectos ha estado? ¿Va a estar en las reuniones semanales o solo aparece en la propuesta?”
Mala señal: que la respuesta sea “nuestro equipo” o “un arquitecto senior” sin nombre; que los perfiles asignados en la propuesta digan “por definir”; que la persona que te vende sea encantadora y desaparezca a la semana de firmar, reemplazada por un ejecutivo de cuenta que traduce mensajes entre tú y alguien que nunca conoces. El patrón tiene nombre en la industria: te vende el equipo A y te construye el equipo B.
2. Continuidad: qué pasa si esa persona se va
Pregunta: “Si mañana el desarrollador principal renuncia, ¿quién sigue? ¿La documentación permite que otra persona tome el proyecto sin partir de cero?”
Mala señal: “no nos ha pasado nunca”. Es la respuesta de alguien que no tiene plan. También es mala señal que todo el conocimiento del proyecto viva en una sola cabeza, sin documentación de arquitectura ni de decisiones. Esta es la diferencia de fondo entre contratar a una persona y contratar a un equipo, y es la razón principal por la que un freelance cuesta menos por hora.
3. Propiedad del código, del dominio y de los accesos
Pregunta: “¿En qué cláusula del contrato dice que la propiedad intelectual del código es mía? ¿El repositorio va a estar en mi organización de GitHub desde el primer commit? ¿A nombre de quién quedan el dominio, el hosting y las credenciales de los servicios de terceros?”
Mala señal: “por supuesto que es tuyo” sin poder mostrarte la cláusula; el repositorio en la cuenta del proveedor “por comodidad”; el dominio registrado a nombre de la agencia; las licencias de servicios pagadas con la tarjeta del proveedor. Es el criterio que más caro sale ignorar, porque no se nota mientras la relación funciona y se nota entero el día que quieres cambiar de proveedor. Cuando eso ya pasó, lo que sigue es un rescate y toma de control del sitio o del sistema, y ese es un proyecto aparte: el procedimiento completo está en cómo tomar el control de un software heredado.
4. Alcance escrito: qué queda fuera
Pregunta: “¿Qué queda fuera del alcance? Dímelo explícito. Y si a mitad de camino pido un cambio, ¿cómo se procesa y a qué tarifa?”
Mala señal: una propuesta que solo lista lo que sí incluye. Todo conflicto de proyecto de software nace en el espacio entre lo que el cliente supuso incluido y lo que el proveedor supuso excluido. Un documento de alcance serio trae criterios de aceptación por entregable —para que “listo” signifique lo mismo para los dos lados—, supuestos y dependencias (accesos, credenciales de terceros, contenidos que entregas tú) y un procedimiento de cambio de alcance con tarifa conocida. El desglose completo de lo que debe traer una propuesta está en qué debe incluir una cotización seria de software.
5. Ritmo de entrega: software funcionando cada semana
Pregunta: “¿Cada cuánto voy a ver software funcionando, no un avance en presentación? ¿Tengo acceso al repositorio y a un ambiente de pruebas desde el primer sprint?”
Mala señal: que la primera demo esté agendada para el mes cuatro; que el acceso al código llegue con la entrega final; que el reporte de avance sea un porcentaje (“vamos en 60%”) en vez de una funcionalidad que puedes usar. El modelo en cascada —definir todo, desaparecer meses, entregar— no falla por ideología: falla porque el error de definición aparece cuando ya no hay presupuesto para corregirlo. Con entrega iterativa el error aparece en la semana tres y cuesta una semana.
6. Precio: rangos públicos y desglose por partidas
Pregunta: “¿Tienen rangos de referencia publicados? ¿Me pueden desglosar esta cotización por partidas, con las horas y los perfiles de cada una?”
Mala señal: un número total sin desglose; una cotización que baja un 40% cuando dices que es cara, porque significa que el primer número no salía de una estimación; cobro por hora sin techo ni estimación de horas totales. Publicar rangos no es una virtud moral, es lo que hace comparable una propuesta: sin referencia externa, no tienes forma de saber si 900 UF es caro o barato para lo que pediste. Los rangos de mercado chileno para 2026 los publicamos en cuánto cuesta un software a medida en Chile, con el desglose por tipo de proyecto, y para casos específicos en cuánto cuesta una API, cuánto cuesta un MVP y cuánto cuesta una app móvil.
7. El día después del go-live
Pregunta: “¿Qué incluye la garantía, cuántos días dura y desde cuándo se cuenta? ¿Cuánto cuesta la mantención mensual, cotizada aparte del desarrollo? ¿Quién contesta un lunes a las 9 de la mañana si el sistema se cae, y en cuánto tiempo?”
Mala señal: una garantía sin plazo escrito; que no distingan entre corregir un defecto (garantía) y agregar una funcionalidad (proyecto nuevo); que la mantención sea “lo vemos después”. La regla de mercado es que mantener un sistema cuesta entre 15% y 20% anual del costo de desarrollo, y ese número tiene que estar en la conversación antes de firmar, porque cambia el costo total a tres años. Para sitios web la mensualidad se cotiza distinto y la banda chilena está en cuánto cuesta la mantención de un sitio web en Chile. Y “respondemos rápido” no es un compromiso: un SLA dice una ventana concreta, como cuatro horas hábiles.
8. Referencias verificables por un tercero
Pregunta: “¿Me das el contacto de dos clientes con proyectos parecidos al mío, para llamarlos yo?”
Mala señal: solo testimonios en su propio sitio, sin nombre de empresa ni cargo de quien los firma; casos de éxito donde el cliente es “una importante empresa del retail”; “por confidencialidad no podemos”. La confidencialidad es real en algunos contratos, pero no en todos a la vez: un proveedor con años de operación tiene al menos dos clientes dispuestos a tomar una llamada de quince minutos. Y cuando llames, la pregunta útil no es “¿quedaste conforme?” sino “¿qué salió mal y cómo lo resolvieron?”. Todo proyecto de software tiene algo que sale mal; lo que distingue a un buen proveedor es lo que hizo después.
9. Dónde y por quién se escribe el código
Pregunta: “¿Quién escribe el código: personas contratadas por ustedes o un tercero subcontratado? ¿En qué país y en qué zona horaria trabajan? ¿Puedo hablar directo con quien construye?”
Mala señal: evasivas. El problema no es que un equipo sea distribuido —casi todos lo son, y funciona—, el problema es la capa intermedia que no te deja hablar con quien escribe el código, y la subcontratación no declarada, donde el margen se reparte en dos y las decisiones técnicas se toman en un lugar donde nadie leyó tu contexto de negocio. Pregunta también por la zona horaria: seis horas de diferencia significan un ciclo de pregunta-respuesta al día.
10. Datos personales y seguridad durante el proyecto
Pregunta: “¿Usan datos reales de producción en los ambientes de prueba? ¿Quién del equipo tiene acceso a la base de datos de mis clientes? ¿Firman un acuerdo de encargado de tratamiento?”
Mala señal: que copien la base de producción al computador de un desarrollador para “probar con datos reales”; que no sepan qué es un encargado de tratamiento; que no exista un documento que diga qué datos salen hacia proveedores de terceros. En Chile esto dejó de ser una buena práctica y pasó a ser una obligación: la Ley 21.719 entra en plena vigencia el 1 de diciembre de 2026 y la Agencia de Protección de Datos Personales puede fiscalizar y sancionar desde esa fecha, con multas que llegan a 20.000 UTM por infracción gravísima. El detalle de lo que exige está en el checklist de la Ley 21.719 para empresas chilenas.
Tres verificaciones que puedes hacer tú, gratis y en diez minutos
Antes de la reunión, no después:
- El RUT y la razón social. Toda propuesta debería venir con razón social y RUT. Consúltalo en el sitio del SII (situación tributaria del contribuyente): confirma que la empresa existe, que tiene inicio de actividades vigente y desde cuándo. Una sociedad constituida el mes pasado no descalifica a nadie, pero es un dato que la propuesta no te dijo.
- La dirección publicada. Que sea una oficina y no una casilla. En un proyecto que va a durar meses, la dirección es donde se notifica si algo sale mal.
- El LinkedIn de la empresa contra lo que dice su sitio. Cuántas personas se declaran empleadas ahí, desde qué año aparece actividad y si los perfiles del equipo técnico existen. Las contradicciones entre las dos fuentes son informativas por sí solas.
El criterio que no cabe en la rúbrica: que te digan cuándo no construir
Hay una pregunta que vale por varias: “¿Existe un producto en el mercado que resuelva esto sin desarrollo a medida? ¿Por qué no me sirve?”
Un proveedor en el que todos los caminos terminan en un desarrollo a medida no está diagnosticando, está vendiendo. En muchos casos la respuesta correcta es comprar un SaaS y configurarlo bien; en otros, conectar los sistemas que ya tienes en vez de reemplazarlos; en otros, automatizar el proceso sin construir un sistema nuevo. El criterio para decidir entre comprar y construir está en software a medida frente a SaaS, y la comparación de costo total a tres años es lo que zanja la discusión.
El sesgo de este artículo, declarado
Esto lo escribe Apollo.TI SPA, una empresa de desarrollo de software con domicilio en Providencia, Santiago. O sea: somos uno de los proveedores que esta misma rúbrica evalúa, y este artículo existe también porque queremos que nos consideres. Lo justo es aplicarnos la rúbrica en público.
| Criterio | Cómo lo cumplimos |
|---|---|
| 1. Quién dirige técnicamente | El líder técnico está nombrado en la propuesta y participa en la demo semanal. No hay ejecutivo de cuenta traduciendo entre tú y el equipo. |
| 2. Continuidad | Modelo software factory: más de un perfil por proyecto (arquitectura, backend, frontend, QA) y documentación técnica como entregable, no como favor. |
| 3. Propiedad del código | Queda en el SOW: propiedad intelectual del cliente, repositorio en tu organización de GitHub desde el primer commit, credenciales de infraestructura a tu nombre. Ver empresa de desarrollo de software. |
| 4. Alcance escrito | SOW con entregables, criterios de aceptación, supuestos, dependencias y qué queda fuera. |
| 5. Ritmo de entrega | Sprints con demo semanal y acceso al repositorio desde el primer día. |
| 6. Precio | Publicamos rangos de referencia de todas las líneas: software a medida, APIs, integración de sistemas y mantención web, con el análisis detrás de cada tramo en el blog. |
| 7. Post go-live | Garantía sobre lo construido y mantención cotizada aparte del desarrollo, para que puedas calcular el costo a tres años. |
| 8. Referencias | Casos de éxito con cliente identificado —la API de calidad del agua de Floskin y la ticketera de El Sentido del Humor, ambas en producción— y contacto de clientes a pedido. |
| 9. Quién escribe el código | Equipo propio distribuido, sin subcontratación oculta. Hablas directo con quien construye. |
| 10. Datos y seguridad | Aprobación humana en todo lo irreversible, permisos acotados por rol y definición escrita de qué datos salen hacia terceros. Es la misma capa que implementamos en cumplimiento de la Ley 21.719. |
Cuándo Apollo.TI no es la opción correcta
Esta parte importa más que la tabla de arriba, porque es la que un ranking nunca publica:
- Si tu presupuesto está por debajo de las ~80 UF. Es el piso de un proyecto nuestro. Bajo eso no es que no queramos: es que el proceso —discovery, SOW, sprints, QA, documentación— cuesta más que el trabajo, y estarías pagando estructura en vez de software.
- Si lo que necesitas es un sitio web simple para un negocio chico. Una web que se vea profesional, cargue rápido y reciba contactos por WhatsApp no requiere una software factory. Para eso está RayoWeb, nuestra rama para micro y pequeña empresa, con planes cerrados desde $129.990. Recomendarte Apollo.TI ahí sería hacerte perder plata.
- Si tu proceso es estándar y un SaaS lo resuelve. Si vas a pagar menos en licencias de lo que cuesta construir y mantener, la respuesta es comprar. Lo decimos en la reunión, no después de la firma.
- Si buscas el menor precio por hora. No lo somos y no intentamos serlo. Un equipo senior cuesta más por hora y suele usar menos horas; si tu criterio de decisión es la tarifa hora aislada, vas a encontrar opciones más baratas que nosotros.
- Si necesitas gente sentada a tiempo completo en tu oficina. Trabajamos por proyecto con entregables, no por dotación de personal.
Cómo aplicar la rúbrica en la práctica
Una reunión de una hora alcanza para las diez preguntas. Lo que recomendamos:
- Manda las diez preguntas por correo antes de la reunión. La velocidad y el detalle de la respuesta escrita ya ordena a los candidatos.
- Compara tres propuestas, no dos. Con dos terminas eligiendo la barata; con tres se ve el patrón y aparece la que está subcotizando el alcance.
- Pon las respuestas en una tabla, un criterio por fila. Es incómodo para el proveedor y clarísimo para ti.
- Llama a las referencias antes de firmar, no después. Es el paso que casi nadie hace y el que más información entrega por minuto invertido.
Si quieres profundizar en cómo se compara una cotización partida por partida, el detalle está en qué debe incluir una cotización seria de software. Y si todavía estás decidiendo qué contratar antes de a quién, el punto de partida es software a medida y su guía de precios 2026.
Preguntas frecuentes
¿Cuál es la mejor agencia de desarrollo de software de Santiago?
No existe una respuesta única, y cualquier ranking que la dé está construido por alguien con intereses en el resultado. Lo que sí existe son criterios verificables: quién dirige técnicamente el proyecto y si esa persona es la misma que te vende, qué pasa con la continuidad si esa persona se va, si la propiedad del código y del dominio queda por escrito a tu nombre, si el alcance dice explícitamente qué queda fuera, si ves software funcionando cada semana o recién al final, si publican rangos de precio, si la garantía tiene plazo escrito y la mantención se cotiza aparte, si te dan el contacto directo de clientes anteriores para llamarlos tú, dónde y por quién se escribe el código, y cómo tratan tus datos durante el proyecto. La mejor empresa para tu caso es la que responde esas diez preguntas sin incomodarse.
¿Cómo sé si una empresa de desarrollo de software es buena?
Por lo que acepta poner por escrito, no por su portafolio. Tres pruebas rápidas que se hacen en una reunión: pide el nombre del líder técnico que va a estar en tu proyecto y pregunta si va a estar en las reuniones o solo en la propuesta; pide la cláusula del contrato donde dice que el código es tuyo y que el repositorio vive en tu organización desde el primer commit; y pide el contacto de dos clientes con proyectos parecidos al tuyo para llamarlos tú. Un proveedor serio responde las tres en el momento. Si alguna genera incomodidad, ahí está el riesgo.
¿Cuánto cobra una empresa de desarrollo de software en Chile?
Depende del tipo de sistema, no del proveedor. Los rangos de mercado en 2026: una web o plataforma acotada a medida entre 80 y 200 UF; un MVP entre 150 y 400 UF; una app web interna o SaaS pequeño entre 400 y 1.000 UF; una app móvil para iOS y Android entre 500 y 1.200 UF; una plataforma empresarial desde 1.000 UF y puede superar las 3.000. Una API, integración o automatización va entre 80 y 500 UF. La mayoría de los proyectos de empresas medianas cae entre 400 y 1.500 UF. Súmale entre 15% y 20% anual del costo de desarrollo para la mantención. El desglose completo está en cuánto cuesta un software a medida en Chile.
¿Sirven los rankings de “mejores empresas de desarrollo de software”?
Sirven como lista de candidatos, no como veredicto. Una parte importante de esos rankings los publica una agencia que se incluye a sí misma, casi siempre en el primer lugar, y no declara el criterio de selección. Los directorios internacionales como Clutch, Sortlist o GoodFirms son mejores porque verifican al reseñador, pero el orden en que aparecen las empresas depende también de si pagan por posicionarse. La forma de usarlos es sacar tres o cuatro nombres y después aplicarles una rúbrica propia.
¿Conviene una empresa grande o una chica?
Depende de cuánto duele que el sistema se caiga. Una empresa chica o un freelance funcionan bien para una pieza acotada, con alcance claro y sin dependencia crítica del negocio: son más baratos por hora y más rápidos de coordinar. Un equipo formal se justifica cuando el sistema tiene que seguir vivo después del lanzamiento, porque hay continuidad si alguien se va, hay más de un perfil, hay contrato con entregables y hay alguien responsable de la operación. Regla práctica: si la caída del sistema detiene la operación de la empresa, no lo dejes en manos de una sola persona.
¿De quién es el código cuando termina el proyecto?
Del cliente, si el contrato lo dice. No basta con que te lo prometan de palabra: tiene que estar la cláusula de propiedad intelectual a tu nombre, el repositorio en tu organización de GitHub desde el primer commit, las credenciales de infraestructura a nombre de tu empresa y la documentación técnica entregada como entregable del proyecto. Si el repositorio está en la cuenta del proveedor por comodidad o el dominio quedó registrado a su nombre, el día que quieras cambiar de proveedor vas a negociar tus propios accesos.
¿Qué preguntas hay que hacerle a una empresa de desarrollo antes de firmar?
Las diez de este artículo: cómo se llama el líder técnico y en qué otros proyectos ha estado; qué pasa si esa persona se va; en qué cláusula dice que el código es mío y a nombre de quién quedan dominio y accesos; qué queda fuera del alcance; cada cuánto voy a ver software funcionando; cómo se desglosa el precio por partidas; cuánto dura la garantía y cuánto cuesta la mantención mensual; el contacto de dos clientes con proyectos parecidos; quién escribe el código y desde dónde; y cómo se tratan los datos personales durante el desarrollo.
¿Importa que la empresa esté en Santiago?
Menos de lo que parece para el trabajo diario y más de lo que parece para el contrato. El desarrollo es remoto en casi todos los casos y la calidad no cambia por la comuna. Lo que sí importa es que exista una razón social chilena con RUT verificable, inicio de actividades vigente en el SII y una dirección real, porque de eso depende que puedas exigir el cumplimiento del contrato en Chile. Reunirse presencialmente en la etapa de definición ayuda, pero no es la variable que decide el resultado del proyecto.
En resumen
La pregunta útil no es cuál es la mejor empresa de desarrollo de software de Santiago, sino cuál de tus tres candidatos responde las diez preguntas sin incomodarse. Un ranking te ahorra la búsqueda de nombres; la rúbrica te ahorra el proyecto que sale mal.
Si quieres aplicarnos la rúbrica en vivo, esa es exactamente la conversación que tenemos en un diagnóstico inicial: qué hay que construir, qué no, cuánto cuesta y quién lo hace. Puedes partir revisando cómo trabajamos como empresa de desarrollo de software.