# Lucas Duarte — Complete Profile

Lucas Duarte is a senior full-stack developer with 9 years of professional experience, working across 6 companies since 2017. His core stack is TypeScript end to end: React on the front, Node.js on the back, with Python and AWS alongside. He is most often brought in for performance and reliability work on systems that have grown past their original design — cutting a 12-second load to under 2.5 seconds, moving 240,000-record batches off the request path, taking legacy code from recurring bugs to an 80% drop in bug reports. Since 2025 his work has centred on agentic AI inside engineering workflows: MCP servers, autonomous QA agents, and generated end-to-end tests. He is based in Brazil, works in English and Portuguese, and is open to remote and full-time roles.

**Role:** Senior Full-stack Developer
**Email:** lucasduarte1112@outlook.com
**LinkedIn:** https://linkedin.com/in/lucasdu4rte
**GitHub:** https://github.com/lucasdu4rte
**WhatsApp:** https://wa.link/7k5jtl
**Portfolio:** https://oduarte.dev/

## Hiring questions, answered

**What is his seniority level?**

Senior. He has held Senior Software Engineer titles since 2021 at BOTY, DASA, MaisTODOS and Forecastr, and has been developing professionally since 2017.

**Is he a frontend or a backend developer?**

Both, genuinely. React and TypeScript on the front across every role; Node.js, NestJS, Python and .NET Core on the back; plus AWS, GCP, Docker, PostgreSQL, MongoDB, Redis and InfluxDB. At MaisTODOS and Intelup he made backend architecture decisions rather than only consuming APIs.

**Does he have real AI and LLM experience, or just familiarity?**

Production experience. At Forecastr he built an MCP server exposing the financial calculation engine to AI agents, and shipped bug triage and QA automation with n8n and GitHub Actions, including an agent that reproduces bug reports, generates Playwright tests and verifies fixes. He also trained an image classification ensemble with Python, Transformers and HuggingFace.

**Has he led technical work, or only executed it?**

Led. He proposed and drove the AngularJS to React migration at Intelup against an initial rejection, led the refactoring of legacy code at DASA using Adapter, Facade and Factory, led a from-scratch real-time chat at PECEGE that other teams then adopted, and mentored junior developers at DASA.

**Can he show measurable impact?**

Load times from around 12s to under 2.5s and interactions from about 2,500ms to 200ms at Forecastr; roughly 80% fewer bug reports in test-covered areas; about 50% lower chat cost at PECEGE; on-premise deployment from over three days to about three hours at Intelup; some pages up to 5x faster after the React migration; 100% test coverage at MaisTODOS; 100% Lighthouse accessibility at PECEGE.

**How does he handle unfamiliar technology?**

He has adopted a materially new stack in most years of his career and shipped with it — .NET Core and Firebase in 2020, XMPP in 2021, Module Federation in 2022, MCP and agent tooling in 2025, Swift and Tauri for personal projects. The pattern is choosing the technology the problem needs rather than the one he already knows.

**Has he worked in regulated or high-stakes domains?**

Yes. Telemedicine at DASA, the largest diagnostics company in Latin America, applying OWASP practices; financial products at MaisTODOS and Forecastr; and LGPD-compliant cross-company anonymisation for industrial benchmarking at Intelup.

**Does he build things outside work?**

Yes — 6 shipped side projects, including a full e-commerce with Mercado Pago, Pix, bank slip and card payments plus multi-carrier shipping integrations; a native macOS video playlist application in Swift; a desktop tool sold commercially, built with Tauri; and a machine learning sprite classifier.

**What languages does he work in?**

Portuguese natively and English professionally. This site is published in both, and his written technical work is in English.

**Is he available, and for what kind of role?**

Open to full-time positions and projects. Contact by email at lucasduarte1112@outlook.com, on WhatsApp, or via LinkedIn at linkedin.com/in/lucasdu4rte.

## Learning velocity

Technologies adopted and shipped with, by year:

**2018** — Proposed and led the AngularJS to React migration at Intelup after building an internal billing application in AdonisJS, React and Redux as proof — from a rejected proposal to a completed migration in about a year.

**2019** — Picked up Electron and the OPC industrial protocol to build offline data collection against InfluxDB, plus Docker to cut on-premise deployment from over three days to about three hours.

**2020** — Moved to an entirely new stack at PECEGE — Firebase, Google Cloud Functions and .NET Core — and shipped a real-time chat that cut chat cost by around 50% and a statistical matching API at roughly 70% accuracy.

**2021** — Learned the XMPP protocol at BOTY to build real-time messaging across the Wevy group's products, alongside GraphQL, Atomic Design and a video player SDK.

**2022** — Took on Webpack Module Federation to restructure DASA's telemedicine frontend into micro-frontends, and became the team's technical reference for MongoDB performance.

**2024** — Owned AWS Cognito authentication and the company SSO at MaisTODOS, applying Clean Architecture across a modular system to 100% test coverage.

**2025** — Adopted MCP, n8n and agent tooling at Forecastr to automate bug triage and QA, including an agent that writes and runs Playwright tests from bug reports. In parallel, learned Swift to ship a native macOS application and Tauri plus Python and HuggingFace for personal projects.

## Professional experience

### Forecastr — Senior Software Engineer

**Period:** 2025-04 to 2026-07
**Stack:** react, node.js, typescript, nest.js, playwright, mcp, n8n, github actions
**Summary:** Technical reference for the proprietary financial calculation engine.

Forecastr builds software for financial planning and analysis. Lucas became one of the technical references for the platform's proprietary financial calculation engine, working on performance, large-volume data processing, engine reliability, testing, and the automation of engineering processes with AI.

The clearest problem was speed. Processing and displaying large volumes of financial data took around 12 seconds. Through caching strategies, query optimisation and changes to how data was processed and accessed, he brought that down to under 2.5 seconds. Certain interactions that took roughly 2,500ms and stalled analysis came down to about 200ms.

Bulk processing was the second front. He built pipelines using job workers and streams for operations over batches of roughly 240,000 records, making reads, writes and processing efficient without blocking the main application.

Reliability had depended on manual checking. He implemented and expanded a suite covering unit, integration and end-to-end tests; after that strategy was adopted, bug reports in the covered areas fell by around 80%.

The last front was AI inside the engineering workflow itself. He took part in implementing an MCP (Model Context Protocol) server so AI agents could interact with the calculation engine's capabilities, and built bug triage and QA automation with custom agents and skills, integrating n8n and GitHub Actions. Within that work he developed an agent that creates and runs end-to-end tests with Playwright: it takes bug reports as input, reproduces the reported problem, captures evidence through the tests, and reuses those same tests to verify that a fix actually resolves the behaviour. The result turned part of bug investigation and QA into an agent-assisted flow, leaving developers the technical decisions and the final review.

**Key outcomes:**

- Loading large volumes of financial data took ~12s; with caching, query optimisation and changes to how data was processed and accessed, it dropped to under 2.5s.
- Some interactions took ~2,500ms and stalled analysis; by restructuring the processing behind them, they came down to ~200ms.
- Operations over batches of ~240k records blocked the app; I moved the work into pipelines with job workers and streams, making reads, writes and processing efficient without blocking the main application.
- Reliability depended on manual checking; I built a unit, integration and end-to-end test suite, and bug reports in the covered areas fell by around 80%.
- Investigating bugs ate hours of the team's time; I built an MCP server and AI agents with n8n and GitHub Actions that reproduce the report, generate Playwright tests and verify the fix, leaving the developer the technical call and the final review.

### MaisTODOS — Senior Software Engineer

**Period:** 2024-04 to 2025-04
**Stack:** react, node.js, typescript, nest.js, python, aws, aws cognito, redis
**Summary:** Platform integrated with the company's financial products.

MaisTODOS needed a platform that brought its financial products together, and did not have one. Lucas built the first version of that platform, working on it from its earliest iterations and taking part in the backend architecture decisions on Node.js and AWS, as well as the integration with the company's internal services.

Access had to be unified and secure across products. He maintained and evolved the authentication and authorisation architecture built on AWS Cognito, including the implementation of the SSO the company used.

A system composed of multiple modules tends to couple and stall. He applied Clean Architecture and SOLID principles across it, paired with a broad testing strategy that reached 100% test coverage, which gave the team room to evolve and maintain the application safely.

Several integrations with external services were significantly slow. He implemented caching with Redis, reducing how much the response time depended on repeated calls to third parties.

He also worked on the company's Design System, both building the reusable components and contributing to UI and UX decisions.

**Key outcomes:**

- The company had no platform bringing its financial products together; I built the first version and took part in the backend architecture decisions on Node.js and AWS and in the integration with internal services.
- Access had to be unified and secure across products; I maintained and evolved the authentication and authorisation architecture on AWS Cognito, including the company's SSO.
- A multi-module system tends to couple and stall; I applied Clean Architecture and SOLID alongside a broad testing strategy, reaching 100% coverage and making the application safe to maintain and evolve.
- Integrations with external services were significantly slow; I added Redis caching and cut the response time's dependency on repeated third-party calls.
- The products shared no visual language; I worked on the company's Design System, both building the reusable components and on the UI and UX decisions.

### DASA — Senior Software Engineer

**Period:** 2022-03 to 2024-04
**Stack:** react, node.js, typescript, nest.js, webpack, module federation, mongodb, jenkins, twilio sdk, zoom sdk, machine learning
**Summary:** Telemedicine at Latin America's largest diagnostics company.

DASA is the largest diagnostics company in Latin America and the sector leader in Brazil. Lucas worked mainly on digital products for telemedicine, and took part in the redesign of the company's main telemedicine application, working on both the user experience and the frontend architecture.

Legacy code produced recurring bugs and made every change risky. He implemented unit test coverage over that code, reducing the incidence of failures, and led its refactoring using patterns such as Adapter, Facade and Factory to make it more scalable and maintainable.

A monolithic frontend made parallel work across teams difficult. He structured and evolved a modular architecture based on micro-frontends using Webpack Module Federation, letting parts of the product evolve independently.

The Jenkins CI/CD pipeline was slow and held deliveries back; he introduced parallelism into its execution and cut the time of each run.

Beyond that, he integrated video through the Twilio and Zoom SDKs, worked on integration with anamnesis processes supported by machine learning and AI, applied security practices based on OWASP, acted as the team's technical reference for MongoDB — including monitoring and optimising query performance — and mentored junior developers. He also contributed to Alma, the Design System used at DASA, helping standardise the experience and the development of the company's different digital products.

**Key outcomes:**

- The main telemedicine application needed to move on; I took part in its redesign, working on both the user experience and the frontend architecture.
- Legacy code produced recurring bugs and made every change risky; I added unit test coverage over it and led its refactoring with Adapter, Facade and Factory, bringing the failure rate down.
- The monolithic frontend made parallel work across teams hard; I structured a modular micro-frontend architecture with Webpack Module Federation, letting parts evolve independently.
- The Jenkins CI/CD pipeline was slow and held deliveries back; I introduced parallelism and cut the time of each run.
- Poorly sized queries degraded production performance; I acted as the MongoDB technical reference, monitoring and optimising queries, while integrating video through Twilio and Zoom and mentoring junior developers.

### BOTY — Senior Software Engineer

**Period:** 2021-08 to 2022-02
**Stack:** react, node.js, typescript, graphql, xmpp, firebase, gcp, machine learning
**Summary:** Digital products across the Wevy group.

At BOTY, part of the Wevy group, every product was reimplementing its own components. Lucas developed the company's proprietary Design System applying Atomic Design concepts, standardising the components and visual identity of the products while increasing the development speed of the teams.

Real-time communication had to serve the demands of several different products and companies within the Wevy group at once. He implemented a communication architecture on the XMPP protocol focused on performance and scale, able to support a large volume of connections.

He also worked on a chatbot that ran both inside the platform itself and externally through an SDK. The product was used for process automation and included machine-learning features.

His remaining work there covered responsive interfaces, animations and transitions between screens and components, authentication with Firebase, integration with Google Cloud Storage, CI/CD on Google Cloud Platform, a GraphQL API, and a video player SDK.

**Key outcomes:**

- Every product reimplemented its own components; I built the company's proprietary Design System with Atomic Design, standardising the visual identity and speeding the teams up.
- Real-time communication had to serve several Wevy group products at once; I implemented an architecture over the XMPP protocol focused on performance and able to hold a large volume of connections.
- Manual processes ate the clients' time; I worked on a chatbot with Machine Learning features, available inside the platform and externally through an SDK.
- There was no foundation for shipping and distributing the products; I set up CI/CD on Google Cloud Platform, Firebase authentication, Cloud Storage integration, a GraphQL API and a video player SDK.

### PECEGE — Software Engineer

**Period:** 2020-08 to 2021-08
**Stack:** react, node.js, typescript, firebase, gcp, .net core, machine learning, lighthouse
**Summary:** Platform for managing the thesis-advising process.

Lucas joined PECEGE to work on a platform managing the thesis-advising process. When he arrived the project was close to its deadline, still unlaunched, and at real risk of a significant delay. One of his main contributions was helping the team accelerate that delivery, bringing strategies to prioritise what genuinely had to exist for launch and helping the team deliver more value in the time available. The project went into production on schedule, and the application is still running today.

The platform let advisors manage their students, thesis topics and the whole advising process. Students wrote their work directly in the application and advisors reviewed the text inside the system, which made it a heavily collaborative product: a WYSIWYG editor, content revisions, REST API integration, upload and management of large documents, and tracking of the thesis development process. He also took part directly in stakeholder interviews to gather and validate requirements.

Advisors ran live sessions to answer student questions, but most individual communication between advisors and students still happened over email, which made the process slow. He led the development of a chat system from scratch, covering both the live sessions and one-to-one conversations, and owned the project from the interface design through to the architecture and infrastructure decisions. The company already had a previous chat solution, but its maintenance cost was high because it used a more traditional architecture based on servers, REST APIs and relational databases. Since the new project needed a low operating cost, he chose Firebase, taking advantage of its NoSQL infrastructure and real-time features, with Google Cloud Functions for integrations and triggers fired by user actions or data changes. The new architecture significantly reduced the need for dedicated servers, WebSocket infrastructure and relational databases, and cut the cost of the chat by roughly 50%. The result was received well enough that other teams inside PECEGE began using the solution, and it was recognised by the CTO and the managers.

He also worked on an API responsible for matching advisors to students. It began as a statistical algorithm that ranked and assigned students to advisors based on information about their thesis topics. Machine learning experiments followed, mainly to analyse and improve the cases where the statistical algorithm did not produce the expected result; the statistical approach remained the primary solution, reaching roughly 70% accuracy, which was considered acceptable for the use case. The API was built with .NET Core.

Finally, he refactored and maintained the frontend with a focus on accessibility, reaching 100% on the accessibility criteria assessed by Google Lighthouse.

**Key outcomes:**

- The project was close to its deadline, unlaunched and at real risk of slipping; I helped the team prioritise what had to exist to ship, and the platform went live on time — it is still running today.
- Advisor–student conversation depended on email and a previous chat that was expensive to run on servers and a relational database; I led a real-time chat built from scratch on Firebase and Cloud Functions, cutting cost by around 50% and getting adopted by other teams.
- Students wrote and reviewed their work outside the system; I built the collaborative experience inside the platform, with a WYSIWYG editor, content reviews and large document uploads.
- Assigning advisors to students by hand did not scale; I built a .NET Core API with a statistical algorithm that ranks and matches by thesis topic, reaching around 70% accuracy.
- The frontend failed basic accessibility criteria; I refactored the interface with that focus and reached 100% on the criteria assessed by Google Lighthouse.

### Intelup — Software Engineer

**Period:** 2017-08 to 2020-08
**Stack:** react, node.js, redux, react native, angularjs, adonisjs, electron, web workers, python, pandas, sqlalchemy, postgresql, influxdb, docker, aws, opc
**Summary:** Shop-floor digitalisation with Industry 4.0 technologies.

Intelup works on shop-floor digitalisation using Industry 4.0 technologies, turning industrial data into strategic information to increase production efficiency and control. This was Lucas's first role, and the one where he spent the longest.

The main challenge he found on arriving was the frontend of the primary application, built in AngularJS 1. The system produced a steady stream of interface bug reports and, above all, data synchronisation problems: the heavy use of two-way data binding meant a change in one part of the application could produce side effects and inconsistencies elsewhere, making maintenance progressively harder.

He proposed migrating the frontend to React and Redux to the CTO. At the time React was only beginning to gain traction in Brazil, and the proposal to migrate the whole legacy system was not approved right away. As an alternative, the CTO gave him the challenge of building a new internal application for management: handling B2B client subscriptions, controlling billing and generating payment invoices. He built it from scratch with AdonisJS, React and Redux, taking part from requirements gathering through to implementation, and shipped an MVP in roughly two months. The project was later presented to the company's executives, who received the result very positively, and it served as practical proof that React could work well inside the company.

With the CTO's approval he prepared a more structured proposal for migrating the main application. Since Intelup was still a growing startup, halting product development for months to do a full rewrite was not viable, so he proposed a gradual migration in which React components were rendered inside the existing AngularJS application. New features were built in React while the old screens and components were progressively replaced. The complete migration took about a year. Hiring was part of the argument as well: AngularJS was already deprecated and finding professionals with experience in it was becoming difficult, while React was growing quickly with far more developers available. The migration accelerated the development of new features, opened up a much larger ecosystem of libraries and components, made hiring and expanding the frontend team easier, cut load time on some pages by roughly 5x, and modernised the interface and user experience.

He also built a desktop application with ElectronJS for industrial data collection. Inside the Electron process, a Node.js service handled OPC communication and collected millions of points from industrial equipment. Because many industrial environments had limited or unstable internet, the data could not depend on immediate cloud synchronisation, so he implemented a queue-based process where data was collected locally and scheduled for later synchronisation with InfluxDB once a connection was available.

Deployment was another bottleneck he identified. The platform's frontend, services and databases were installed on-premise, and the engineers responsible had to configure several components by hand. At clients with limited internet the process could take more than three days before the team could even begin customising the platform. He automated the rollout with Docker and built an offline installation process compatible with Windows and Linux, bringing environment setup down to roughly three hours.

The platform's dashboards were initially quite static. He turned them into a more interactive experience with customisable component sizing, responsiveness, dark mode, interactive charts, click-driven actions, and direct interaction with the points and information shown in the charts. To reduce the impact of internet interruptions on users, he also implemented an offline-first architecture using React, Redux, Redux-Saga, Web Workers and queues, so certain operations kept working locally and synchronised afterwards. He built an intelligent alerting system with notifications distributed to both the web application and the mobile app, prepared to operate at scale, and developed the mobile application itself with React Native, reusing roughly 70% of the web application's code against the same API. On the backend and infrastructure side he worked with Python, SQLAlchemy, Pandas, PostgreSQL and InfluxDB, with the main application hosted on Amazon EC2.

The last significant project was a benchmarking service between companies in the same segment, generating daily and monthly reports comparing performance indicators across different companies, always with the agreement and consent of the parties involved. The architecture covered cross-company data collection through a microservices-based, event-driven API, along with private and customisable dashboards carrying benchmarking charts with server-side rendering. He was responsible for the authentication and for the anonymisation strategy: to stop one company identifying another, each company received a random, unrecognisable key that stayed static within the analysed period — allowing the same company to be tracked through that context — but was changed when certain parameters shifted, such as the month under analysis. That preserved the consistency the benchmarking needed without revealing any company's identity, and kept the privacy requirements of the LGPD intact.

**Key outcomes:**

- The AngularJS frontend piled up sync bugs from heavy two-way data binding, on an already deprecated technology; I proposed and led the gradual migration to React, rendering components inside the legacy app, finished in about a year and leaving some pages up to 5x faster.
- The migration proposal was not approved right away; I built an internal B2B subscription and billing application from scratch in AdonisJS, React and Redux, with an MVP in about two months, which served as proof and unblocked the migration of the main app.
- The on-premise rollout required manual setup and took over three days at clients with limited internet; I automated it with Docker and an offline installer for Windows and Linux, bringing the environment up in about three hours.
- Industrial environments with unstable connectivity could not depend on immediate syncing; I built an Electron application with a Node.js OPC service that collects millions of points locally and queues them to sync into InfluxDB once a connection is available.
- Companies wanted to compare indicators without exposing their identity; I implemented the authentication and anonymisation strategy of a cross-company benchmarking service, with random keys kept stable within the analysed period and rotated when the window changes, preserving report consistency and LGPD requirements.

## Projects

### Tradição Monástica

E-commerce with payments, shipping and WhatsApp built in
**Stack:** next.js, node.js, bun, tailwind, shadcn, vitest, playwright
**URL:** https://tradicaomonastica.com.br/

A store built from scratch, including the checkout and every integration it needs: Mercado Pago payments with Pix, bank slip and card, shipping quotes and labels through Melhor Envio, Braspress and the Brasil API, and support wired into WhatsApp. It runs on Next.js over Bun, with Vitest and Playwright covering the purchase flow.

### Encontra Missa

Finds the nearest mass at the time you have free
**Stack:** next.js, node.js, google maps, tailwind, shadcn
**URL:** https://encontra-missa.vercel.app/

A utility that matches the visitor's location against celebration times to point at the nearest church for the time they want, using the Google Maps API for lookup and distance.

### Sheet Music Maker

Percussion notation for children's music education
**Stack:** react, vite, vitest, tailwind, shadcn
**URL:** https://criador-partitura.vercel.app/

A simplified percussion notation editor for children's teaching: notes and rests drop into a drum-kit grid, with tempo and more than one voice, without the complexity of a professional editor.

### Tibia Sprite Tools

Desktop app for importing sprites and configuring Tibia items
**Stack:** tauri, react, node.js, python, tailwind, shadcn

A desktop tool sold to admins of unofficial Tibia servers: it imports sprites and configures in-game items. The interface is React inside a Tauri app, with the heavy image processing handled in Python.

### Pokémon Classifier

A model ensemble that recognises PokéTibia sprites
**Stack:** python, transformers, hugging face
**URL:** https://github.com/lucasdu4rte/pokemon-classifier

A computer vision project: an ensemble of models trained to recognise PokéTibia sprites, built with Transformers and the Hugging Face ecosystem.

### Video Playlist Player

Watch video folders as a playlist, keeping your progress
**Stack:** swift
**URL:** https://github.com/lucasdu4rte/video-playlist-player

A native macOS app that treats a folder of videos as a playlist and keeps track of what you have already watched — made for following courses, series or any collection organised in folders.

## Technology experience

| Technology | Years of experience |
| --- | --- |
| react | 9.1 |
| node.js | 9.1 |
| aws | 9.1 |
| jest | 9.1 |
| next.js | 8.7 |
| sqlite | 7.1 |
| websockets | 7.1 |
| gcp | 6.1 |
| redux | 6.1 |
| vitest | 6.1 |
| typescript | 5.8 |
| nest.js | 4.3 |
| azure | 4.1 |
| react native | 4.1 |
| python | 4.0 |
| machine learning | 3.6 |
| graphql | 3.1 |
| playwright | 3.1 |
| adonisjs | 3.0 |
| angularjs | 3.0 |
| docker | 3.0 |
| electron | 3.0 |
| influxdb | 3.0 |
| opc | 3.0 |
| pandas | 3.0 |
| postgresql | 3.0 |
| sqlalchemy | 3.0 |
| web workers | 3.0 |
| jenkins | 2.1 |
| module federation | 2.1 |
| mongodb | 2.1 |
| twilio sdk | 2.1 |
| webpack | 2.1 |
| zoom sdk | 2.1 |
| firebase | 1.5 |
| github actions | 1.3 |
| mcp | 1.3 |
| n8n | 1.3 |
| rust | 1.1 |
| swift | 1.1 |
| .net core | 1.0 |
| aws cognito | 1.0 |
| lighthouse | 1.0 |
| redis | 1.0 |
| xmpp | 0.5 |

## Writing

- [React 19.3: the features you'll actually use](https://oduarte.dev/blog/react-19-3) — 2026-09-14 — View Transitions and Fragment Refs leave experimental, plus use(browser()), Trusted Types, and Context rendered directly in Server Components. A code example for each
- [Performance Tips for Next.js Applications](https://oduarte.dev/blog/nextjs-performance-tips) — 2024-01-20 — A practical guide to making Next.js apps fast: measuring first, shipping less JavaScript, killing waterfalls, streaming, caching, and keeping it from regressing
- [Welcome to My Blog](https://oduarte.dev/blog/welcome-to-my-blog) — 2024-01-15 — First post on my blog - learn about what I'll be sharing here