skip to content

Fullstack that reaches production tested, secure and observable.

I build end to end in TypeScript, React, NestJS and Java, and I only call something done after it has been tested, measured and reviewed for security.

now Fullstack Developer · Stech Soluções Tecnológicas

Three cases and what I decided in each

see all projects
  • TaskForge

    Orchestrator that turns a request into a task graph, isolates each task in its own Git worktree and runs them in parallel waves, with human review and merge at the end. The planner is read-only, and no agent can publish on its own.

    1. Pressure and constraint

      An agent writing to a shared repository is a risk: a solo publish has to be impossible, not merely unlikely.

    2. Decision

      Split planning from execution, keep the planner read-only, isolate every task in its own branch and worktree, and leave review and merge to a person.

    • professional
    • TypeScript
    • Node.js
    • Zod
    • Git worktrees
  • StechClub

    Education platform delivered end to end: public area, company SSO, learning tracks, video served through signed S3 links, an application quiz and an admin panel. Used today by 15+ mentees.

    1. Pressure and constraint

      The company already had its own SSO, and course video cannot be served straight from the bucket.

    2. Decision

      Reuse corporate SSO instead of reimplementing auth, address media by hash under separate prefixes, and hand out links through an authenticated API.

    • professional
    • React
    • Vite
    • TypeScript
    • NestJS
  • Conn-Pod

    A library that splits AI work across different models: one executes, another verifies. Each role has declared read and write scope, bounded retries and an evidence receipt tied to the version. Every task runs in its own Git worktree, under a sandbox.

    1. Pressure and constraint

      The model that writes code cannot be the one that approves it. And an agent with disk access is attack surface: the boundary has to be verifiable, not agreed upon.

    2. Decision

      Split executor and verifier by model, run each task in its own worktree and keep writes with the host, which then checks that only the declared paths changed. A subscription is the default profile; paid API usage is opt-in only.

    • personal
    • TypeScript
    • Node.js
    • Claude Code
    • Codex CLI

Where I've worked

see the full career
2026 — present
Stech Soluções TecnológicasFullstack Developer
2025 — 2026
Cebrac CursosInformation Technology Instructor
2024 — 2025
Outlier / Scale AITest Engineer
2024
Make Acelerador de VendasFrontend Developer
2022 — 2024
Persys Projetos de Inovação TecnológicaFullstack Developer
2021 — 2022
Sintel S.A.Support Analyst (internship)
2020 — 2021
Itaú UnibancoMarket Intelligence (internship)

How I read a problem

Four questions I ask before calling a task delivered.

  1. Context

    Before writing code, I try to understand who depends on the system and what has already failed in it.

  2. Constraint

    Deadline, team and existing debt are part of the problem, so the solution has to fit the constraint that actually exists.

  3. Decision

    I write down what I chose, what I dropped and why, so the next person does not have the same argument again.

  4. Evidence

    Tests, metrics and review close the task. If I cannot show the scenario where it works, it is not done yet.

What I don't compromise on

Quality
The test is written with the feature, not after it.
Security
A failing security gate blocks the merge, even when it looks like noise.
Operations
I leave enough logs and metrics for someone else to diagnose the problem without calling me.
Communication
I write the decision down in a text that stays useful after I leave the project.

If one of these cases looks like a problem of yours, write to me.