# 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.

URL: https://skyquetz.com/blog/empresa-de-software-a-medida-en-santander
Autor: Santiago Gómez de la Torre
Publicado: 2026-09-06

---
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](/proyectos/eliteestate) y [Packatrack](/proyectos/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](/guias/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:

<table>
<thead>
  <tr>
    <th>
      
    </th>
    
    <th>
      Consultoría
    </th>
    
    <th>
      Desarrollo
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Qué produce
    </td>
    
    <td>
      Un diagnóstico y una decisión: qué hace falta, en qué orden y qué no hace falta
    </td>
    
    <td>
      Un sistema funcionando en producción
    </td>
  </tr>
  
  <tr>
    <td>
      Cuándo se necesita
    </td>
    
    <td>
      Cuando sabes que algo no funciona pero no qué construir
    </td>
    
    <td>
      Cuando el problema y el alcance ya están claros
    </td>
  </tr>
  
  <tr>
    <td>
      Riesgo de saltárselo
    </td>
    
    <td>
      Construir bien lo que no hacía falta
    </td>
    
    <td>
      Quedarse con un informe y ninguna herramienta
    </td>
  </tr>
</tbody>
</table>

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

<table>
<thead>
  <tr>
    <th>
      Lo que oyes
    </th>
    
    <th>
      Qué preguntar
    </th>
    
    <th>
      Qué respuesta es buena señal
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      "Te lo hacemos en una semana"
    </td>
    
    <td>
      Qué entra exactamente en esa semana
    </td>
    
    <td>
      Un alcance corto y concreto, no un proyecto entero comprimido
    </td>
  </tr>
  
  <tr>
    <td>
      "Trabajamos con la última tecnología"
    </td>
    
    <td>
      Por qué esa y no otra para mi caso
    </td>
    
    <td>
      Una razón ligada a tu problema, no a la moda
    </td>
  </tr>
  
  <tr>
    <td>
      "El precio es cerrado"
    </td>
    
    <td>
      Qué ocurre si aparece un caso no previsto
    </td>
    
    <td>
      Que se valora aparte y se decide antes de tocarlo
    </td>
  </tr>
  
  <tr>
    <td>
      "Nosotros nos encargamos de todo"
    </td>
    
    <td>
      De quién son el código, los datos y las cuentas al terminar
    </td>
    
    <td>
      Tuyos, y por escrito
    </td>
  </tr>
  
  <tr>
    <td>
      "Somos de aquí, de Santander"
    </td>
    
    <td>
      Cuántos proyectos lleváis a la vez y quién responde
    </td>
    
    <td>
      Un número concreto y un nombre
    </td>
  </tr>
</tbody>
</table>

## 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](/desarrollo-web-santander). La conversación inicial es gratuita y sin compromiso, y si no somos el encaje correcto se dice ahí mismo.