Santiago Gómez de la Torre

Empresas de software a medida en Santander: cómo elegir la correcta

Cómo se elige una empresa de desarrollo de software a medida en Santander: qué son de verdad los rankings de mejores agencias, si la cercanía importa y qué preguntar antes de firmar.

Elegir empresa de desarrollo de software a medida en Santander se decide con cuatro comprobaciones: qué ha construido antes y se puede abrir hoy, quién va a escribir el código de tu proyecto en concreto, de quién es ese código cuando termina, y si la cercanía física cambia algo en tu caso. Ninguna de las cuatro la responde el listado de "mejores agencias" que devuelve Google, y ese es el primer sitio donde casi todo el mundo empieza.

¿Qué son de verdad las listas de "mejores agencias de Santander"?

Casi nunca son un ranking de calidad. Los primeros resultados de esa búsqueda suelen ser de tres tipos y ninguno evalúa trabajo entregado:

  • Directorios donde se paga la posición. El orden lo decide el plan contratado, no el resultado de los proyectos. Se reconocen porque toda empresa listada tiene ficha completa y ninguna tiene una mala reseña.
  • Artículos escritos por una de las empresas de la lista. Suelen aparecer en primer o segundo lugar en su propio artículo, con la descripción más larga. Es marketing legítimo, pero no es un criterio.
  • Agregadores automáticos que agrupan cualquier empresa dada de alta en una actividad de informática. Ahí conviven consultoras de software, tiendas de reparación de ordenadores y proveedores de hosting.

Sirven para una sola cosa útil: construir una lista larga de candidatos. Para reducirla hay que salir del listado y mirar lo que se puede verificar por tu cuenta.

¿Importa que la empresa esté físicamente en Santander?

Menos de lo que parece, pero no es cero. Conviene separar los casos.

Sí importa cuando el proyecto tiene una parte que ocurre en un sitio físico: instalar o integrar hardware, formar presencialmente a un equipo que no es de oficina, levantar un proceso observándolo en planta o en tienda. También si la forma en que tu empresa decide de verdad es sentándose en una sala, porque forzar eso a videollamada alarga cada decisión.

No importa en la mayoría de los proyectos: una web, una tienda online, un portal de cliente, una automatización o una plataforma de gestión se especifican, se construyen y se revisan igual de bien en remoto. Lo que la gente busca al escribir "en Santander" no suele ser proximidad geográfica, es poder hablar con alguien y que conteste, y eso no lo garantiza un código postal: una empresa a diez minutos con veinte proyectos abiertos responde más tarde que un equipo en remoto con pocos.

Nosotros trabajamos 100% en remoto y no tenemos oficina en Santander, y lo decimos antes de que lo preguntes. Si tu proyecto necesita presencia física, es un criterio legítimo para descartarnos.

Qué mirar en el trabajo anterior (y qué no)

Un portafolio con imágenes bonitas no prueba nada: las capturas se diseñan, no se entregan. Lo que sí prueba algo:

  • URLs que se pueden abrir hoy. Si un proyecto no tiene enlace, pregunta por qué. A veces hay una razón buena (proyecto interno, acuerdo de confidencialidad) y a veces la razón es que ya no existe.
  • Casos que explican el problema, no solo el diseño. Un caso útil cuenta con qué se encontró el cliente, qué se decidió y qué se dejó fuera. Uno que solo enseña pantallas está enseñando a un diseñador, no a un equipo de ingeniería.
  • Que se distinga lo construido de lo planificado. En nuestros propios casos, EliteEstate y Packatrack, esa distinción está escrita: qué funciona hoy y qué está documentado pero no construido.
  • Coherencia entre lo que dicen y lo que tienen. Una empresa que vende posicionamiento y no aparece por sus propios servicios, o que vende webs rápidas y tiene una web lenta, está dando un dato.

Las tres preguntas que casi nadie hace

Las cinco preguntas estándar antes de firmar (qué entra, de quién es el código, qué pasa con los cambios, qué cubre el mantenimiento y quién responde ante un fallo) están desarrolladas en la guía de precios y plazos. Estas tres se hacen mucho menos y suelen explicar mejor la diferencia entre dos propuestas:

  1. ¿Quién va a escribir el código, y puedo hablar con esa persona durante el proyecto? No quién firma la propuesta ni quién viene a la reunión: quién construye. Si la respuesta es "un equipo" sin nombres, o "eso lo gestiona la cuenta", ya sabes cómo va a ser la comunicación los tres meses siguientes.
  2. ¿Qué parte de lo que proponéis es a medida y qué parte es producto de terceros? Una propuesta seria dice claramente qué se resuelve con servicios ya existentes (pagos, correo, facturación, autenticación) y qué se construye de cero. Construir de nuevo lo que ya está resuelto no es rigor técnico, es presupuesto quemado.
  3. ¿Qué pasa con lo que ya tengo funcionando? Casi ningún proyecto empieza en blanco. Hay un ERP, un programa de facturación, una hoja de cálculo que lleva años. La respuesta a si eso se integra, se migra o se ignora cambia el alcance entero.

¿Y si mi sistema actual está en .NET o en una tecnología antigua?

Es una situación normal en empresas con años de operación y conviene resolverla con honestidad por las dos partes. Nuestro stack de construcción es TypeScript con Vue/Nuxt o React/Next.js en el front y Node.js en el backend; no somos la empresa correcta si lo que buscas es alguien que se haga cargo del mantenimiento de una base de código .NET, Java o PHP heredada, y decirlo antes ahorra tiempo a todos.

Lo que sí es habitual y funciona bien: dejar el sistema antiguo donde está y conectarse a él por API para construir encima lo nuevo (el portal de cliente, la automatización, la web que vende). Es más barato y menos arriesgado que reescribir algo que hoy funciona, y evita el proyecto de migración total que tantas empresas empiezan y pocas terminan.

Consultoría de software y desarrollo no son lo mismo

Mucha gente busca "consultoría de software" cuando lo que necesita es que alguien le diga qué construir, no que se lo construya ya. Son dos trabajos distintos y conviene saber cuál estás comprando:

ConsultoríaDesarrollo
Qué produceUn diagnóstico y una decisión: qué hace falta, en qué orden y qué no hace faltaUn sistema funcionando en producción
Cuándo se necesitaCuando sabes que algo no funciona pero no qué construirCuando el problema y el alcance ya están claros
Riesgo de saltárseloConstruir bien lo que no hacía faltaQuedarse con un informe y ninguna herramienta

Cuando las dos las hace el mismo equipo hay una ventaja real (el que diagnostica se responsabiliza de lo que propone) y un riesgo evidente (que el diagnóstico siempre concluya que hay que construir mucho). La forma de controlarlo es pedir por escrito qué se descarta y por qué, no solo qué se recomienda.

Señales rápidas, en una tabla

Lo que oyesQué preguntarQué respuesta es buena señal
"Te lo hacemos en una semana"Qué entra exactamente en esa semanaUn alcance corto y concreto, no un proyecto entero comprimido
"Trabajamos con la última tecnología"Por qué esa y no otra para mi casoUna razón ligada a tu problema, no a la moda
"El precio es cerrado"Qué ocurre si aparece un caso no previstoQue se valora aparte y se decide antes de tocarlo
"Nosotros nos encargamos de todo"De quién son el código, los datos y las cuentas al terminarTuyos, y por escrito
"Somos de aquí, de Santander"Cuántos proyectos lleváis a la vez y quién respondeUn número concreto y un nombre

Cuándo no somos la empresa correcta

Si buscas la opción más barata del mercado, si necesitas presencia física, si quieres mantener una base de código heredada en otro stack, o si tu operación ya cabe sin dolor en las herramientas que usas, hay opciones mejores que nosotros y lo decimos en la primera conversación. Ese criterio también funciona al revés: una empresa que nunca te ha dicho que algo no hace falta probablemente no te lo va a decir cuando le convenga vendértelo.

Si estás valorando proveedores para un proyecto en Santander o Cantabria, puedes ver qué hacemos y cómo trabajamos en la zona. La conversación inicial es gratuita y sin compromiso, y si no somos el encaje correcto se dice ahí mismo.

Tema

Cuánto cuesta y cuánto tarda un proyecto de software

El precio de un proyecto de software depende de cuánto tiene que hacer el sistema, cuánto de eso se construye a medida y qué nivel de calidad técnica se exige debajo; el plazo depende del alcance y de la velocidad con la que el negocio decide y entrega contenido. Ninguna de las dos cosas depende del número de páginas.

Ver la guía completa del tema

Sigue leyendo