Who you would be funding
I design the part of the system that has to be right.
I'm Alejandro Pozo — a senior backend architect for complex business software. ERP cores, payroll closures, accounting moves: the engines where a wrong answer is not a bug, it is a liability.
The work
Not features. Foundations.
Anyone can add a screen. I build the layer underneath it — the domain model, the boundaries, the kernel — so the tenth feature costs less than the first and the system is still editable years after it ships. That is the line between software that compounds and software that decays.
How I work
Every engagement runs the same disciplined path.
Select each phase. None of it is improvised — the sequence holds whether the stack is Java or TypeScript.
Start with the language
Bounded contexts emerge from how the operations team actually thinks about the work — not from a database schema. Shared vocabulary before a line of code.
Draw the boundaries
Explicit seams between contexts. Each one owns its model; integration is deliberate. This is where most systems are quietly won or lost.
Build the kernel
Buses, ports, value objects, saga, outbox, idempotence — a hand-built foundation. Pay the upfront tax once; every context after it costs less.
Coexist, never rewrite blindly
New contexts ship into clean layers while legacy keeps running. Anti-corruption layers bridge the two. A god-service retires only when its replacement has earned it under real load.
The compounding asset
Each bounded context costs less than the last.
The kernel is built once. After that, every new context reuses it — so the marginal cost of growth falls instead of rising. Add contexts and watch the two cost curves separate.
Most systems get more expensive to extend every year. A kernel makes them get cheaper. That gap is what you are funding.
Principles
Four rules I do not bend.
- 01
Build the kernel first
Every reusable pattern lives in a hand-built foundation. Each new context costs less because the foundation already paid the upfront tax.
- 02
Patterns over frameworks
The architecture travels. Hexagonal, DDD and CQRS work the same in Java/Spring as in TypeScript/NestJS. The framework is only a delivery vehicle.
- 03
Coexistence over rewrites
Legacy keeps shipping while new contexts prove themselves. Anti-corruption layers bridge the two. Nothing is retired on faith.
- 04
Documentation pairs with code
Every non-obvious decision has a markdown beside it — bounded contexts, refactor narratives, runbooks. The system explains itself.
Two stacks, one architecture
The framework is the vehicle. The discipline is the asset.
I work in two parallel stacks. The patterns are identical in both. Switch the stack below — only the adapters change; the domain at the core never moves.
This is why funding judgment beats funding a framework specialist. Judgment travels between stacks; framework knowledge expires with them.
Background
Where the discipline comes from.
Software Engineer, graduated from Universidad de Oriente in Santiago de Cuba. Recent engagements: an ERP backend with a fifteen-context architecture and a hand-built kernel of CQRS, saga and outbox primitives; and a full-stack HR and payroll platform with a parallel kernel in TypeScript. The same patterns, proven twice, in two languages.
Stack
- Languages
- TypeScript · Java · SQL
- Backend
- Spring Boot · NestJS
- Frontend
- React · Vite
- Persistence
- PostgreSQL · Spring Data JPA
- Patterns
- DDD · Hexagonal · CQRS · Saga · Outbox · Idempotence
- Operations
- Docker · OpenAPI / Swagger
Working together
If correctness is non-negotiable, we should talk.
I selectively take on engagements where the architecture is the thing that matters. Email is the fastest path — I read every message myself.