Skip to content
JAJEFERSON AMORIM LET'S CONNECT

021990s → NOW · BUILT, NOT GIVEN

I DIDN'T INHERIT
A PATH INTO

technology. I built one.

I was born in a favela in a small Brazilian town, without an obvious path into technology. What I had was curiosity, teachers who recognized it, and the conviction that learning could change the direction of my life.

A winding mountain road at dawn, moving through mist toward the horizon.CH. 02

ONE ROAD · NO SHORTCUTS DRIVEN BY CURIOSITY

01
A late-1990s home computer and handwritten programming notes.

CH. 01 · 1990s-EARLY 2000sACCESS · CURIOSITY · SELF-DIRECTION

CH. 01 · 1990s-EARLY 2000s

The first system I had to build was my own future.

STUDENT / TEACHER / SELF-DIRECTED TECHNOLOGIST

THE CHALLENGE: Access to technology was scarce, and there was no established path waiting for me.

Teachers noticed my dedication and helped me enter public computer programs. One opportunity led to another, until I found myself learning BASIC and QBasic without yet realizing that I had started learning how to program.

My first computer outside an institution was an old XT that an uncle brought home. I played Carmen Sandiego, of course, but I also wanted to understand what happened before the game appeared: how the machine started, where its limits came from, and what made the system work.

Later, I studied data processing, learned Clipper, and started building a system for a neighborhood community center. I took apart and rebuilt my first computer, installed Linux, recompiled its kernel to make a soft modem work, and built a home network. Before being paid to work in technology, I was already learning, building, troubleshooting, and teaching it.

WHAT I LEARNED

You do not need perfect conditions to begin. You need curiosity, persistence, and the courage to work beyond what you already know.

MINDSET FORGED

My starting point does not determine how far I can go.

TECH

  • BASIC
  • QBasic
  • Clipper
  • Linux
  • Hardware
  • Networking

→ The next chapter called for a wider system.

SEE THE WORK
02
An early home network lab with cables, a switch, and a system diagram.

CH. 02 · EARLY CAREERINFRASTRUCTURE · OPERATIONS · FIRST BREAK

CH. 02 · EARLY CAREER

I earned the opportunity before I was ready for it.

INFRASTRUCTURE AND TECHNICAL SUPPORT · CONSOFT

THE CHALLENGE: My first technology role required Windows networking and Windows NT. I knew neither.

I convinced one friend to bring a computer to my house, borrowed a switch from another, and built a Windows network so I could experiment before the interview. I got the job. Then I spent my first day building a Windows NT practice environment and teaching myself how to do the work.

Supporting infrastructure for the São Paulo State Department of Finance gave me a view many developers encounter much later. I worked with networks, routing, DNS, web and mail servers, databases, operating systems, and production support. I also built a PHP and MySQL process-tracking tool. Infrastructure gave me the foundation. Software showed me how much more I could create with it.

WHAT I LEARNED

Applications do not live in isolation. Behind every line of code is an operating system, a network, a database, a security boundary, and someone depending on all of it to work.

MINDSET FORGED

Learn the whole system, especially the parts other people overlook.

TECH

  • TCP/IP
  • DNS
  • Linux
  • Windows Server
  • Active Directory
  • Solaris
  • PHP
  • MySQL

→ The next chapter called for a wider system.

SEE THE WORK
03
A game-platform engineering desk with delivery and operations tools.

CH. 03 · 2008-2016DEVELOPMENT · SCALE · LEADERSHIP

CH. 03 · 2008-2016

I joined as a developer. I grew into an owner.

PHP DEVELOPER → .NET DEVELOPER → LEAD DEVELOPER · LEVEL UP GAMES

THE CHALLENGE: One of Brazil's largest online-game publishers needed to serve players, payments, support, e-commerce, and large downloads under intense demand.

My infrastructure background changed the way I approached software. When servers struggled under traffic, I could follow the problem across the network, web server, cache, database, and deployment environment. I built the CMS that gave editors access to site content, worked with marketing to launch campaigns, and delivered an early banner-serving system for the game websites. As web architecture owner, I carried SEO, accessibility, responsive and mobile-first development, and performance measurement with Google Analytics, Tag Manager, PageSpeed Insights, and Core Web Vitals. I began mentoring a junior developer, moved to the .NET team closer to the core business, and eventually led a six-person team while managing projects and delivery.

Soon after joining, I identified security weaknesses and proposed mitigations. I was technically right, but I had not yet learned how to turn knowledge into organizational action. When the company was later attacked, I joined the incident response effort. Discovering a risk is only the beginning. A leader must communicate it in a way that makes action possible.

WHAT I LEARNED

Engineering leadership is helping people understand the problem, make better decisions, and move together when the stakes are real.

MINDSET FORGED

Own the outcome, not only the implementation.

TECH

  • PHP
  • .NET
  • C#
  • AngularJS
  • Yii
  • Apache
  • Nginx
  • Varnish
  • Jenkins

→ The next chapter called for a wider system.

SEE THE WORK
04
A remote cloud-architecture workstation with deployment sketches.

CH. 04 · 2016-2019GLOBAL DELIVERY · DEVOPS · ARCHITECTURE

CH. 04 · 2016-2019

My work crossed borders before I did.

FRONTEND DEVELOPER / DEVOPS ENGINEER / SOFTWARE ARCHITECT · CROSSOVER

THE CHALLENGE: Global teams needed to modernize long-lived enterprise systems without disrupting the people already depending on them.

Crossover was my first experience working for a US company. I worked across frontend development, DevOps, cloud infrastructure, and software architecture, deepening my experience with Docker, Azure, AWS, CI/CD, and enterprise modernization.

The role changed how I thought about architecture. A good idea was not enough. I had to make the reasoning visible, test assumptions, build proofs of concept, and give distributed teams evidence they could use to move forward.

WHAT I LEARNED

Architecture is not authority. It is the practice of turning ambiguity into decisions a team can understand, test, and execute.

MINDSET FORGED

Make the direction clear enough for others to build on it.

TECH

  • AngularJS
  • Docker
  • CI/CD
  • Azure
  • AWS
  • SQL Server
  • IBM Watson

→ The next chapter called for a wider system.

SEE THE WORK
05
An accessibility and product-platform workbench with component tokens.

CH. 05 · 2019-2023PLATFORM MODERNIZATION · ACCESSIBILITY

CH. 05 · 2019-2023

I learned to modernize without losing what already worked.

SENIOR FULL-STACK DEVELOPER / SENIOR SOFTWARE ENGINEER · CEROS

THE CHALLENGE: A mature creative platform needed to evolve across its APIs, frontend, accessibility, testing, infrastructure, and engineering practices.

At Ceros, modernization was not a single migration. I designed APIs, helped move the frontend from Backbone to React, fixed accessibility issues, strengthened automated testing, and improved the infrastructure and delivery systems around the product.

The work demanded more than replacing old technology. Every architectural decision affected customers, product teams, and the engineers who would maintain the platform after us.

WHAT I LEARNED

The best modernization respects the value already inside a product while removing the constraints that prevent it from moving forward.

MINDSET FORGED

Leave the platform more capable than you found it.

TECH

  • React
  • TypeScript
  • NestJS
  • Docker
  • Jenkins
  • Terraform
  • Cloudflare
  • E2E Testing

→ The next chapter called for a wider system.

SEE THE WORK
06
Early product sketches, a prototype, and launch-planning tools.

CH. 06 · 2023-2026ZERO TO ONE · PRODUCT OWNERSHIP · AI

CH. 06 · 2023-2026

The specification was often an idea and a conversation.

SENIOR FULL-STACK DEVELOPER / AI ENGINEER · EARLY-STAGE PRODUCTS

THE CHALLENGE: Early-stage companies needed to turn uncertain ideas into products that people could use and the business could operate.

For almost three years, I helped small companies take ideas from paper to MVP and from MVP to production. There was rarely a large team or a perfect specification, so I moved between product discovery, interface decisions, APIs, data, cloud infrastructure, delivery, and mentoring.

This was also where AI became central to my work, both as a product capability and an engineering partner. I learned that connecting an application to a model is the easy part. The real product lives in everything around it: context, validation, state, human handoff, security, recovery, cost, and trust.

WHAT I LEARNED

Early-stage engineering is the discipline of turning uncertainty into something useful, testable, and real.

MINDSET FORGED

Do not wait for certainty. Build the system that creates it.

TECH

  • TypeScript
  • React
  • Node.js
  • GraphQL
  • AWS
  • ECS
  • CDK
  • RAG
  • LLM Workflows

→ The next chapter called for a wider system.

SEE THE WORK
07
An AI-native engineering workstation with a human final review.

CH. 07 · 2026-NOWAI-NATIVE DELIVERY · ENGINEERING JUDGMENT

CH. 07 · 2026-NOW

Software development changed. I changed with it.

SENIOR SOFTWARE ENGINEER / AI ENGINEER · G2i

THE CHALLENGE: Fast-moving projects required complete features across unfamiliar codebases, frequent context changes, and an uncompromising delivery pace.

At G2i, AI agents became part of my complete engineering workflow. I direct them across full-stack workstreams by providing the context, architecture, constraints, and acceptance criteria needed to produce useful results.

Agents provide leverage, not accountability. I remain responsible for reviewing the work, challenging assumptions, testing behavior, checking security and performance, and deciding whether it is ready to ship. I was not watching the next era of software development arrive. I was already working inside it.

WHAT I LEARNED

AI can multiply implementation capacity. It cannot replace context, taste, responsibility, or engineering judgment.

MINDSET FORGED

Use AI as leverage. Keep responsibility human.

TECH

  • AI Agents
  • TypeScript
  • APIs
  • Databases
  • Playwright
  • Vitest
  • CI/CD
  • Performance Engineering

→ The next chapter called for a wider system.

SEE THE WORK

THE NEXT CHAPTER

The technology keeps changing.

What it made possible changed everything.

I began this journey believing technology could transform my life. It did. The kid from a favela in a small town became an engineer whose work crossed borders. I traveled through Brazil and the world, built a home and a family, became the father of an amazing child, and gained the ability to support my parents and the people I love. Those achievements are not separate from my professional journey. They are the reason it matters.

LET'S CONNECT WORK