Kallas Lima

Full-stack product engineering

I usually want context before I start changing a system. I want to understand who uses it, how the current behavior works, what the business is trying to change, and where the proposed solution came from.

I'm comfortable following a problem across backend services, web and mobile applications, databases and infrastructure. At Olly Olly, that meant building the foundations of a new software platform while developing the product itself. At CookUnity, it meant moving between customer applications and the systems used to operate Smart Fridges.

I stay involved after release as well. My work has included incident investigation, debugging, code review, release preparation, automated testing and monitoring.

Languages, education and international work

I'm based in Belo Horizonte, Brazil, in Latin America. I speak Portuguese, English, Spanish and French fluently, and Italian and German at an intermediate level.

My work has included remote teams and colleagues across the US, Latin America and Europe. Alongside the technical work, that experience has involved discussing requirements, reviewing implementation and coordinating delivery across different locations.

I studied Computer Engineering in PUC Minas and technology management and artificial intelligence at ESIEE Paris.

Building Olly Olly's software platform

At Olly Olly, the business was expanding from marketing services into CRM and SaaS. I built the software platform from the ground up and worked with company leadership on what it should become.

My implementation work covered the database, cloud infrastructure and TypeScript backend architecture, along with work in the Flutter application.

I combined that technical work with engineering management. I hired and trained engineers, led a remote team and worked directly with the VP of Engineering and CEOs on product and technology decisions.

I was also the main engineer responsible for production AI features for generating social media content and responding to customer reviews. These were features for business customers using the product. I worked with multiple models and providers across those uses, connecting the AI capabilities to the application's existing workflows.

CookUnity and Smart Fridges

CookUnity's Smart Fridges are physical points of sale stocked with prepared meals. The platform includes customer applications, backend services and tools for the people stocking and operating the fridges.

I led engineering for the platform. I rewrote its mobile application and backend, and built its progressive web app myself. The PWA work included the customer purchasing journey and the backend support it required, so the scope went beyond creating another interface.

Customer and operational software

My work connected customer purchases with inventory movements, delivery operations and the dashboard used to manage the system. I worked on transactions, payment and wallet behavior, customer identity, reporting and operational tooling.

The physical setting matters. The software has to represent what is happening at a fridge, while giving the customer and the people operating it useful information. Investigating a problem can require following behavior through an application, a backend record and an operational process. The symptoms may appear in one place while the cause sits somewhere else.

My work also included rebuilding the delivery application and migrating backend infrastructure to AWS.

Testing, releases and production

I built testing and release infrastructure and worked with the team on production reliability. That included automated tests, CI workflows, preview environments and checks around the software being released. I also contributed to monitoring and incident investigation as part of a broader team effort.

Code review, onboarding and technical direction were part of my responsibilities alongside implementation. I helped engineers understand the repositories, the domain and the delivery process, and reviewed changes across the platform.

I regularly joined discussions with business and operational colleagues. My contribution was usually technical: asking questions, explaining constraints, proposing approaches and sharing delivery updates.

Work beyond those two platforms

Loka: mobile products and distributed engineering

At Loka, I worked as a software engineer and senior software engineer, and led a multinational team of seven people. I worked with colleagues across the US, Latin America and Europe, combining implementation with interviewing, training and team coordination.

Within the Loka Labs incubator, I developed internal software including Real Ticket and Real Ticket Scanner, working with Flutter, React Native and AWS. I helped establish code review, documentation and communication practices.

Devnology: internal financial systems

At Devnology, I designed and developed internal financial systems for 123 Milhas and HotMilhas. My responsibility covered infrastructure, frontend, backend and database architecture. Working across those layers meant I could follow a requirement from the business process through to the data and interface supporting it.

I contributed throughout the development lifecycle and helped interview and train junior developers.

Hinova: maintaining and changing existing software

At Hinova, I worked with PHP, JavaScript and MySQL, refactoring legacy software with the team. The work focused on reducing production bugs and improving performance, readability and maintainability.

Working with other engineers

I've held management and individual contributor roles while remaining involved in technical work. At Olly Olly, I hired and trained engineers while building the platform. At Loka, I helped establish engineering practices. At CookUnity, my responsibilities included technical direction, onboarding and review across several applications and services.

When helping someone join a team, I want them to understand the product and the reasons behind the system's structure. Access to repositories is a starting point. They also need context about the users, the important workflows, how changes are reviewed and how the software reaches production.

In code review, I care about why an approach was chosen as much as what changed. That context often exposes assumptions worth checking before the code reaches production.

I've trained engineers in several of my roles, both as a manager and as an individual contributor. The goal is for someone to understand enough of the system to take responsibility for larger pieces of it without depending on me for every decision.

Full-stack, mobile and AI experience

My technical experience is easiest to describe through the work I've used it for:

• Backend and data: TypeScript and Node.js services, PHP and Symfony, API design, SQL databases, data migrations and integrations. This includes the backend foundations at Olly Olly, financial systems at Devnology and the Smart Fridges backend.
• Flutter, web and mobile: Flutter and Dart, React, React Native, TypeScript and JavaScript. I've worked on customer applications, operational dashboards, mobile rewrites and a progressive web app.
• Cloud and delivery: AWS, CI/CD, automated tests, preview environments and release workflows. My work has included defining infrastructure, advising other teams and changing how software is validated and released.
• AI in products: production features using multiple models and providers, plus experiments with how AI workflows fit into an application's architecture and user experience.

How I use coding agents

Coding agents are part of my daily work. I use them for research, implementation, tests, review, debugging and documentation. I often have several agents working in parallel while I concentrate on the decisions that need my attention.

The context I give an agent matters. A useful assignment includes the intended outcome, the relevant systems, constraints, supporting material and a way to establish whether the work is complete. I review the proposed approach and the result, question assumptions and redirect the work when it misses the point.

I remain responsible for what is built and what ships. I want evidence that the result works in its intended setting, including the user flow when the change affects one. A successful command or a passing test can answer a specific question; I still need to understand what it establishes about the actual product.

A public project: Creative AI Workflow Lab

Creative AI Workflow Lab ↗ is a local prototype of an AI-assisted design workflow. A Figma plugin connects to a backend for copy, localization and image workflows, with a browser interface for exercising the same flow outside Figma.

The project explores model orchestration, policy, explicit review and application of results, usage records and verification. Model and image outputs use deterministic fixtures rather than live generation. The repository includes the prototype, architecture notes, trade-offs, a delivery plan and executable verification scripts.

Find me online

LinkedIn ↗ · GitHub ↗

Finding a direction

The first concepts were too plain. I wanted more color, more technology and something worth exploring. I tried several directions, including a pixel world and a portable computer, before settling on a spaceship cockpit.

The early spaceship images went too far in the other direction. They suggested a large game environment that would be difficult to build and distract from the writing. The useful idea was smaller: a cockpit, a view into space and a set of displays where the content stays readable.

From generated images to working materials

AI image generation helped me compare designs before committing to an implementation. I reacted to the results, chose details and rejected others: brighter lights, a darker cabin, silver display rims and fewer decorative controls that looked clickable.

I instructed the AI to build the cockpit and display models in Blender, then directed revisions to materials, texture, lighting and proportions. Later, I sent screenshots of the working website back through image editing to explore a more detailed finish. The approved result became a reference for changes to the actual site, including generated cabin artwork prepared as runtime assets.

Making the scene behave

The website combines layered space artwork, rendered cabin surfaces and live display geometry. The writing is HTML, so it stays selectable and scrollable as the displays move. The screens, their text, reflections and shadows have to agree about where each display is.

That took repeated corrections. Side hinges appeared to slide. Tilted edges looked jagged. Reflections made the glass look cracked. Shadows needed to follow the console's different heights. I could see when something felt wrong, even when I didn't yet know the graphics term for it.

Travel needed the same attention. Planets drifting sideways felt like objects being rearranged. I changed the movement to suggest approaching them, passing them and pulling away across much larger distances.

Keeping it usable

More detail also brought performance problems. I measured the animation, reused prepared artwork and lighting, and kept expensive rendering for the parts that actually change. Fixed cabin lighting can be baked into an image; a folding display still needs its pose, glass and shadows to respond.

The text remained the priority. I adjusted the reading area, made vertical scrolling read the article, and kept chapter navigation separate. On phones, the side displays disappear so the main display and the view outside have enough room.

Working with AI

I directed the project through references, questions, choices and hands-on feedback. The coding agent investigated problems, proposed approaches, generated iterations, implemented changes and checked the result.

The final view is an artist's impression inspired by the Local Group, our neighborhood of galaxies. Positions and distances are compressed for this composition.