Cómo elegir una empresa de desarrollo de software en Saltillo (y en cualquier ciudad)

Antes de preguntar cuánto cobra un proveedor de software, conviene saber qué evaluar: trabajo real en producción que puedas ver, un proceso con entregables por escrito, el código y los accesos a nombre de tu empresa, y un plan para operar el sistema después de la entrega. Eso pesa más que la tarifa por hora. En Saltillo, Ramos Arizpe y Arteaga hay freelancers, agencias de diseño y consultoras de TI que ofrecen desarrollo de software, y la opción correcta no es la más barata ni la más conocida: depende del tamaño del proyecto y de cuánto se conecta con el resto de tu operación.

¿Freelance, agencia o consultora: cuándo conviene cada opción?

No hay una respuesta única. Depende de qué tan chico o crítico es el proyecto y de cuánto toca tus sistemas y tus datos:

• Freelance. Conviene en proyectos pequeños y acotados, con alcance simple y riesgo bajo si algo sale mal: una página de una sección, un ajuste puntual, un formulario.
• Agencia. Conviene cuando el sitio es sobre todo de marketing y el diseño visual es la prioridad: campañas, identidad de marca, contenido pensado para conversión.
• Consultora de TI o empresa de software. Conviene cuando el sistema se integra con procesos, datos o sistemas del negocio: un cotizador conectado al inventario, un portal para clientes o proveedores, un asistente de IA que lee tus documentos, una herramienta interna que reemplaza hojas de cálculo.

El error más común no es elegir mal entre estas tres opciones, sino usar la equivocada para el tamaño del proyecto: pagar tarifas de consultora por una página simple, o confiarle a un freelance un sistema que ya toca inventario, facturación o varias áreas. Si tu proyecto dejó de ser «una página» y empezó a ser un sistema, estás en el terreno del software a la medida.

¿Qué evaluar antes de firmar?

1. Trabajo verificable y en producción. Pide ver sistemas reales, en línea y en uso, no solo capturas de pantalla o maquetas. Si el proveedor no puede mostrar casos con permiso del cliente, que te lo diga y te enseñe el trabajo en una llamada; eso es mejor que un logotipo sin contexto.
2. Proceso con fases y entregables por escrito. Qué se entrega en cada etapa, cuándo y en qué formato. «Te aviso cuando esté listo» no es un proceso.
3. Propiedad del código, del dominio, de la infraestructura y de los accesos a nombre de tu empresa. El sistema es un activo tuyo y no debería quedar atado a la cuenta personal de un proveedor.
4. Comunicación directa con quien programa. Al menos en los puntos clave del proyecto, no solo con un intermediario comercial que traduce todo de segunda mano.
5. Operación después de la entrega. Qué pasa cuando el sistema necesita un cambio, una actualización de seguridad o deja de funcionar meses después. Quién lo monitorea, quién recibe la alarma y qué cuesta.

¿Qué entregables exigir al cerrar el proyecto?

Antes de firmar, pide que el proveedor confirme por escrito qué vas a recibir al cerrar. No es desconfianza: es la diferencia entre un activo que controlas por completo y uno que depende para siempre de la buena voluntad de quien lo construyó.

1. Código fuente en un repositorio (GitHub, GitLab o similar) a nombre de tu empresa, con historial de cambios, no un archivo comprimido entregado al final.
2. Documentación técnica mínima: qué tecnologías se usaron, cómo se despliega, dónde viven las claves y las variables de los servicios externos.
3. Infraestructura a tu nombre: la cuenta de nube (por ejemplo, tu propia cuenta de AWS), el dominio y el certificado, con la renovación documentada: quién lo paga, cuándo vence y qué pasa si no se renueva.
4. Periodo de garantía por errores de desarrollo, distinto del soporte pagado: cuánto dura y qué tipo de fallas cubre exactamente.
5. Capacitación básica para tu equipo si el sistema incluye un panel de administración o contenido que ustedes mismos van a actualizar.

¿Cuáles son las señales de alerta en un proveedor?

• Trabaja sin contrato ni alcance escrito: todo queda en mensajes de WhatsApp y buena voluntad.
• Registra el dominio, la nube o el hosting a su nombre, no al de tu empresa.
• Da un precio cerrado sin hacer antes un levantamiento de lo que realmente necesitas.
• Promete el primer lugar en Google. La propia documentación de Google para quien contrata SEO dice que nadie puede garantizar la primera posición en sus resultados y que, si alguien lo promete, busques a otro (https://developers.google.com/search/docs/fundamentals/do-i-need-seo).
• Promete porcentajes de ahorro o de mejora antes de medir nada.
• No hace ninguna pregunta sobre tu operación, tus clientes o tus procesos antes de cotizar.

¿El proveedor necesita estar en Saltillo?

El trabajo remoto funciona bien cuando el proceso es el correcto: reuniones agendadas, entregables claros y canales definidos desde el inicio. Pero lo presencial ayuda en ciertos momentos: un levantamiento en planta para entender cómo se mueve la información en piso, una capacitación cara a cara con el equipo que va a usar el sistema, un arranque donde vale más resolver dudas en el momento que por correo. En el corredor industrial Saltillo–Ramos Arizpe, donde muchos proyectos terminan conectados a procesos de planta y no solo a una vitrina digital, esa cercanía acorta los detalles finos.

Si quieres ver quién desarrolla software en la ciudad y cómo comparar, está la guía de empresas de software en Saltillo y la página sobre desarrollo de software e implementación de IA en Saltillo.

¿Y si el proyecto incluye inteligencia artificial?

A las preguntas anteriores se suman tres, porque un proyecto de IA falla distinto que un sistema tradicional:

• ¿Qué métrica define el éxito y cuál es la línea base hoy? Si no se puede medir, no se puede saber si sirvió.
• ¿Cuál es el tope de gasto mensual en modelos y qué pasa cuando se alcanza? El costo de inferencia debe ser un parámetro de la aplicación, con corte automático, no una sorpresa en la factura.
• ¿Qué datos salen de la empresa, a quién y con qué contrato? Los proveedores empresariales lo documentan; por ejemplo, AWS declara que «AWS and the third-party model providers will not use any inputs to or outputs from Amazon Bedrock to train» sus modelos (https://aws.amazon.com/bedrock/faqs/). Pide el documento equivalente de cualquier proveedor que te propongan.

Cómo lo trabajamos nosotros está en implementación de IA.

¿Qué preguntas hacer en la primera reunión?

1. ¿Quién va a programar mi proyecto: la persona con la que estoy hablando o alguien más que todavía no conozco?
2. ¿Qué recibo exactamente en cada fase, y en qué formato?
3. ¿De quién son el código, el dominio y la cuenta de nube una vez que el proyecto termina?
4. ¿Qué pasa si el proyecto se pausa a la mitad, por decisión mía o de ustedes?
5. ¿Cómo se cotizan los cambios después de la entrega: por hora, por bolsa de horas, por proyecto?
6. ¿Quién monitorea el sistema en producción y quién recibe la alarma cuando falla?
7. ¿Dónde viven mis datos y quién tiene acceso a ellos?
8. ¿Con qué tecnologías lo van a construir, y podría otro equipo mantenerlo si ustedes no están?

Si un proveedor responde las ocho sin rodeos, ya sabes más de él que con cualquier presentación comercial.