Open to senior roles · Remote or hybrid

Lucas Matías Frías

Senior Software Engineer

Architecture, security and distributed systems · Agent-assisted engineering

Eight years building software. Lately, event-driven distributed systems: microservices that talk over queues, signed integrations between platforms, and the infrastructure that keeps them running in production.

I work from judgement, not from tooling. The questions that shape my designs are always the same ones: what guarantees this is correct, what happens when it fails, and who is allowed to reach what.

For over a year now I have been building with coding agents. The work moved from writing code to defining the acceptance criteria and the constraints the result has to clear.

Download CV as PDF Contact

Buenos Aires, Argentina · Remote lucasmatiasfrias@live.com linkedin.com/in/lucasmatiasfrias

8yearsbuilding software, since 2018

7yearsteaching programming at university level

+1yearbuilding with coding agents

How I work

What I bring to a team is not a language. It is judgement about these five things.

Architecture and design

I split systems for operational reasons, not for fashion. Every boundary has to be justifiable by something that actually happens in production.

See the 6 points Hide

Extend the tool the business already runs on rather than standing up a parallel system. Almost everything I have built in recent years is exactly that: a module, a channel or a service that plugs into an existing platform through its public contracts, without asking the team to switch tools.
Services with independent build contexts, when there is a concrete availability reason: redeploying the UI must not restart the event ingester, which has to keep receiving.
Event-driven over a message broker: queue, audit log, dead-letter queue, and domain routing kept separate from ingestion.
Ports and adapters where it matters. In the payments prototype, swapping the mocked gateway for the real one touches a single file — neither the domain nor the UI notices.
Contract first: the envelope, the enums and the result codes defined before the code that uses them.
Control plane separated from data plane, cache-aside, BFF and facade — applied where they solve something, not as a catalogue.

Security

Not a layer bolted on at the end, but the property that decides the shape of the system.

See the 7 points Hide

Cryptography verified on both ends: 2048-bit RSA-SHA256 signatures with canonical serialisation over a payment envelope. Flip a single byte of the signature and the operation fails with the contract's own error code.
Ed25519 signature verification on inbound webhooks, before the event ever reaches the queue.
Isolation of untrusted execution: an ephemeral container per turn, non-root user, memory, CPU and process limits, and only the workspace mounted.
Separate authentication surfaces: a service-to-service secret compared in constant time, and short-lived user credentials minted by the control plane.
Per-module authorisation over an explicit permission catalogue, with roles seeded idempotently.
Defence in depth at the edge: a single container with host ports, backends with no public exposure, and internal routes rejected at the proxy.
Attack-surface audit of a server: ports listening on all interfaces, authentication logs and authorised keys, with a hardening plan — key-only access, firewall, and secrets moved out of the code.

Reliability and operations

Design for the day something breaks, because it will. What matters is whether you can see it, trace it and replay it.

See the 6 points Hide

Idempotency and retries with backoff on every integration that crosses a network boundary.
Dead-letter queues and an audit log: a failed event can be found, understood and reprocessed.
Container healthchecks, structured logs, metrics and active monitoring.
Scheduled jobs go to a workflow engine, not to a cron hanging off the server. Every run is recorded with its input, its output and its error, and can be retried without opening an SSH session. A cron that fails at three in the morning leaves nothing behind to explain why.
Containerised deployment behind a TLS reverse proxy. Internal services do not reach the internet.
Time zones treated as a design decision rather than a default: a system that reasons in the merchant's local time closes the day when the merchant closes.

Methodology and team

Code is half the job. The other half is that someone else can understand it, extend it and trust it.

See the 4 points Hide

Tests as executable specification, written to define behaviour rather than as paperwork afterwards.
Architecture documentation as the repository's contract: a written golden path so every new module is built like the ones before it.
Seven years teaching Algorithms and Programming at university level. Explaining a system to someone who does not know it is half of a senior engineer's job.
Predictable delivery with distributed teams across time zones: decisions written down where they can be found later, and progress that does not depend on someone being online at the same hour I am.

Engineering with agents

I have not hand-written code in over a year. I specify, constrain and verify.

See the section

Engineering with agents

I have not hand-written code in over a year. I specify, constrain and verify.

I replaced line-by-line diff reading with verifiable constraints. The work moved from writing code to defining the acceptance criteria, and that has two disciplines with names of their own.

Test-Driven Development, which has been around forever: the test is written first and defines the behaviour, so it acts as acceptance criteria rather than after-the-fact verification. And Spec-Driven Development, which came out of exactly this: the versioned specification is the source of truth and the code is what gets generated against it. This site works that way — the content lives in one file, and the page and the PDF are output.

The gauntlet whatever an agent produces has to run: automated tests as acceptance criteria, static security analysis, mutation testing — mutate the code and check the tests actually fail — and complexity and dependency limits. If any of that does not pass, it does not ship.

Reviewing stopped being reading. It is designing that gauntlet before the result exists. That is not a tool you pick up — it is an architectural decision.

“My current strategy is to not read any of the code written by my agents. […] What I do instead is to surround the agents with extreme constraints.”

Robert C. Martin — @unclebobmartin · X · 23 July 2026

The gauntlet, implemented

In the agent-builder module of the apps platform, the security boundary is not the agent's tool restrictions: it is a server-side publish gate — a pristine security lint plus the test suite — that the code has to clear before it can be deployed. The decision is reasoned and written down in the code, not left implicit in configuration.

A capability layer of my own

Around fifty versioned procedures over the APIs I use daily, typed and narrowly scoped, instead of relying on generic functionality. The number is not the point: the governance is. Per-domain credentials with least privilege, in-house standards imposed on the agent, and a real lifecycle — anything replaced is marked deprecated with a pointer to its successor rather than deleted.

A reconstructed contract

A payment gateway publishes its integration manuals as scanned PDFs with no extractable text. The filename gave away the real provider, which does document in text. From there: contract reconstructed, cryptographic signature verified on both ends, and tests that exercise it. All of it — protocol, cryptography, app, mocked backend and deployment — in less than an afternoon. The agents supply the speed; what had to be built and what it had to withstand, they do not.

under 4 hours

Portfolio

Five systems. Almost everything I know how to do is in the first two.

Otimify · 2026

An apps platform on top of a SaaS ecosystem

Extending a third-party CRM with in-house modules that carry their own permissions, without being able to touch its code.

Lifecycle of an event · on failure → dead-letter queue

Read the detail Hide the detail

The problem

A SaaS CRM the business already runs on, which has to be extended with in-house functionality. Its code cannot be modified, integration has to go through its public contracts, and CRM event ingestion cannot go down every time a new feature ships.

Decisions

Five services with independent build contexts. Redeploying the UI neither rebuilds nor restarts the webhook ingester, which has to keep receiving CRM events without interruption. That is the reason for the split, and it is documented as such.
A full event pipeline: ingestion with verified Ed25519 signatures, queue, audit log, a configurable forwarding engine to external destinations, domain routing and, when something fails, a dead-letter queue. The forwarding control plane is kept separate from the data plane.
A single container holds the host ports and terminates TLS, acting as the edge. Every other service only exposes ports on the internal network, and service-to-service routes are rejected at the edge even if someone knows them.
Single sign-on inside the CRM's iframe, with a token that is independent of the account — the account travels in a header — and per-module authorisation over an explicit permission catalogue, complementing the CRM's own user system.
A documented golden path: how a new module is added, which conventions are non-negotiable, and which components must be reused rather than reinvented.

My favourite module: the agent builder

It runs a coding agent in an ephemeral container per turn — non-root user, memory, CPU and process limits, and only the workspace mounted — so it can be prompted in natural language to build and deploy other agents already wired into the CRM ecosystem. Two separate authentication surfaces: a service-to-service secret compared in constant time, and short-lived user credentials minted by the control plane. The real security boundary is the publish gate, not the agent's tool restrictions.

Outcome

The platform carries independent modules, each with its own permissions, layered on the CRM's user structure. Shipping a new feature does not interrupt event ingestion.

Java 17
Spring Boot
PostgreSQL
RabbitMQ
React
Python
FastAPI
n8n
Docker
Caddy

Decisions and patterns are described here. Details of the client's operation are deliberately left out.

Personal project · 2026

A portal against a real payment gateway

A prototype that speaks a payment gateway's real protocol, reconstructed from scanned documentation.

Path of a signed operation · one altered byte → the operation fails

handy-poc.fluxing.app

Read the detail Hide the detail

The problem

The gateway publishes its integration manuals as scanned PDFs with no extractable text. Building a credible prototype meant reconstructing the contract first, rather than inventing models that merely looked the part.

Decisions

The manual's filename gave away the gateway's real provider, which does publish documentation in text. With that, the prototype stopped using invented models and started speaking the real protocol: signed envelope, canonical serialisation, result codes, transaction states and the financial-inclusion legislation that applies.
2048-bit RSA-SHA256 signing and verification on both ends. Flipping a single byte of the signature returns the error code the contract defines: the cryptography is real even though the gateway is mocked.
Ports and adapters: pointing at the provider's real certification environment touches one configuration file, plus loading the certificate they issue. Neither the domain nor the UI notices. That is the architectural argument.
A real-time sales feed over WebSocket, and the cents of the amount trigger each of the gateway's error paths — so failures can be demonstrated live, during a walkthrough, without touching code.

Outcome

Deployed and browsable. A single container serves both the mocked API and the app. The data is synthetic and generated from a fixed seed, so the prototype is reproducible.

Flutter
Node.js
WebSocket
RSA-SHA256
Docker

A prototype built for technical demonstration. It processes no real payments and is not affiliated with any company.

Fluxing LLC · own product

Business automation platform

The authentication and licensing server for the desktop application: signed credentials, bcrypt hashing, a server-side session for the admin panel and an audit trail of every access attempt. Around it, the product's synchronisation and orchestration services.

fluxing.app

Python
React Native
FastAPI
SQLAlchemy
JWT
n8n
Docker

Software engineering · 2024–2026

A messaging provider of my own

An instant-messaging channel built from scratch on the Baileys library and registered as a native provider of the CRM: it holds the session, reconnects, sends and receives through the platform's API, and publishes every message onto the broker for the asynchronous microservices to process. Three languages talking over queues, with signed webhooks, idempotency and retries with backoff.

Node.js
Fastify
Baileys
Java 17
Spring Boot
RabbitMQ
PostgreSQL
GoHighLevel

Roche · 2022–2024

Data and natural language over the warehouse

A Python library published on PyPI to reach several corporate data warehouses through a single client. A chatbot that turns natural-language questions into executable SQL against those warehouses and answers with the results. ETL processes, analytics dashboards, and reverse engineering of public APIs to bring external data in.

Python
FastAPI
SQLAlchemy
SQL Server
SSIS
Tableau
Amazon Redshift
AWS EC2

Experience

Where I have been, and what I built there.

Software Engineer & Project Manager

Otimify

Montevideo, Uruguay · remote

Design and construction of the in-house apps platform that extends the CRM the operation runs on: event pipeline, single sign-on, per-module permissions and the agent builder. In parallel, project management and prioritisation with clients.

Co-Founder

Fluxing LLC

United States · remote

An in-house business automation product. Architecture, backend, authentication and licensing, infrastructure and deployment. Mobile apps in React Native for iOS and Android.

Programming Lecturer

Universidad Nacional de José C. Paz

Buenos Aires, Argentina

Introduction to Programming, and Algorithms and Programming, in the BSc in Information Technology Management.

Software Engineer

The Old School Services

Buenos Aires, Argentina · remote

Designed, built and operated event-driven microservices in Java 17, talking over a message broker and collaborating with Node.js and Python services. Integrated SaaS platforms — GoHighLevel among them — through APIs and signed webhooks defined contract-first, with a strong focus on resilience (retries with backoff, idempotency), observability and security. Built a custom instant-messaging provider, registered as a native channel of the CRM, that holds the session, sends and receives through the platform's API and publishes every message onto the broker for the asynchronous services to process. Agents running in production for sales and appointment scheduling.

Data Engineer

Roche

Buenos Aires, Argentina

ETL processes and modelling over SQL Server and Amazon Redshift, with services running on EC2. A Python library published on PyPI unifying access to the company's data warehouses. Scraping and reverse engineering of public APIs to bring external data in, a natural-language-to-SQL chatbot, internal applications with AppSheet, and analytics dashboards in Tableau.

Virtual campus developer and administrator

Universidad Nacional de José C. Paz

Buenos Aires, Argentina

Built a custom client against the Moodle REST API to automate what the platform did not expose: course and user provisioning, enrolments, and synchronisation with the university's systems. Custom React frontends over the campus, and in-house PHP plugins extending Moodle's source. This is where I started working with Google Apps Script and the Google Workspace ecosystem to automate administrative processes. Data modelling and queries over MariaDB and PostgreSQL, with ad-hoc reporting for the administrative departments. Deployment, configuration and maintenance of the campus.

Website Administrator

Argentine National Secretariat of Modernisation

Buenos Aires, Argentina

Frontend of the institutional site, LAMP server administration, and the database behind the public examinations system.

Education

Degree and certifications.

Degree

University Programmer AnalystUniversidad Nacional de José C. Paz
2016 – 2019

Certifications

Object-Oriented Design — EscuelaIT (2020)
Denodo — data virtualisation, four modules (2022)

What I have worked with

Tools are context for the systems I built, not the skill itself. They are here for whoever is looking for them.

Languages: Java · Python · JavaScript · TypeScript · Dart · SQL · PHP
Backend: Spring Boot · FastAPI · Node.js · Fastify · Express · SQLAlchemy
Data: PostgreSQL · SQL Server · MySQL · MariaDB · Oracle · SSIS · Tableau · Amazon Redshift · AppSheet
Integration and messaging: RabbitMQ · REST · OpenAPI · Signed webhooks · WebSocket · n8n · GoHighLevel · Google Apps Script
Infrastructure: Docker · Docker Compose · nginx · Caddy · Linux · Git · CI/CD · AWS EC2
Security: RSA · Ed25519 · JWT · OAuth 2.0 · bcrypt · RBAC · Container isolation
Frontend and mobile: Flutter · React · Vite · HTML · CSS · React Native
AI: Claude Code · MCP · OpenAI API · LLMs in production

Contact

Lucas Matías Frías

Open to senior software engineering roles, remote or hybrid.

Email me WhatsApp LinkedIn Download the CV as PDF