Modernisation
Modernise your systems
Legacy systems slow down change.
I modernise incrementally to reduce risk.
Technical Leadership for Scalable Product Delivery (Es)
Technology Consultant
Engineering that creates business value.
I help companies build scalable digital products by bringing together software architecture, product strategy and engineering leadership.
Who I work with
- Startups
- Scale-ups
- SMEs
- Enterprise
Technology for growth
Your technology investment should grow your business.
The right architecture accelerates delivery, reduces operating costs and prepares your company for future growth. I design and deliver that transformation.
- 01
Business goals
I make sure your software investment supports company goals and measurable outcomes.
- Faster delivery
- Lower costs
- Measurable value
- 02
Right architecture
I design systems that solve today's needs without limiting tomorrow's growth.
- Less technical debt
- Ready for change
- Scalable systems
- 03
Reliable delivery
I help new features reach customers safely and predictably.
- Safer releases
- Faster development
- Operational continuity
- 04
Sustainable growth
I turn technology into long-term efficiency and competitive advantage.
- Controlled costs
- Resilient operations
- Ready to scale
Measured by impact numbers that reflect our growth and trust.
Help when you need it!
Where technology holds you back
Turn your technology investment into a competitive advantage.
Are your systems limiting growth?
Legacy systems and technical debt become an adaptable, sustainable architecture.
Explore the approach →Is delivery slowing down?
Your teams gain the practices needed to deliver faster, predictably and reliably.
Explore the approach →Is technology investment falling short?
Technical decisions align with growth, cost and operational goals, turning investment into measurable business outcomes.
Explore the approach →11+ years · Cloud · AI · Marketplaces · Distributed systems
The right fit
I work with you when the problem is the right one.
The best projects happen when technical goals and business goals move in the same direction. That is why I choose every engagement with care.
Where I create the most value
- SaaS companies preparing to scale their product
- Marketplace and e-commerce platforms
- Teams modernising legacy systems
- Companies integrating AI into business processes
- Engineering teams building cloud and distributed systems
It may not be the right fit
- Companies that make price the only decision criterion
- Teams that put short-term fixes ahead of long-term architecture
- Organisations that continually postpone technical debt
- Teams that change priorities without establishing delivery discipline
- Companies seeking code delivery without product ownership
Working principles
Stop technology from slowing your company down.
Every technical decision should produce faster delivery, lower risk and sustainable growth.
- ↗New features reach customers sooner.
Reach production faster
Small changes should not create major release risk.
- ↗Technical risk no longer blocks growth.
Bring technical debt under control
Complexity becomes visible and priorities follow business impact.
- ↗Delivery accelerates and dependencies decrease.
Help teams move independently
Clear system boundaries reduce how often teams wait on one another.
- ↗Safer releases and more resilient operations.
Make delivery predictable
Automation, measurement and observability reduce operational risk.
Work built together
I turn distinct business models into reliable, scalable digital products.
Each engagement is a case study in bringing business context, technical decisions, and delivery discipline into one system.
Kayra Export: plataforma de mercado y comercio electrónico (CTO)
ABC Logistics: Plataforma de seguimiento GIS en tiempo real
Cripto desnudo: DApp de minería de NFT Marketplace
Rapid Render: configurador de productos 3D en tiempo real
Dunelm: experiencia de "ver en la habitación" de AR con soporte LiDAR
Mulcol: Simulación de ensamblaje de cortafuegos en realidad virtualMulcol: Catálogo de ensamblajes AR (basado en marcadores)Featured engagement
Kayra Export: plataforma de mercado y comercio electrónico (CTO)
Como CTO, gestioné el comercio electrónico y la transformación del mercado; Construí una arquitectura de microservicio .NET + CQRS y la escalé en AWS. Producticé la infraestructura de comercio multicanal con módulos de pago/integración y soportados por inteligencia artificial.
See what I delivered in this case studyPerspectives
Technology, growth and better decisions.
¿Qué buscan realmente las empresas de tecnología financiera?
Perspectiva profesional: empresas de tecnología financiera, no el SDK de Stripe; Busca el pensamiento del fracaso, la reconciliación, la idempotencia y el…
Lista de la serie
Motor de pago distribuido
Parte 22 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Diseño de un motor de pago de producción
Síntesis de la serie de 22 partes: lista de verificación arquitectónica para motor de pagos de producción con orquestador de pago y puerta de enlace de…
Lista de la serie
Motor de pago distribuido
Parte 21 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Procesamiento de pagos efectivo una sola vez
Enviar mensajes exactamente una vez es una mentira. ¿Cómo lograr resultados comerciales efectivos cuando se combina la defensa en profundidad con…
Lista de la serie
Motor de pago distribuido
Parte 20 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Runbook y proceso de recuperación de pagos
Antes de la automatización: trabajador de reconciliación y canal de recuperación. Los runbooks humanos basados en evidencia entran en juego cuando los…
Lista de la serie
Motor de pago distribuido
Parte 19 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Observabilidad y correlación de pagos
¿Cómo correlacionar cada registro, métrica y seguimiento con la identificación de pago? ¿Cómo el registro de eventos paso a paso y las métricas de…
Lista de la serie
Motor de pago distribuido
Parte 18 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Simultaneidad optimista bajo Webhook
¿Cómo resuelven el token de versión y el arrendamiento la carrera cuando la respuesta sincrónica con webhook toca el mismo pago al mismo tiempo? Secreto de…
Lista de la serie
Motor de pago distribuido
Parte 17 / 22
- Parte 1 ¿Por qué los sistemas de pago son sistemas distribuidos?
- Parte 2 Diseño de la máquina de estado de pago: ¿Por qué el pago y el pago no son lo mismo?
- Parte 3 ¿Por qué la recopilación (captura) es fácil pero la finalización es difícil?
- Parte 4 Diseño de instantáneas de pago inmutable: la decisión que congela el carrito
- Parte 5 Idempotencia (transacción segura repetible) más allá de la solicitud de API (interfaz de programación de aplicaciones)
- Parte 6 Fiabilidad del webhook en sistemas de pago
- Parte 7 Patrón de bandeja de salida/bandeja de entrada en sistemas de pago
- Parte 8 Comprobante de pago y estado de pago: por qué no debe confundirse
- Parte 9 Abstracción de proveedores sin fugas SDK (kit de desarrollo de software): el límite de la puerta de enlace
- Parte 10 Evento semántico en lugar de datos sin procesar del proveedor
- Parte 11 Taxonomía de errores de pago
- Parte 12 Algoritmos de reintento para trabajadores de pagos
- Parte 13 Trabajos compatibles con bases de datos con arrendamiento
- Parte 14 Trabajador de conciliación de pagos de construcción
- Parte 15 Pagado pero sin pedido: mejora
- Parte 16 Por qué la coherencia eventual es superior a las transacciones distribuidas
- Parte 17 Simultaneidad optimista bajo Webhook
- Parte 18 Observabilidad y correlación de pagos
- Parte 19 Runbook y proceso de recuperación de pagos
- Parte 20 Procesamiento de pagos efectivo una sola vez
- Parte 21 Diseño de un motor de pago de producción
- Parte 22 ¿Qué buscan realmente las empresas de tecnología financiera?
Before you decide
What you should know before deciding.
Do you need to rewrite the entire system?
Usually not. I first identify the areas creating the greatest business risk and cost, then modernise the system incrementally and with controlled risk.
How soon will you see the first result?
Timing depends on the scope of the problem. I divide the work into small, measurable steps and clarify both quick wins and the long-term roadmap first.
Will you need to replace your team or change how it works?
Usually not. The goal is not to replace the team, but to preserve its knowledge while strengthening decision-making, development and delivery.
How do you measure whether the investment creates value?
I clarify success measures with you at the start, using indicators relevant to the problem such as delivery time, defect rate, operating cost and team wait time.
What happens in the first technical conversation?
I discuss your current system, team and business goals, clarify the priority risks and recommend the most useful next step for you.