Respondemos en tres días hábiles

Su pico de tráfico no es un incidente.Es martes.

Altessa Solutions construye plataformas de alta carga, aplicaciones cliente y AI que aguantan en producción. Usted habla con los ingenieros que harán el trabajo, desde la primera llamada.

cada cambio lo lee un segundo ingenieroantes de llegar a producción
Qué
Plataformas de alta carga. Aplicaciones cliente. AI en producción.
Cómo
Proyecto de alcance fijo. Equipo dedicado. Refuerzo de equipo.
Inicio
Semana de diagnóstico, inicio en diez días hábiles.
Sectores
  • Fintech y pagos
  • Movilidad
  • Streaming de medios
  • Telecom
  • Healthtech
  • Marketplaces

Por qué empezamos leyendo

La carga no rompe los sistemas. Lo hacen las decisiones tomadas dos años antes.

Por eso empezamos por su código, no por un presupuesto. La semana de diagnóstico muestra cuáles de esas decisiones aún pueden deshacerse a bajo coste y cuáles no.

§ 01 — Qué hacemos

Tres prácticas que tienen que funcionar juntas.

La mayoría de los proyectos empiezan en una práctica y acaban usando dos. La app necesita un backend que aguante; el backend necesita un modelo que no se salga de su presupuesto.

01

Plataformas de alta carga

GoJavaC#.NETKotlingRPCProtobuf 3KafkaNATSNATS JetStreamRabbitMQPostgreSQLMongoDBClickHouseRedisElasticsearchk8s

Sistemas que se miden en peticiones por segundo. Núcleos orientados a eventos, almacenamiento particionado, escrituras idempotentes y un margen que demostramos con pruebas de carga antes de que sus usuarios lo prueben por nosotros. Bajo sobrecarga, descartan trabajo a propósito en lugar de caerse.

Habitual: 5–8 ingenieros, 4–6 meses, SLO acordado por escrito

  • 01Revisión de arquitectura y planes de migración
  • 02Núcleos de pagos, reservas y streaming
  • 03Migración sin parada: escritura doble, backfill, conmutación
  • 04Un banco de carga que reproduce su pico, más simulacros de fallo
  • 05Diseño de SLO, observabilidad, runbooks de guardia

02

Aplicaciones cliente

SwiftSwiftUIKotlinComposeKMPWinUIC#.NETQtC / C++Java

Nativas para iOS, Android, macOS y Windows, con un núcleo compartido donde compensa. Datos offline-first, telemetría desde la primera build, releases con cadencia fija.

Habitual: 3–5 ingenieros, 3–5 meses hasta la tienda, release cada dos semanas

  • 01Windows 10/11, macOS, Linux, Android, iOS/iPadOS, watchOS
  • 02Publicación en tiendas, CI, despliegues graduales
  • 03Telemetría de fallos, latencia y embudos

03

AI en producción

PythonPyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflow

Recuperación, agentes y servicio de modelos con la parte ingrata terminada: conjuntos de evaluación, guardarraíles, techos de coste, presupuestos de latencia. Una demo lleva un fin de semana; un SLA lleva más. Medimos la calidad sobre sus datos antes del lanzamiento y seguimos midiéndola después.

Habitual: 2–4 ingenieros, 8–12 semanas hasta la primera entrega en producción

  • 01Recuperación y búsqueda sobre sus propios datos
  • 02Flujos de agentes con puntos de control humanos
  • 03Suites de evaluación que bloquean cada cambio de modelo
  • 04Una vía alternativa para cuando el proveedor se cae
  • 05Inferencia autoalojada y control del coste de GPU

§ 02 — Ejemplos

Los problemas por los que nos suelen llamar.

Escrito a partir de patrones en nuestros proyectos, no de un solo cliente. Con qué llega la gente, qué suele haber detrás y qué cambiamos.

“Cada promoción acaba en un incidente y no hay tiempo para reescribir.”

No reescribimos todo. La ruta caliente pasa a su propio núcleo, las escrituras se vuelven seguras de reintentar y la migración corre en vivo mientras el código antiguo sigue sirviendo hasta el último día.

Plataformas · normalmente 5–8 ingenieros, 4–6 meses

“Una release tarda un trimestre y nadie sabe decir por qué.”

Rara vez es el código. Es la regresión manual y una rama que nadie se atreve a fusionar. Separamos el tren de releases del trabajo en funcionalidades, automatizamos el paquete de regresión y ponemos las partes arriesgadas detrás de flags.

Aplicaciones cliente · normalmente 3–5 ingenieros, 3–5 meses

“La demo de AI impresionó a todos y nunca llegó a producción.”

Porque una demo no cuenta el dinero ni responde por los errores. Añadimos un conjunto de evaluación, un techo de coste, una vía alternativa y una persona en el circuito donde un error sale caro.

AI en producción · normalmente 2–4 ingenieros, 8–12 semanas

Lo que usted veLo que hay debajoLo que hacemos

Cada promoción acaba en incidente

Escrituras síncronas a una sola base de datos, pagos duplicados, rollback manual

Núcleo orientado a eventos, escrituras idempotentes, migración sin ventana de mantenimiento

La app sale una vez al trimestre

Regresión manual, dos bases de código, una rama que nadie se atreve a fusionar

Núcleo Kotlin compartido, regresión automatizada, un tren de releases cada dos semanas

Soporte no consigue vaciar la cola

Conocimiento en la cabeza de la gente, respuestas no reproducibles, el piloto de AI nunca salió

Recuperación sobre sus propios datos, evaluaciones en cada release, inferencia autoalojada

También en la lista

  1. 01

    La búsqueda se ralentiza al crecer el catálogo

    Ranking fuera de la base de datos principal, un presupuesto en cada ruta de consulta

    3–4 meses
  2. 02

    La telemetría desbordó su base de datos

    Ingesta en un stream, histórico en un almacén columnar, informes sin timeouts

    3 meses
  3. 03

    Dos bases de código en lugar de un equipo

    Un núcleo KMP compartido, UI nativa donde la plataforma lo espera

    3–5 meses
  4. 04

    Ya no queda nadie que escribiera el sistema

    Una auditoría, decisiones por escrito y un equipo que pueda llevarlo

    desde 1 sem.

§ 03 — Cómo funciona

Cinco pasos, empezando por una semana.

La semana de diagnóstico es un encargo pagado por sí mismo, €12k fijos. Produce una arquitectura, una lista de riesgos ordenada y un precio. Si cualquiera de los tres le decepciona, termina ahí y usted se queda con los documentos.

  1. 01semana 1

    Semana de diagnóstico

    Su código, sus gráficas de carga, su plazo. Leemos antes de hablar.

  2. 02fin de la semana 1

    Arquitectura y estimación

    Un documento: diseño objetivo, ruta de migración, forma del equipo, rango de precio.

  3. 03cada 2 semanas

    Iteraciones de dos semanas

    Incrementos en staging, demostrados en vivo, con el gráfico de consumo adjunto.

  4. 04antes del lanzamiento

    Pruebas de carga y lanzamiento

    Pruebas de resistencia, simulacros de fallo, un rollback ensayado. El día del lanzamiento debería ser aburrido.

  5. 05continuo

    Operar o entregar

    Nos quedamos de guardia, o formamos a su equipo y le dejamos los runbooks.

Lo que tiene en la mano tras la primera semana

  • Arquitectura objetivo, y lo que conservaríamos
  • Registro de riesgos, ordenado por radio de impacto
  • Modelo de capacidad para los próximos 18 meses
  • Forma del equipo, calendario y rango de precio
  • Una decisión go / no-go que puede llevar a su consejo
  • Todo en su repositorio, suyo para siempre

§ 04 — El equipo

Quienes lo diseñan son quienes lo mantienen en marcha.

Cuarenta ingenieros en plantilla. Usted entrevista a las personas que escribirán el código, se quedan en el proyecto hasta terminarlo y nadie es movido a mitad de camino para cubrir un hueco en otra parte.

Backend y plataforma
18
Móvil y escritorio
9
AI y datos
7
SRE, QA, diseño
6

Principio 01

Ingenieros sénior

Mediana de nueve años de experiencia. Los ingenieros junior aprenden en nuestras herramientas internas, no en su producción.

Principio 02

De guardia con usted

Los ingenieros que construyeron un sistema llevan la guardia de ese sistema.

Principio 03

Decisiones por escrito

Cada decisión de arquitectura queda registrada por escrito en su repositorio, no en un mensaje de chat.

Principio 04

Sin ataduras

Su nube, sus repositorios, su CI. Dejarnos debería costar una invitación de calendario, no una migración.

§ 05 — Modalidades de contratación

Un equipo, un proyecto o un especialista.

Elija la forma que encaja con el trabajo, no al revés. Cambiar de modalidad a mitad de proyecto es normal y no reinicia nada.

ModalidadIdeal paraEquipoCompromisoCadenciaDesde
Proyecto de alcance fijoUn lanzamiento definido con fecha firme4–8 personas3+ mesesHitos, precio fijo por fase€100k / fase
Equipo dedicadoLlevar una línea de producto de punta a punta5–12 personas6+ mesesMensual, preaviso de 30 días€9.5k / ingeniero / mes
Refuerzo de equipoHuecos concretos en sus propios squads1–5 personas3+ mesesPor horas, partes semanales€58 / hora

Incluido en todas las modalidades

  • Las tarifas son por ingeniero a 160 horas facturables al mes
  • Delivery lead y QA, sin facturación aparte
  • Revisión de seguridad antes de cada release
  • NDA y acuerdo de tratamiento de datos conforme al GDPR
  • Transferencia completa de la PI al pagar
  • Estado por escrito cada semana, comité de dirección cada mes

§ 06 — El stack del que respondemos

Herramientas convencionales, bien usadas.

La herramienta sigue al problema: lo que la carga, el plazo y sus sistemas existentes exigen de verdad. Cualquier cosa inusual viene con una razón escrita y un plan de salida.

Backend

GoJavaKotlinC#.NETC / C++PythonNode.jsRustSpring BootASP.NET CoregRPCProtobuf 3GraphQL

Web y frontend

TypeScriptVue.jsNuxtNext.jsReactNode.jsViteWebSocketSSR

Datos y mensajería

PostgreSQLMongoDBClickHouseElasticsearchRedisKafkaNATSNATS JetStreamRabbitMQDebeziumAirflow

Infraestructura

KubernetesHelmDockerTerraformArgoCDGitHub ActionsAWSGCPBare metalPrometheusGrafanaOpenTelemetry

Móvil y escritorio

iOSiPadOSwatchOSmacOSWindows 10/11AndroidLinuxSwiftSwiftUIKotlinComposeKMPC#.NETWinUIQtFlutter

Carga y calidad

k6GatlingJMeterTestcontainersPlaywrightpprofSimulacros de fallo

AI y ML

PyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflowClaude / OpenAI APIs

§ 07 — En abierto

Lo que publicamos.

Bibliotecas que extrajimos de trabajos para clientes y notas que escribimos mientras resolvíamos algo. Todo lo que publicamos vive en un solo sitio:

github.com/altessa-s

§ 08 — Cómo decidimos

Las decisiones de arquitectura se escriben.

No un documento que nadie lee: un registro breve por decisión, en su repositorio, revisado como código. Un año después, la pregunta "por qué está construido así" tiene respuesta.

  1. 01

    La bifurcación se escribe antes de tomarla

    Opciones, lo que cuesta cada una y a qué renunciaríamos. Dos párrafos, no una presentación.

  2. 02

    Se revisa como código

    El registro pasa por un pull request. Su arquitecto puede discutirlo antes de construir nada, no después.

  3. 03

    Se registra la razón, no solo la elección

    Restricciones, supuestos de carga y la fecha. La mayoría de las malas reescrituras empiezan porque nadie recuerda la restricción.

  4. 04

    Dice cuándo revisarla

    Cada registro lleva la condición que lo invalidaría — un umbral de carga, un techo de coste, un cambio de proveedor.

§ 09 — Donde decimos que no

El trabajo que rechazamos.

  • No presupuestamos sin acceso al código

    Una estimación a partir de una presentación es una conjetura, y siempre la paga uno de los dos.

  • No vendemos juniors como séniores

    Si no podemos cubrir un proyecto con ingenieros sénior, lo decimos y lo dejamos pasar.

  • No reescribimos por reescribir

    Dos veces hemos recomendado dejar un sistema como está y marcharnos. Fue más barato para todos.

  • No hacemos webs ni landing pages

    Ni sitios de marketing, ni apps desechables hechas contra una fecha y abandonadas. Si no es un sistema que alguien tenga que mantener en marcha, no somos el equipo adecuado.

  • No le tenemos como rehén

    Su nube, sus repositorios, 30 días de preaviso y runbooks a la salida.

§ 10 — Preguntas que nos hacen pronto

Haga primero las incómodas.

Si su pregunta no está aquí, escríbala en el formulario de abajo. Responde un ingeniero, por escrito.

La semana de diagnóstico empieza en los diez días hábiles siguientes a la firma del statement of work, y el equipo queda formado al final de esa semana con nuestra propia plantilla. Si no podemos cubrirlo con ingenieros sénior, lo decimos y declinamos el proyecto.

Cuéntenos qué se rompe bajo carga.Le diremos qué haríamos al respecto.

§ 11 — Contacto

Escríbanos.

Describa el sistema y qué está fallando en él. Un ingeniero lo lee y responde en tres días hábiles.

Qué pasa después

Días 1–3
Un ingeniero lee su nota y responde por escrito con una primera lectura: qué creemos que ocurre y qué miraríamos primero.
Si es útil
Una llamada corta con ese mismo ingeniero, en el horario que usted elija. Solo si la respuesta escrita deja algo abierto.
Si encaja
Definimos la semana de diagnóstico: una semana leyendo su código, €12k fijos, arquitectura y precio al final.
Modalidad de contratación

NDA a petición. Sus datos se quedan en la UE. Respondemos nosotros mismos, sin secuencias automáticas.

Este sitio está protegido por reCAPTCHA; se aplican la Política de privacidad y los Términos del servicio de Google.

¿Prefiere responder a unas preguntas en lugar de escribir una nota?Rellenar el brief