DEV Community: Rubén Rangel

Stripe puts its AI agents in boxes. I did the same with my accounting system.

Rubén Rangel — Tue, 27 Oct 2026 00:00:00 +0000

What caught my attention in Stripe's Minions, what I borrowed, what I left out on purpose, and how my own agents found the holes in the box I built for them.

In February, Stripe published two articles (part 1 and part 2) about Minions , its internal coding agents. The number everyone repeated was the PR count: more than 1,300 a week merged into main, written start to finish by an agent, reviewed by people but without a single line of human code.

The number didn't move me much. What stopped me was an idea from the second part: the system gets more reliable the more they lock the model into small boxes. Reading it, I realized something uncomfortable about my own agent workflow: almost everything that protected it was a paragraph in a Markdown file.

This article is about how I changed that.

What Stripe does, in five ideas

Unattended, end to end. An engineer tags the bot in a Slack thread and the next thing they see is a PR that passes CI, with no interaction in between. They do it because the company's scarcest resource is developer attention, and an unattended agent lets you launch several tasks in parallel.
Isolation is what enables autonomy. Each run happens on a devbox, the same development machine humans use, ready in about 10 seconds and cut off from production and the internet. Since a mistake can only break that one devbox, the agent runs with full permissions and no confirmation prompts.
Blueprints. The flow is a state machine written in code that mixes two kinds of node: deterministic ones (run linters, push), which never call an LLM, and agent ones (implement the task, fix CI), which do make decisions. Whatever can be anticipated is done by code.
Curated context, not abundant context. They have almost no global rules: rules load per subdirectory as the agent walks the repo. Their internal MCP server has close to 500 tools, and each agent gets only a small subset.
Feedback shifted left, with a cap. Anything that would fail in CI is caught earlier, by local linters that answer in under five seconds. And there are at most two rounds of CI : after that, the PR goes back to a human.

Underneath it all is one idea that sums up their philosophy: what's good for humans is good for agents too. They didn't build new infrastructure for AI; the agents use the same tools their engineers have been tuning for years.

My context: one person, not a thousand

I'm building PyME Contable , a concept-based accounting system for small construction companies in Colombia, meant to grow into an ERP. Laravel 13, PostgreSQL 17 and a React SPA in TypeScript, all in Docker. I'm the only developer, working with an accountant who validates the accounting and tax rules.

Some things in this system are never negotiable: a journal entry always balances, a posted document is never modified, a company never sees another company's data (RLS in Postgres), sequential numbers have no gaps, and an amount is never a float. When two goals collide, the order is fixed: accounting integrity, security, compliance, performance, simplicity and, last, convenience.

My agent workflow existed before I read Stripe. It's the evolution of the one I described in the previous article:

Architect (the main session, Opus): plans, delegates and doesn't write code.
Tester (Sonnet): writes one test and watches it fail before the code exists.
Coder (Sonnet): writes the minimum to turn it green, without touching the test.
Code, security and performance reviewers (Opus): read, probe and report; they don't fix.
Me : I approve every plan and every commit.

The hole Stripe showed me

Comparing it to blueprints, I saw the problem. "The tester only writes in the tests folder", "the coder never touches tests", "reviewers don't write to the database": all of those were instructions. Sentences in .claude/agents/*.md that the model reads and, almost always, respects.

Almost always is not a guarantee. A model can forget a rule in a long conversation, interpret it creatively or, worse, receive contrary instructions from a dependency's README or a web page. In a system whose first priority is accounting integrity, "almost always" isn't enough.

Stripe doesn't trust the agent to behave: it trusts the box. That's what I wanted to borrow.

What I didn't borrow, on purpose

Before what I did borrow, what I didn't:

No unattended runs and no parallelism. Stripe needs them because its bottleneck is the attention of thousands of engineers. Mine isn't volume, and my approvals aren't an obstacle: they're part of the control.
No custom harness. Stripe forked an open-source agent. With a single developer, that's pure overengineering. I use Claude Code and its mechanisms: subagents, hooks and permissions.

What transfers from Stripe are the patterns, not the parts.

What I did borrow: deterministic gates

I turned the most important rules into gates : code that always runs and doesn't depend on the model remembering anything. I numbered them G0 to G5 so I could close them one by one.

Gate	What it does	Stripe idea	Status
G0	One branch per step, PR into a protected `main`, required CI and no admin bypass	Push and CI as deterministic nodes	Done
G1	A hook that intercepts every tool call and allows or blocks it based on the agent's role	Put the LLM in a box	Done
G2	Fingerprint of approved tests: if the coder touches a test, it doesn't pass	Code handles what can be anticipated	Pending
G3	SQL mutations: deliberately break each Postgres invariant and require a test to fail	Automated feedback to iterate against	Pending
G4	CI with actionlint, hadolint, `composer audit` and `npm audit`, which I also run locally before the PR	Shift feedback left	Done
G5	Retire LLM review where a linter does better (CI, Dockerfile, lockfiles)	An LLM only where judgment adds value	Pending

G1: the box

The core piece is a Claude Code PreToolUse hook: a Python script that receives every attempt to use a tool, along with the type of agent making it, and answers yes or no. The rules, in short:

The tester can only write to backend/tests/** and to the frontend's *.test.* files.
The coder can't touch tests, docs/, .claude/, CLAUDE.md or .env, not even through Bash with >, sed -i or cp.
Neither of them runs git operations that write, migrations, or dependency installs.
The code reviewer can only use git diff, status, log, show and read files.
The security and performance reviewers can query Postgres, but as the application role, never as superuser, and any SQL that writes must run inside BEGIN ... ROLLBACK.
Any other subagent is read-only.
If the script crashes or Python is missing, it blocks. It fails closed.

This is what a reviewer sees when it tries to delete a table outside a transaction:

Blocked by .claude/hooks/role_guard.py: writing SQL must run inside
BEGIN ... ROLLBACK, never COMMIT. If you need it, stop and ask the architect.
exit=2

The same query wrapped in BEGIN ... ROLLBACK goes through. The instruction in the Markdown is still there, but it's no longer the only thing.

My agents reviewed the box, and broke it

I ran the hook through my own workflow: the code reviewer and the security reviewer in parallel, on the uncommitted change. They found things nobody had seen: ways to slip past the rules with quoting and heredocs, a psql meta-command left open, and a test for the hook itself that passed for the wrong reason, because the command it was supposed to block was already blocked by another rule. A test that can't fail proves nothing, which is exactly what this workflow exists to prevent.

My rule, like Stripe's, is at most two rounds of fixes. Here I ran a third one, as an explicit exception, because the findings crossed real boundaries.

Then the architect pointed out something no reviewer had said: the subagents run in WSL as my user. Any interpreter, a simple python3 -c that writes a file, slips under the hook without it being able to read what it does. And there's something worse: the tester and the coder need docker compose to run tests, and whoever can run Docker is root inside the containers.

The lesson: a guardrail is not a barrier

That finding changed how I understand gate G1:

For the agents that write (tester and coder), the hook is a guardrail : it stops them when they make a mistake, which is what happens almost every time. It doesn't stop them if something induces them to evade it, and patching a blocklist for them has diminishing returns.
For the reviewers , it is a real barrier , because there it works as an allowlist: whatever isn't explicitly authorized doesn't run.

The realistic threat isn't a malicious agent. It's a prompt injection arriving in a file or a page. Against that, the real barriers live outside the hook: a protected main with no bypass, so my key can only push branches; an SSH key with a passphrase; and I do the pushes and merges myself.

Here's the honest difference from Stripe. Their real box isn't the prompt or the hook: it's the devbox, a machine that can't see production, the internet, or anyone's credentials. I don't have devboxes. My box has holes, I know them, and they're written down in decisiones.md as a trade-off, not hidden. The next step is evaluating Claude Code's Bash sandbox, which restricts reads, writes and network at the operating system level, to close the biggest ones.

"Good for humans, good for agents", at a scale of one

The idea that helped me most wasn't technical. I work alone and, even so, every step gets its own branch and goes in through a PR. It isn't bureaucracy: the PR is where CI runs and where the step's summary lives, with the reviewers' findings. It's the audit trail I'd want if I reviewed this system a year from now, and it's the same one an agent needs to understand what happened.

And one rule I took from their "shift feedback left": whatever a reviewer finds once becomes a permanent test. If the security reviewer spots a misconfigured SECURITY DEFINER function, the fix doesn't end there: a test on the Postgres catalog stays behind and checks every function of that kind. That way, not repeating the mistake doesn't depend on another reviewer having the same good day.

What's next

Now I want to pull this workflow out of PyME Contable and use it in all my projects. I'm trying two ways of packaging it in parallel, a Claude Code plugin and a template, to compare the results. The rule for splitting is simple: roles, gates and the order of the flow are generic; the accounting invariants stay in the CLAUDE.md of the repo that needs them.

What I take from Stripe fits in one line: the instruction guides the agent, but what stops it is code. And when code can't stop it, the honest thing is to write that down.

Sources: Minions, part 1 and part 2, from Stripe's engineering blog. Tools: Claude Code with file-defined subagents, a Python PreToolUse hook and GitHub Actions.

From 354 MB to 16 MB: Docker under the hood, multi-stage builds and a Vercel deploy from the terminal

Rubén Rangel — Sat, 03 Oct 2026 00:00:00 +0000

What an image really is, what a container is, why the order of your Dockerfile decides how long you wait on every build, and how I ended up shipping a Go server to Vercel with a single command.

I wrote a twenty-line HTTP server in Go. The first image that packaged it weighed 354 MB. The final version, which does exactly the same thing, weighs 16 MB. I didn't change a single line of Go. I only changed how the Dockerfile was written.

This article explains why, starting with the basics: what an image is and what a container is. If you already have those down, skip to the caching section.

Image and container: the recipe and the dish

An image is a read-only package with everything an application needs to start: a minimal filesystem, libraries, the binary and the instruction for what to run. It doesn't run, doesn't change, has no state. It's a template.

A container is a running image. Docker takes the image, puts a thin writable layer on top of it, gives it its own process and network space, and starts the command. Whatever the program writes goes to that layer, never to the image.

If the image is the recipe, the container is the dish being served. You can serve ten dishes from the same recipe, and if you salt one of them, the recipe doesn't change and neither do the other nine.

How a Dockerfile becomes layers

An image is not a single block. It's a stack of layers , and almost every instruction in the Dockerfile produces one. Each layer stores only what changed compared to the previous one.

This is the final Dockerfile of my project:

FROM golang:1.24-alpine AS builder
WORKDIR /src
COPY . .
RUN go build -o /server main.go

FROM alpine:3.20 AS runner
COPY --from=builder /server /server
CMD ["/server"]

And this is what Docker reports for the final image with docker history:

CMD ["/server"] 0B
COPY /server /server 8.15MB
CMD ["/bin/sh"] 0B
ADD alpine-minirootfs-3.20.10 ... 7.81MB

Two layers with weight: the Alpine base system (7.8 MB) and my binary (8.1 MB). Instructions like CMD or WORKDIR only store metadata and weigh 0 bytes. There are the 16 MB, not one more.

The cache: step order matters

Because each layer depends on the one before it, Docker can reuse them. On a rebuild it walks the Dockerfile top to bottom and, as long as the instruction and its input files haven't changed, it uses the layer it already has stored. As soon as one layer changes, every layer after it gets rebuilt.

That turns ordering into a design decision. The rule: what rarely changes goes on top, what changes often goes at the bottom.

In a Go project with dependencies, the difference looks like this:

# Bad: any code change invalidates the dependency download
COPY . .
RUN go mod download
RUN go build -o /server .


# Good: dependencies are only downloaded if go.mod or go.sum change
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o /server .

In the bad version, editing a comment in main.go changes the context of COPY . ., and that forces every dependency to be downloaded again. In the good one, go.mod and go.sum didn't change, so the dependency layer comes from cache and only the code is recompiled.

The benefits are concrete:

Faster builds. The expensive work (downloading dependencies, installing system packages) is done once and reused.
Less network and disk. Shared layers are stored only once, even if many images use them.
Lighter deploys. When pushing or pulling an image, only the layers the destination doesn't have travel.

One detail that completes the rule: a .dockerignore file that excludes .git, node_modules or local binaries keeps irrelevant changes from invalidating COPY . ..

Multi-stage: build in one image, run in another

Here's the difference between 354 MB and 16 MB.

To compile Go you need the compiler, the standard library and the build tools. To run the resulting binary you need none of that. A single-stage Dockerfile puts everything into the final image:

# The bad: a single stage. The final image drags the compiler along.
FROM golang:1.24-alpine
WORKDIR /src
COPY . .
RUN go build -o /server main.go
CMD ["/server"]

A multi-stage build separates responsibilities. Each FROM starts a new stage with its own base:

builder starts from golang:1.24-alpine, compiles and produces the binary. It's a throwaway stage.
runner starts from alpine:3.20, which is clean, and with COPY --from=builder takes only the binary.

Everything that was in builder (the compiler, the source code, the build cache) stays out of the final image. Measured on my machine:

Image	Size	Contains the compiler?	Contains the source code?
`builder` stage (same as a single stage)	354 MB	Yes	Yes
`runner` stage (final image)	16 MB	No	No

95% smaller. And it's not just size: fewer things inside means fewer packages with vulnerabilities, nothing useful for an attacker who gets into the container, and faster startups because there's less to download.

Naming the stages also helps with debugging. If something fails at compile time, you can build just that stage:

docker build -f Dockerfile.vercel --target builder -t go-vercel:builder .

Many containers, one image, zero interference

Because the image is read-only, nobody can modify it while it runs. Each container gets its own writable layer on top of the same shared layers. That's what lets you start ten containers from the same image without them stepping on each other.

I tested it with two containers from the same Alpine image:

docker run -d --name a alpine:3.20 sleep 300
docker run -d --name b alpine:3.20 sleep 300

docker exec a sh -c 'echo hello > /note.txt'

docker exec a cat /note.txt # hello
docker exec b cat /note.txt # No such file or directory

The file exists in a and not in b. They wrote on top of the same image, but each one in its own layer.

Why data is lost without a volume

The writable layer lives and dies with the container. If you remove the container, its layer goes with it. Continuing the example:

docker rm -f a
docker run -d --name a alpine:3.20 sleep 300
docker exec a cat /note.txt # No such file or directory

Same name, same image, but it's a new container with a new, empty layer. The note is gone.

And that's not a bug, it's the design: containers are ephemeral on purpose, so you can destroy, replace and scale them without fear. A version upgrade, for example, is exactly that: remove the old container and create a new one from the new image.

Whatever has to survive (a database, files uploaded by users) goes in a volume : storage that Docker manages outside the container and mounts at a path inside it.

docker volume create notes
docker run --rm -v notes:/data alpine:3.20 sh -c 'echo hello > /data/note.txt'
docker run --rm -v notes:/data alpine:3.20 cat /data/note.txt # hello

The first container wrote and was destroyed (--rm). The second, brand new, found the file. The data lived in the volume, not in the container.

The practical rule: the image is the code, the container is the process, the volume is the state.

The finale: from the terminal to Vercel

With the image optimized, all that was left was shipping it. Vercel can run containers: if the project has a Dockerfile.vercel, it uses it to build the image, starts the final stage and injects the PORT variable. That's why the server reads it from the environment instead of hardcoding it:

port := os.Getenv("PORT")
if port == "" {
    port = "80"
}

The whole deploy was done from the terminal, with no connected repository and no pipeline:

vercel link # links the folder to a project
vercel --prod # builds the image and publishes it to production

Vercel detected the project with the Container preset, built both stages, and 34 seconds later the server was responding:

curl https://05-vercel-bice.vercel.app
# Hello from a container on Vercel 👋

What I take away

An image is a read-only template made of layers; a container is that template running, with its own layer to write to.
The order of the Dockerfile decides what gets reused from cache: stable things on top, changing things at the bottom.
Multi-stage separates the workshop from the shop window: you build with everything, you ship only what's needed. In this case, from 354 MB to 16 MB.
Containers from the same image don't affect each other because each one writes to its own layer.
Whatever isn't in a volume is lost when the container is removed, and that's an advantage if you design for it.

The code is at github.com/rubenerangel/go-docker-vercel and the live demo at 05-vercel-bice.vercel.app. Tools: Go 1.24, Docker with BuildKit, Alpine 3.20 and the Vercel CLI.

Four AI agents build my code. The most valuable one knows nothing.

Rubén Rangel — Tue, 15 Sep 2026 00:00:00 +0000

How I split the work between AI agents with locked-down roles, and why the last one — the one that arrives with no context — is the one that finds what everyone else misses.

I recently finished a change to a KPI and payroll platform in eight steps. I verified every step myself, with my own eyes, before moving to the next. At the end, an agent I had told nothing about any of it found two problems I had completely missed.

This article explains how I work with AI agents, who does what, and why that last agent is worth more precisely because it knows nothing.

The rule that changes everything

The AI builds; I direct. I don't write the code: I write the instructions, hand out the work, and verify what comes back. It sounds like delegation, and it is. But it has a trap that took me a while to see: directing is not reviewing. Whoever runs the build site knows too much about it to look at it with fresh eyes.

To make the analogy work, picture a construction site with four people: an inspector, a bricklayer, a site foreman, and, at the very end, an outside surveyor. Each has a locked-down role and a list of things they are forbidden to do.

1 · The inspector writes the test before the wall exists

In software, a test is a small program that checks one single thing: "if this goes in, that must come out." The inspector writes one test, for one behavior, before the code that satisfies it exists. By definition, that test fails (it's "red"). There is no wall yet.

Its most important rule is easy to say and hard to follow: the correct answer is written by hand from the rule, never copied from what the program returns. If the inspector runs the program and writes down whatever came out as "correct," the test will approve anything and can never contradict anyone.

A real example. The work card said: "there are 15 browser tooltips to replace." That 15 came from the system's own counter. Counting by hand, there were 17 : the counter had two holes and was missing two. Had we trusted the program, the job would have finished "green" with two tooltips still alive.

Forbidden: writing solution code, touching any other test, and inventing business rules. If the expected value isn't on the card, it stops and asks.

2 · The bricklayer builds that wall, and only that one

The bricklayer receives the red test and writes the minimum code that turns it green. Nothing speculative, no "while I'm at it." Only the files it has been authorized to touch.

It is forbidden to touch the test. If it thinks the test is wrong, it says so and justifies it; it doesn't quietly rewrite it or mark it as "skipped." It doesn't fix other things along the way either, and it doesn't add anything nobody asked for.

What I liked most about this role I saw when I was the one who got it wrong. In one instruction I told it where to put a certain technical detail, and I was mistaken. The bricklayer neither obeyed nor changed it silently: it stopped, explained why my instruction was incorrect, and reported it. I fixed the following instructions. An agent that pushes back with good reason is worth more than one that obeys.

3 · The foreman doesn't trust the report

That's me. The foreman writes neither code nor tests: it hands out the assignments and verifies every delivery independently. It's not enough for the inspector to say "the test fails": I run it myself and read why it fails. It's not enough for the bricklayer to say "it passes now": I run it myself.

And there's one check I consider the most important of all: the test of the test. Once everything is green, I remove only the bricklayer's fix and confirm the test goes red again. If it stays green without the fix, the test was useless and has to be redone. In this case, removing the fix turned the test red listing the 17 tooltips — not one more, not one less.

The inspector → bricklayer → verification cycle repeated eight times, from small to large. On the last step, when running all the platform's tests — not just the new one — nine old tests broke: they were looking up elements by the very attribute we were removing. The bricklayer stopped and reported it instead of tweaking them to pass. That is exactly the behavior you want: a broken test is a question, not an obstacle.

At the end, I counted browser tooltips on the running platform: 186 before, 0 after. Forty-six screenshots, light and dark. Everything verified.

And still, things got past me.

4 · The outside surveyor: arrives knowing nothing

The reviewer is an agent in a clean session : it has no access to the conversation where everything was planned and built. It receives exactly two things: the original card (what was asked) and the final result (what changed). It is read-only : it can't fix anything, only report.

Its instructions begin like this:

You arrive without the context of the build and look at the
change as if it were someone else's. That ignorance is the
value: don't accept anything just because "it makes sense."

It checks seven angles, always the same ones:

Did it do what the card asked, and only that? Anything extra gets flagged.
Did it stay where it belonged? Some areas of the system are off-limits. Touching one is a blocker.
Does the test actually work? Would it fail without this fix? It says so explicitly.
Did it invent business rules? Thresholds, texts, or criteria the card didn't bring.
Does it hide any failure? Errors swallowed in silence, defaults that paper over a real gap.
Does the interface follow the standards? Components, accessibility, keyboard, contrast.
Does every touched screen answer its seven states? Empty, loading, error, no permission, one item, many items, very long text.

It reports from most serious to least, separating blocker from suggestion. And if it finds nothing in an angle, it says so: "I found nothing here" is information; silence is not.

What it found

Eight findings. Two blockers. Both fixed.

Finding	What was done
Blocker. There was a folder of browser tests — the ones that simulate a person using the platform — still looking up elements by the removed attribute. In eight steps nobody had opened it.	Fixed and verified by actually running those tests, not by reasoning about them.
Blocker. The written plan said twice "nothing becomes keyboard-focusable," and the code made three cells focusable.	The code was right: the decision changed mid-way, with new information, and the plan wasn't updated. The plan was corrected.
"No screen-reader label is lost" was inaccurate: descriptions are lost, not names, in four places.	Text corrected and declared in the delivery as a real loss.
On the heaviest screen, tooltips had no width cap.	Fixed and measured.
The plan required measuring performance on the screen with the most elements, and there was no measurement.	Measured, three runs. Opening a week goes from 152 ms to 265 ms; nothing else moves.
The counter still has three theoretical holes.	Declared, not fixed: none exists in the system today. Closing them is another card.

None of the findings was resolved by touching a test to make it pass. None was dismissed without a reason.

Why I can't be the reviewer

Look at the first blocker. I verified eight steps, ran every test twice, removed the fix to see it fail again, took 46 screenshots. And I never opened that folder. Not because I was careless, but because I knew where to look, and that's why I didn't look where I didn't know.

That's the problem with context. Whoever planned and directed a build reviews with a map in their head: they check the places the map marks. The surveyor has no map. It looks at the whole result, with the same seven questions as always, and finds what the map didn't include.

The second blocker is the same lesson from the other side: the plan and the code contradicted each other, and I didn't see it because I knew why. The decision had changed mid-way, for good reason, and in my head the contradiction didn't exist. For someone who only reads the paper and the result, it did.

In the previous article I wrote: automate the proposal, never the approval. This is the other half: whoever approves cannot be whoever built , not even when the builder is the AI and the director is you. A reviewer with no context is not a luxury. It's the only way anyone looks with fresh eyes.

Tools: Claude Code with file-defined agents (one per role, with restricted tools: the reviewer can only read). The method comes from a decades-old practice — the failing test first — applied to agents instead of people.

What to Prepare for a Tech Interview

Rubén Rangel — Sun, 03 Aug 2025 00:00:00 +0000

If you're getting ready for a technical interview, it's important to understand that just knowing how to code is no longer enough.

Below, I share the key areas you need to master, based on my experience working with companies like SproutLoud , Ansira , Imaginamos , and more.

✅ 1. Have a short elevator pitch ready (45–60 seconds)

"I'm Rubén Rangel, a Full-Stack developer with 18 years of experience, mainly strong in PHP, JavaScript, Vue.js, Angular, Laravel, and NestJS. I enjoy building systems from scratch and I'm passionate about clean code, system design, and performance. I've led the full architecture of projects like Indigos Network, and I currently contribute to platforms at SproutLoud and Ansira that integrate marketing and automation at scale."

📌 Don't go on too long—they will ask you more questions later.

✅ 2. Prepare for questions about specific technologies

Can you tell me about your experience working with PHP, Python, JavaScript (React, Angular, or Vue)? What’s your strongest skill?

I have over 18 years of experience with JavaScript, including frameworks like Vue.js and Angular.

Vue.js is my strongest area, followed by Angular (up to version 9).

I’ve used Vue.js extensively for dashboards and dynamic interfaces, and Angular for complex enterprise apps.

I’ve also worked with Python for web scraping, backend services (PHP), REST APIs, and automation tasks.

I don’t have production experience with C#.

✅ Always be honest.

✅ 3. Clearly explain your experience in software architecture

Have you designed and led the technical architecture of a software product? Can you give an example?

Yes. At Indigos Network, I was responsible for designing and implementing the entire architecture of a purchasing platform that connects clients with suppliers. It included:

Modular backend in Laravel with domain-based structure

Frontend in Angular 9

Real-time notifications using Firebase

Infrastructure deployed on AWS (EC2, S3)

RESTful API and authentication layers

CI/CD automation and cloud deployment

I led decisions on the database schema, system scalability, and infrastructure setup at companies like Ormigga SAS, Tres Astronautas, Imaginamos, and Ansira.

Prepare 1 or 2 real architecture examples you've designed

Focus on:

🟨 Example 1: B2B Purchasing Platform for Companies (Ormigga)

Technology used:

Backend: PHP with Laravel 5.6 (later upgraded to 7.x)
Frontend: Angular 6 (upgraded to 9)
Database: MySQL
Realtime/Notifications: Firebase
Cloud: AWS (EC2, S3, Route 53)

System scalability:

To support user and transaction growth, I designed the architecture using AWS services. We used EC2 with autoscaling to handle traffic spikes, S3 for file storage, and Route 53 for load balancing and DNS. I modularized the backend into separate services (auth, purchases, suppliers), which allowed for horizontal scaling.

Key decisions I made:

Led the migration from Laravel 5.6 to 7.x, improving performance and compatibility
Upgraded the frontend from Angular 6 to 9 to take advantage of Ivy and faster load times
Implemented granular roles and permissions in the backend to control purchase approval flows
Used Firebase to implement a real-time notification system and chat between client and supplier

Problem it solved:

The company needed to digitize and scale its corporate purchasing process. Everything was manual before. The system enabled automation of the relationship between suppliers and buyers, budget control, cost optimization, and better traceability.

The platform needed to process and deliver personalized marketing campaigns to thousands of brand partners across multiple channels. My work helped make this logic more robust and scalable, ensuring performance and reliability for high-volume and high-priority campaigns. -->

✅ 4. Frequently Asked Interview Questions

🧠 How many years of experience do you have in digital transformation?

I have over 18 years of experience in digital transformation, especially in SaaS products.

For example, at Indigos Network, Imaginamos, SproutLoud, and Ansira, I led projects that replaced manual processes with complete web systems (dashboards, workflows, reports, APIs).

These efforts helped reduce human errors, save operational time, and centralize business data.

💬 Have you worked directly with clients in consulting or custom development environments?

Yes, I’ve worked directly with clients in multiple custom development agencies, including Indigos Network, Videobase, Imaginamos, and Tres Astronautas.

I always aim to translate technical terms into business value: I explain decisions based on benefits, use diagrams, and validate their needs with prototypes or user stories before developing.

💰 What is your salary expectation in USD?

I’m open to discussing fair compensation based on the role's responsibilities.

Based on my experience and the market, my target range is between $XXXXX and $XXXXX USD per year.

🇬🇧 English Level

📖✍️ Fluent in reading and writing (C1).

🧑‍💼💬 Comfortable handling meetings and asynchronous communication.

🗣️ Currently improving my spoken English (B2) and progressing quickly towards full fluency (C1).

🛠️ Key Technologies

Languages: JavaScript, TypeScript, PHP, Python, SQL

Frameworks: Vue.js, Angular, NestJS, Laravel, Django

Backend: Node.js, REST APIs, GraphQL

Databases: PostgreSQL, MySQL, MongoDB, DynamoDB

Cloud & DevOps: AWS (EC2, S3, RDS, Lambda, Fargate), Firebase, Docker, Redis

Others: TDD, SOLID, DDD, OAuth2, Git, Linux, WordPress

Soft skills: Leadership, Agile/Scrum, Client Communication, Code Review

🧭 Know Yourself

Strengths and Weaknesses

✅ I have over 18 years of experience with PHP and JavaScript , which allows me to confidently handle complex projects.

💬 I know how to gather requirements directly from clients and translate them into effective technical solutions.

🧠 When I need to work with technologies I'm not familiar with, I use Artificial Intelligence to find accurate and efficient paths to meet the requirements without wasting time.

⚙️ I haven't worked with Flask or React in production, but I have solid experience with NestJS and Vue.js , and I learn new frameworks quickly when needed.

🎯 Smart Questions for the End of the Interview

How is the engineering team structured in this role?
What challenges is the product currently facing?
What technologies do you plan to adopt or evolve over the next year?

🧱 Scalable Architecture Design (Frontend + Backend + Data + AI)

1. Frontend

SPA built with React or Vue 3
Tailwind CSS to keep the code clean and maintainable
Internationalized content (i18n)
SEO optimized with prerendering or SSR (Next.js)
Integration with a secure and managed API Gateway

2. Backend

Microservices using Laravel (PHP) or Spring Boot
Communication via events or queues (Kafka or RabbitMQ)
Orchestration in Kubernetes (EKS or GKE)
Authentication: OAuth2 with Laravel Passport or Auth0
CI/CD: GitLab Pipelines with testing, security, and automatic deployment

3. Data

Transactional database: PostgreSQL with replication and partitioning
Data lake in AWS S3 to store events, logs, and training datasets
Streaming and ETL: Kafka + Apache Flink
Dashboarding: Metabase or Apache Superset

4. AI / ML

Python (FastAPI) to expose trained models as microservices
Training with scikit-learn or TensorFlow, using pipelines in AWS SageMaker or Vertex AI
Anonymized and versioned data using DVC or MLflow
Models acting as internal services or asynchronously via queues

🚀 Scalability and Observability

📈 Horizontal autoscaling per service with Kubernetes + HPA
📊 Observability with Prometheus + Grafana
🕵️‍♂️ Tracing with Jaeger
📄 Logs with the ELK Stack
🧩 Event-driven architecture to decouple services

🧠 Key Decisions

✅ Choose Laravel
🧠 Separate AI into its own domain to isolate complexity
📬 Use queues and cache (Redis) to decouple expensive processes

🔍 Differences Between Monolith, Microservices, and Event-Driven Architecture

Feature	🧱 Monolith	🔗 Microservices	📡 Event-Driven Architecture
Definition	Entire system in one app	Independent services	Communication through events
Deployment	Single unit	Each service is separate	Services react to events
Scalability	Scales everything together	Each service scales independently	Scales based on event flows
Maintenance	Harder as it grows	More maintainable and modular	Modular and decoupled
Internal communication	Functions or classes	REST APIs or gRPC	Messages/events (Kafka, RabbitMQ, etc.)
Typical example	All-in-one Laravel app	Auth, Orders, Payments, etc.	User registers → emits event → others react

☁️ Using AWS in Scalable Architectures

I have worked directly with key AWS services to build and scale robust applications in production:

1️⃣ EC2 (Elastic Compute Cloud)

🚀 Host backend servers in production and staging
⚙️ Set up autoscaling + load balancers (ELB)
🔁 Automate deployments with CI/CD

2️⃣ Lambda

🖼️ Image processing when uploading to S3
🔔 Send asynchronous notifications
✅ Run validations on specific forms

3️⃣ S3 (Simple Storage Service)

📁 Store attachments, media content, and backups
🔐 Configure secure access policies and enable versioning

4️⃣ RDS (Relational Database Service)

💾 I use MySQL and PostgreSQL
📊 Set up read replicas and automatic backups
🌐 High availability with multi-AZ instances

5️⃣ API Gateway

🔒 Expose secure endpoints to microservices or Lambdas
⚠️ Set up throttling and authentication (JWT / Cognito)

6️⃣ Other key components

📡 CloudWatch: Logs and custom alerts
🌍 Route 53: DNS and health checks
🔐 IAM: Minimum necessary permissions
📬 SQS: Queues to decouple heavy processes (reports, emails)

🔐 How to protect sensitive information in distributed systems

In distributed systems involving multiple services, environments, and users, protecting sensitive information is a top priority. These are the strategies I apply:

1️⃣ Encryption

🔒 In transit:

I use HTTPS/TLS for all communication between services, frontend, and APIs.

Example: API Gateway + ACM certificates in AWS.
🗄️ At rest:

I enable AES-256 encryption in databases (RDS), storage (S3), and backups.

I also encrypt sensitive data in the app before storing it (e.g., tokens or card numbers).

2️⃣ Secret management

🧪 I use AWS Secrets Manager or Parameter Store to manage keys, passwords, tokens, and credentials.
❌ I avoid exposing sensitive data in environment variables or code.

3️⃣ Access control

🛡️ I apply the principle of least privilege using IAM for services and users.
🔐 I use OAuth2 / JWT to authorize access between systems and define scopes.
🧩 I separate environments (dev, staging, prod) with distinct roles and policies.

4️⃣ Traceability and auditing

📋 I log access and actions in CloudWatch , log systems (ELK stack), or tools like Datadog.
🔍 I audit changes to sensitive data (users, finances, permissions).

5️⃣ Validation and sanitization

⚠️ I apply strict validation and sanitization to prevent attacks (SQL injection, XSS).
🔁 I validate both on the frontend and in the APIs.

6️⃣ Incident response

🚨 I set up alerts for unusual access or security errors.
🔁 I have a key rotation and recovery plan in case of exposure.

🛡️ Security in modern systems: OAuth2, access roles, and encryption

🔑 OAuth2

In projects like Ormigga , I used Laravel Passport to implement OAuth2.
I issue access tokens with defined scopes.
I use JWT as the token format to validate permissions without querying the database.

👥 Access roles

👥 Access roles

🔐 I design authentication systems with hierarchical roles like Admin , Editor , and User , adapting them to business needs.

⚖️ I make sure each role only has access to what's necessary, following best practices for security and user experience.

🛠️ I’ve implemented these role schemes both in systems built from scratch and in existing platforms.

🛡️ Secure design best practices (OWASP principles)

In every system I design or maintain, I apply OWASP project principles to mitigate common risks and ensure security from the architecture level.

✅ 1. Strict input validation

I never trust data coming from the client
I use server-side validation (Laravel Requests) and sanitization to avoid injections (SQL, XSS)

🔐 2. Authentication and session management

I implement strong authentication (OAuth2, JWT)
I use token expiration, revocation, and inactive session detection
I protect against brute-force attacks by limiting login attempts

🔒 3. Role-based authorization

I use RBAC with detailed permission control
Each endpoint checks the user's role before allowing the action (principle of least privilege)

🔏 4. Strong encryption

Encryption in transit (TLS 1.2/1.3) for all communication
Encryption at rest in databases and storage (AES-256)
Passwords are stored using bcrypt or argon2

🚫 5. Secure error handling

I don’t expose traces, internal details, or sensitive messages to users
Errors are logged internally for auditing without compromising security

🔐 6. Secure defaults

All features start from a secure posture: access is denied unless explicitly allowed
I disable unused endpoints or configurations (e.g., debug in production)

🛑 7. CSRF and XSS protection

In Laravel, I enable CSRF middleware for forms
I use Content-Security-Policy and properly escape dynamic data in the frontend

🤖 Use of AI / LLMs in modern systems

I’ve started integrating Artificial Intelligence and large language models (LLMs) into web systems to automate tasks, enhance user experience, and offer advanced features.

💡 Use cases

📝 Automated content generation (descriptions, support replies, email drafts)
💬 Internal assistants for clients or providers (e.g., guided chatbots)
🏷️ Information classification (automatic tags, intent detection)
🎯 Personalized recommendations based on user behavior

🛠️ Technologies used

OpenAI API (GPT-4): for natural language tasks, integrated via backend in Laravel or Python microservice (FastAPI)
Hugging Face Transformers: for local inference in controlled environments where confidentiality is required
Python (scikit-learn, pandas, spaCy): for lightweight NLP or classification models
AWS S3 and RDS: to store training and inference datasets

🧩 Integration into architecture

Models are exposed as REST microservices or integrated via queues (SQS/Kafka) for asynchronous processes
For sensitive tasks, I anonymize and clean data before sending it to external services
I use logs and metrics to evaluate response quality and detect errors

🌍 Experience working with clients on real-world projects

Throughout my career, I’ve worked with various clients in countries like 🇻🇪 Venezuela, 🇨🇴 Colombia, 🇪🇸 Spain, and 🇨🇱 Chile, in companies such as Gaviria Software , Videobase , Indigos Network , Tres Astronautas , and Ormigga SAS , participating in the development of custom, scalable technology solutions aligned with real business goals.

🚀 Notable examples:

📺 Videobase: Developed custom streaming platforms, optimizing video upload and delivery using AWS S3 and CloudFront
🏢 Ormigga SAS: B2B purchasing platform with budget control, approval workflows, client-provider chat, and cloud storage (EC2, S3, RDS)
📣 Indigos Network: Marketing campaign automation for multiple brands, integrating third-party APIs and event-driven workflows
💼 Gaviria Software: Robust backend development with Laravel and PostgreSQL for financial control and licensing systems
👨‍🚀 Tres Astronautas: Frontend projects with Angular and backend with NodeJS/NestJS for SaaS products

In all these projects, I not only participated as a developer but also made architectural decisions, defined integration flows, optimized cloud resources, and ensured security best practices (🔒 OWASP, OAuth2, encryption).

🧠 Effective communication: from technical design to business understanding

One of my strengths as a senior developer has been translating complex technical solutions into understandable explanations for different audiences: from product managers and QA teams to non-technical stakeholders.

🛠️ How do I communicate solutions?

✅ Clear user stories
🧾 Visuals and diagrams
🗣️ Audience-adapted language

🔹 Ormigga

I visualized the full purchase order flow for different roles (buyer, supplier, financial manager) with real examples and scenarios
This reduced friction in the approval process and allowed validating the solution before full development was completed

🚀 Use cases for NestJS, Laravel, Docker, and AWS

🧱 NestJS

I’ve used NestJS in several projects, for example in Tres Astronautas , where I developed a REST API for property management. There, I applied:

✅ Modular architecture
✅ Dependency injection
✅ Use of DTOs and Guards
✅ Unit testing with Jest

🛠 Laravel

I’ve worked extensively with Laravel , including:

In Ormigga : I designed the full architecture of a B2B purchasing platform with:
- 🔐 User roles
- 📣 Real-time notifications
- ✅ Multi-step approval flow
Implementation of:
- 🔗 RESTful API
- 🛡 OAuth2 authentication
- ⚙️ Job queues
- 🧪 Testing with PHPUnit

🐳 Docker

Defined consistent development and deployment environments
Projects with microservices using Laravel and NodeJS
🔧 Used Docker Compose for local orchestration
📦 Optimized images for production

☁️ AWS

I’ve worked with multiple Amazon Web Services :

🖥 EC2 : Auto-scaled servers for critical applications
🗂 S3 : File, image, and backup storage
🛢 RDS : PostgreSQL and MySQL databases with high availability
⚡ Lambda : Serverless functions for specific tasks
📊 DynamoDB : For NoSQL workloads and fast queries
🐳 ECS Fargate : Run containers without managing servers
🛠 Infrastructure as Code (IaC) for reproducible environments

All of this allows me to deliver robust, scalable, and well-maintained solutions 💪.