Héctor Jiménez Ruiz

LiderazgoTecnológico TechnologyLeadership

Más de 20 años construyendo software. Los últimos, liderando la tecnología de producto: el equipo, la arquitectura, la seguridad y una hoja de ruta que se pueda cumplir. Over 20 years building software. Lately, leading product technology: the team, the architecture, security, and a roadmap that can actually be delivered.

20+años en softwareyears in software
12años dirigiendo mi propia empresayears running my own company
10+años formando a desarrolladoresyears teaching developers
DEVELOPER+LOVE

Después de más de 20 años sigo disfrutando de construir software. Ahora mi forma de hacerlo es ayudar a que lo construyan equipos enteros. After more than 20 years I still love building software. These days, I do it by helping whole teams build it.

Sobre míAbout

Tecnología
que funciona como negocio
Technology
that works as a business

Actualmente lidero la tecnología de una plataforma SaaS B2B. Me encargo de dirigir el equipo de desarrollo y datos, decidir la arquitectura, asegurar la plataforma y traducir los objetivos de negocio en una hoja de ruta realista.

Antes fundé y dirigí mi propia empresa durante 12 años. Esa etapa me enseñó a tratar con clientes, preparar propuestas, llevar la gestión económica de los proyectos y adaptar arquitecturas y metodologías a necesidades muy distintas. La consultoría me permitió conocer y analizar negocios de entornos muy variados.

Pocas prioridades, bien elegidas, y equipos que funcionan.

I currently lead technology for a B2B SaaS platform. I run the development and data team, make the architecture decisions, secure the platform and turn business goals into a realistic roadmap.

Before that, I founded and ran my own company for 12 years. It taught me how to work with clients, write proposals, manage project finances and adapt architectures and methodologies to very different needs. Consulting gave me the chance to understand and analyse businesses across many sectors.

A few well-chosen priorities, and teams that work.

Áreas de experienciaAreas of expertise

En qué tengo experiencia What I know well

01

Equipos de ingenieríaEngineering teams

Selección, objetivos, Scrum y estándares de calidad compartidos: Definition of Done, revisión de código y métricas que se usan de verdad.Hiring, objectives, Scrum and shared quality standards: Definition of Done, code review and metrics that are actually used.

02

Arquitectura de softwareSoftware architecture

Evolución de sistemas legacy .NET hacia arquitecturas limpias sin parar la operación. Integraciones con ERP y RRHH, identidad y SSO (SAML2).Evolving legacy .NET systems into clean architectures without stopping operations. ERP and HR integrations, identity and SSO (SAML2).

03

Cloud y DevOpsCloud and DevOps

Azure y AWS. Pipelines CI/CD, entornos reproducibles desde cero con Infrastructure as Code (IaC: Terraform), despliegues seguros y acceso a servidores con SSO.Azure and AWS. CI/CD pipelines, environments reproducible from scratch with Infrastructure as Code (IaC: Terraform), safe deployments and SSO-based server access.

04

Seguridad y cumplimientoSecurity and compliance

Responsable del Sistema en un proyecto de certificación del Esquema Nacional de Seguridad (ENS) y desarrollo seguro.System Owner in a certification project for Spain’s National Security Framework (ENS), and secure development.

05

IA aplicada al desarrolloAI-assisted development

Adopción práctica de herramientas como Claude Code, Spec-Driven Development y agentes de revisión de código en el flujo de Pull Requests.Practical adoption of tools such as Claude Code, Spec-Driven Development and code review agents in the Pull Request flow.

06

Tecnología y negocioTechnology and business

Objetivos anuales, reporting a dirección, priorización con capacidad real y apoyo técnico en preventa y licitaciones.Annual objectives, reporting to senior management, prioritisation based on real capacity, and technical support in pre-sales and tenders.

TrayectoriaExperience

De desarrollador
a liderar la tecnología
From developer
to technology leader

  1. 2024 – hoynow

    Head of Engineering & Architecture

    Plataforma SaaS B2BB2B SaaS platform

    Dirección del equipo de desarrollo y datos, rearquitectura de la plataforma, DevOps en AWS, seguridad (ENS) e implantación de IA en el desarrollo.Leading the development and data team, platform re-architecture, DevOps on AWS, security (ENS) and rolling out AI in development.

  2. 2019 – 2024

    Principal Team Lead / Solutions Architect

    eo soluciones informáticas

    Gestión del área de desarrollo, apoyo a preventa y selección. Arquitecto cloud y Scrum Master en proyectos para NTT y JT International.Managed the development area, supported pre-sales and hiring. Cloud architect and Scrum Master on projects for NTT and JT International.

  3. 2007 – 2019

    Fundador y directorFounder and director

    WebExpression

    Empresa de desarrollo de software centrada en entregar producto, no en facturar horas. Proyectos con Microsoft, Everis, Global TMS o ING Direct, y docencia para empresas y escuelas.Software company focused on delivering product, not billing hours. Projects with Microsoft, Everis, Global TMS and ING Direct, plus teaching for companies and schools.

  4. 2011 – 2014

    Arquitecto .NET y jefe de equipo.NET Architect and Team Lead

    Aventia-Renacimiento · atsistemas

    Arquitectura orientada al dominio, dirección de equipos y Scrum Master. Arquitectura asíncrona en Azure para el Portal Educamos de Grupo SM.Domain-driven architecture, team leadership and Scrum Master. Asynchronous Azure architecture for Grupo SM’s Educamos Portal.

  5. 2005 – 2010

    Analista y technical leadAnalyst and Technical Lead

    Accenture · Repsol · Alba Technology

    Migración de servidores internacional, Guía Repsol y sistemas de control de acceso y cajeros para el Ministerio de Interior e ING Direct.International server migration, Guía Repsol, and access-control and ATM systems for the Spanish Ministry of the Interior and ING Direct.

CasosCase studies

Proyectos que me definen Projects that define me

FIVB · Microsoft · Global TMS

Plataforma digital para la Federación Internacional de VoleibolDigital platform for the International Volleyball Federation

Scrum Master y gestión del equipo en la implantación y extensión de Microsoft Sports Digital Platform, una plataforma cloud de Microsoft, para la FIVB.Scrum Master and team management for the rollout and extension of Microsoft Sports Digital Platform, a Microsoft cloud platform, for the FIVB.

AzureScrumGestión de equipoTeam management
Everis · cloqq.com

Arquitectura multi-instancia en AzureMulti-instance architecture on Azure

Diseño y desarrollo de la plataforma para dar soporte y escalabilidad a la iniciativa: Azure Active Directory, App Service con escalado automático, Azure SQL y CI/CD.Designed and built the platform to support and scale the initiative: Azure Active Directory, App Service with autoscaling, Azure SQL and CI/CD.

Azure.NETEscalabilidadScalability
NTT Disruption

Un producto disruptivo, desde ceroA disruptive product, from scratch

Arquitecto cloud y Scrum Master: toma de requisitos y backlog, arquitectura hexagonal en .NET Core, infraestructura con Terraform y pipelines de CI/CD en Azure DevOps.Cloud architect and Scrum Master: requirements and backlog, hexagonal architecture in .NET Core, infrastructure with Terraform and CI/CD pipelines in Azure DevOps.

.NET CoreTerraformAzure DevOps

ArtículosArticles

Lo que he aprendido
por el camino
What I have learned
along the way

Formación y docenciaEducation and teaching

Aprender y enseñar Learning and teaching

FormaciónEducation

  • Licenciado en FilosofíaBachelor’s Degree in PhilosophyUniversidad Complutense de Madrid
  • Graduado superior en informática aplicadaHigher Diploma in Applied ComputingInstituto Cibernos

CertificacionesCertifications

  • AI-900: Azure AI FundamentalsMicrosoft · 2024
  • AZ-900: Azure FundamentalsMicrosoft · 2023
  • MCSD: Web ApplicationsMicrosoft · 2013
  • Gestión visual de proyectos (Kanban)Visual Project Management (Kanban)Scrum Manager · 2012

DocenciaTeaching

  • Máster en desarrollo .NETMaster’s in .NET DevelopmentCICE · 3 añosCICE · 3 years
  • Cursos de .NET, ASP.NET MVC, WPF, HTML5, TDD y TFS.NET, ASP.NET MVC, WPF, HTML5, TDD and TFS coursesAirbus · RICOH · Metro de Madrid · Comunidad de Madrid

¿Hablamos?Let’s talk

Si quieres comentar algo sobre arquitectura, liderazgo de equipos o IA aplicada al desarrollo, escríbeme.If you would like to talk about architecture, engineering leadership or AI-assisted development, get in touch.

IA aplicada al desarrolloAI-assisted development

La IA no acelera a un equipo desordenado

Las herramientas de IA para programar, como Claude Code o Copilot, multiplican lo que ya existe en un equipo. Si hay criterio, especificaciones claras y una forma compartida de revisar el código, el equipo va más rápido. Si no lo hay, también va más rápido, pero hacia más deuda técnica.

Por eso, cuando he introducido IA en un equipo, no he empezado por las licencias, sino por tres cosas:

  • Especificar antes de generar. Con un enfoque de Spec-Driven Development, la IA trabaja a partir de una especificación revisada por personas, no de una idea suelta en un chat. La especificación es el contrato. El código es una consecuencia.
  • Definir qué es una buena revisión. Antes de poner un agente a revisar Pull Requests, el equipo acordó por escrito qué se revisa y qué bloquea una fusión. El agente hace la primera pasada y las personas deciden.
  • Medir algo sencillo. Tiempo hasta la primera revisión y porcentaje de PR con comentarios. Sin una línea base, cualquier mejora es una opinión.

La herramienta cuesta poco. El trabajo de verdad es el orden previo, y ese orden es lo que hace que la IA sume en lugar de restar.

AI won’t speed up a disorganised team

AI coding tools such as Claude Code or Copilot multiply whatever a team already has. With judgement, clear specifications and a shared way of reviewing code, the team moves faster. Without them, it also moves faster, but towards more technical debt.

That is why, when I introduced AI into a team, I didn’t start with licences but with three things:

  • Specify before generating. With a Spec-Driven Development approach, the AI works from a specification reviewed by people, not from a loose idea in a chat. The spec is the contract; the code follows from it.
  • Define what a good review is. Before letting an agent review Pull Requests, the team agreed in writing what gets reviewed and what blocks a merge. The agent does the first pass; people decide.
  • Measure something simple. Time to first review and percentage of PRs with comments. Without a baseline, any improvement is just an opinion.

The tool is cheap. The real work is the groundwork, and that groundwork is what makes AI add value instead of taking it away.

ArquitecturaArchitecture

Migrar un legacy .NET sin parar la operación

Casi todos los productos con años de vida tienen una parte en .NET Framework, con poca inyección de dependencias y casi sin tests, que nadie quiere tocar. La tentación es reescribirla de golpe. Casi nunca sale bien: el negocio no se detiene mientras tanto y la versión nueva siempre llega tarde.

Lo que me ha funcionado es más aburrido y más seguro:

  • Convivencia, no sustitución. Una API nueva en .NET moderno, con arquitectura limpia, crece junto a la antigua. Cada funcionalidad se mueve cuando hay un motivo de negocio para tocarla.
  • Reglas distintas para cada lado. En lo nuevo, cobertura de tests exigente. En lo antiguo, una sola regla: no introducir regresiones.
  • Capacidad protegida. Si la migración compite cada sprint con bugs y urgencias, pierde siempre. Hay que acordar con producto y dirección qué parte de la capacidad se reserva, y defenderla.
  • Hacerlo visible. Qué porcentaje del tráfico o de las funcionalidades vive ya en la parte nueva. Es lo que permite justificar la inversión.

Una migración así no es un proyecto con fecha de fin, sino una forma de trabajar. Y es la única que he visto terminar.

Migrating legacy .NET without stopping operations

Almost every product with a few years behind it has a .NET Framework part, with little dependency injection and hardly any tests, that nobody wants to touch. The temptation is to rewrite it in one go. It rarely works: the business doesn’t stop in the meantime, and the new version always arrives late.

What has worked for me is more boring and much safer:

  • Coexistence, not replacement. A new API in modern .NET, with a clean architecture, grows alongside the old one. Each feature moves when there is a business reason to touch it.
  • Different rules on each side. Demanding test coverage in the new code; a single rule in the old code: no regressions.
  • Protected capacity. If the migration competes with bugs and urgent requests every sprint, it always loses. Agree with product and management how much capacity is reserved, and defend it.
  • Make it visible. Track what share of traffic or features already runs on the new side. That is what justifies the investment.

A migration like this isn’t a project with an end date; it’s a way of working. And it’s the only kind I have seen finish.

SeguridadSecurity

Seguridad en un SaaS: el auditor no mira el papel

Preparar un SaaS para una certificación como el Esquema Nacional de Seguridad (ENS) genera mucha documentación: políticas, análisis de riesgos, procedimientos… Es necesaria, pero lo que de verdad se evalúa es si lo que dicen los documentos coincide con lo que se hace.

Algunas lecciones desde el lado técnico:

  • Cada procedimiento escrito tiene que ser real. Si el documento dice que los accesos se revisan cada trimestre o que los backups se prueban, tiene que haber evidencia de que se hace. Lo que está escrito y no se hace es lo primero que aparece en una auditoría.
  • Los quick wins suelen estar en los accesos. Pasar del acceso remoto filtrado por IP a un acceso con SSO y sesiones registradas mejora la seguridad y, de paso, genera la trazabilidad que pide la norma.
  • Separar roles de verdad. Quien decide las medidas y supervisa no debería ser quien las implanta y opera. No es burocracia: es lo que evita que alguien se audite a sí mismo.
  • Que las evidencias salgan solas. Los registros de despliegue de la pipeline, los logs de acceso y los tickets ya son evidencias. Si el proceso las genera de forma automática, nadie tiene que recopilarlas antes de la auditoría.

La certificación es un hito, no el final. Lo valioso es convertir la seguridad en parte del trabajo diario del equipo.

SaaS security: auditors don’t look at the paperwork

Preparing a SaaS product for a certification such as Spain’s National Security Framework (ENS) produces a lot of documentation: policies, risk analysis, procedures… It is necessary, but what really gets assessed is whether the documents match what actually happens.

A few lessons from the technical side:

  • Every written procedure must be real. If the document says access is reviewed every quarter or backups are tested, there must be evidence that it happens. What is written but not done is the first thing an audit finds.
  • Quick wins are usually in access control. Moving from IP-filtered remote access to SSO-based access with recorded sessions improves security and, along the way, provides the traceability the framework requires.
  • Separate roles for real. Whoever decides and supervises the controls shouldn’t be the one who implements and operates them. It isn’t bureaucracy; it’s what stops anyone from auditing themselves.
  • Let evidence generate itself. Pipeline deployment records, access logs and tickets already are evidence. If the process produces them automatically, nobody has to gather them before the audit.

Certification is a milestone, not the finish line. What matters is making security part of the team’s everyday work.

Aviso legal y privacidad

Titular

Este sitio web es la página personal de Héctor Jiménez Ruiz (Madrid, España). Contacto: hjimenez19@gmail.com.

Finalidad

Es un sitio de carácter personal e informativo: presenta mi trayectoria profesional y algunos artículos de opinión. No se venden productos ni se contratan servicios a través de este sitio.

Propiedad intelectual

Los textos, imágenes y la marca DEVELOVER son propiedad de su titular. No pueden reproducirse sin autorización, salvo citas breves indicando la fuente.

Privacidad

Este sitio no tiene formularios ni crea cuentas de usuario. Si me escribes por correo electrónico, usaré tus datos únicamente para responderte y no los cederé a terceros. Puedes pedirme en cualquier momento el acceso, la rectificación o la supresión de tus datos escribiendo a la dirección anterior. También puedes reclamar ante la Agencia Española de Protección de Datos (aepd.es).

Cookies

Este sitio no usa cookies de análisis ni de publicidad. Solo guarda en tu navegador el idioma que eliges (español o inglés), un dato técnico que no sale de tu dispositivo. Las tipografías se cargan desde Google Fonts, por lo que tu navegador se conecta a servidores de Google al visitar la página.

Última actualización: octubre de 2026.

Legal notice and privacy

Owner

This website is the personal page of Héctor Jiménez Ruiz (Madrid, Spain). Contact: hjimenez19@gmail.com.

Purpose

This is a personal, informational site: it presents my professional background and some opinion articles. No products are sold and no services are contracted through this site.

Intellectual property

The texts, images and the DEVELOVER brand belong to their owner. They may not be reproduced without permission, except for short quotes that credit the source.

Privacy

This site has no forms and no user accounts. If you email me, I will use your data only to reply and will not share it with third parties. You can ask me at any time to access, correct or delete your data by writing to the address above. You may also file a complaint with the Spanish Data Protection Agency (aepd.es).

Cookies

This site uses no analytics or advertising cookies. It only stores the language you choose (Spanish or English) in your browser, a technical setting that never leaves your device. Fonts are loaded from Google Fonts, so your browser connects to Google’s servers when you visit the page.

Last updated: October 2026.