/ A. Pozo

Available · Selectively taking on engagements for 2026

Senior Full-Stack Developer for Complex Business Systems

I design domain-driven backends — Hexagonal, DDD, CQRS — for ERP, accounting, payroll and operational workflows. Same kernel discipline across Java/Spring and TypeScript/NestJS.

  • ERP
  • Accounting Systems
  • Backend Architecture
  • DDD
  • Hexagonal Architecture
  • Clean Architecture
  • TDD
Focus
ERP · Accounting · Operations
Stack
TypeScript · Node · Postgres
Approach
DDD · Hex · TDD
Based in
Havana, Cuba

What I do

Backend foundations for systems where correctness is non-negotiable.

Selected work

Case studies

All work →

Approach

A disciplined approach to building software that an organisation can rely on for years.

  1. 01

    Domain at the core

    Pure domain logic — no frameworks, no infrastructure. The accounting rules, the inventory invariants, the order workflow live untouched by transport or persistence concerns.

  2. 02

    Ports & adapters

    Inbound use cases drive the domain through explicit ports; outbound integrations (DB, queues, third parties) implement adapters. Swappable, testable, observable.

  3. 03

    Tests as design pressure

    TDD as a feedback tool: red, green, refactor. Unit tests for the domain, integration tests at the boundaries, contract tests for external systems — pyramid stays in shape.

  4. 04

    Documented decisions

    ADRs for trade-offs, ubiquitous language for shared meaning, runbooks for the things that page someone at 3am. The system explains itself.

Domain Application Infrastructure HTTP · CLI · Jobs DB · Queue · APIs

Hexagonal Architecture · Information Flow

On the horizon

Natural language as a first-class interface to enterprise systems.

An AI assistant module currently in production-readiness on top of the ERP backend. Natural-language requests are classified into intents and routed deterministically to a registry of read-only Tools that wrap existing application services. Authorization stays inside the access context — no parallel permission model. The next phase brings command-side tools with HITL confirmation and conversational state for end-to-end operational sales management.

intent classifier · router Sale . getSaleById Sale . searchSales Sale . getTopSellingProducts Sale . createDraft Sale . removeDraft Inventory . getStockAvailability Catalog . getProductDefinition Catalog . searchProducts 9 tools · 12 intents · 3 LLM providers
  1. 01

    Deterministic tool routing

    Intents are resolved by a keyword classifier, not by the LLM. The LLM composes the response, never decides what to call. Failure modes degrade to a deterministic fallback.

  2. 02

    Swappable LLM providers

    A single provider port — three implementations: mock for tests, Ollama for local privacy-first inference, OpenAI-compatible for managed deployment. Switch by config; the domain never knows.

  3. 03

    Authorization stays where it lives

    Every tool call goes through the existing AuthorizeActionHandler. Tenant, business unit and permissions remain owned by the access context. The assistant never reaches around them.

Tools registered
9
Intents classified
12
LLM providers
3
Confirmation flow
HITL

Currently

Designing the next generation of business systems takes careful hands.

If you're rebuilding a critical part of your operation — accounting, ERP, financial workflows — and need a senior pair of hands on the architecture, I'd like to hear about it.