The problem

The old site was a single WordPress page built with Elementor. Before writing a single line, I measured the published home page and listed what got in the way of visitors.

• No menu. There was no navigation. The only way to reach a section was to scroll through the whole page.
• Weight with no payoff. There were 26 scripts and 11 stylesheets for a single page.
• Accessibility. 11 of the 13 images had no alt text, including the logo, which was also a link and therefore had no name for screen readers.
• Search and sharing. There was no meta description. The summary used when sharing mixed button text with the menu and had a typo.
• Duplicated content in the code. The three value blocks were built twice, one version for each screen size, which doubles the work on every change. And the Coleção Criativa section had no heading, which broke the hierarchy.
• Ambiguous links. Three different links carried the same text, "Conheça o nosso catálogo completo" (see our full catalog).
• Contact. Phone, e-mail and Instagram were written without links. The WhatsApp number on the main button was different from the one in the footer.
• Catalog. There was no search, no filter and no way to look inside a material before ordering it.
• Company info. There was no address, privacy policy or terms of use.

Measured on the published home page on November 2, 2026.

The solution

I reorganized the site into pages with a clear purpose and turned the catalog into a showcase, so the material could be presented better.

• Seven pages with a menu. Home with tabs per project, About, Educational Solutions, a page for each project, Partners, Contact us and a 404 page. Old addresses redirect to the new ones.
• A catalog of 82 materials. Books, manuals, games and kits, searchable by title, grade, subject or author, with a filter by project.
• Book-style preview. Page turning, thumbnails, zoom, full screen and search inside the text. The text comes from Portuguese OCR, generated in batch by Python tools.
• Protected previews. Pages only open in the site's reader, with temporary access, usage limits and a watermark burned into the image.
• Coverage map. A map of Brazil showing presence by state, fed by the database.
• Contact that arrives. A form validated on the server, with a submission limit, and every channel clickable.
• No number without proof. Metrics not yet confirmed show up as "data under validation", and testimonials only go in when authorized.

Architecture

I used a dedicated server instead of a static site for two reasons: previews need access control, and the catalog needs to change without touching the code. Updating the catalog does not erase contacts or testimonials.

The MVP was validated in a test environment. Once finished, the goal was to move everything to CEI's VPS, set up in an organized way and maintained by the company's IT team.

How I tested it

I used Opus 5.5 to speed up the workflow, not to decide for me: it helped me put together the verification scripts, and I checked every result. Lighthouse showed where the real cost was, such as images without set dimensions, contrast and unused JavaScript, and I went straight to those points instead of optimizing blindly.

Every critical flow became a test case with an expected result: searching the catalog, opening a preview, turning a page, searching inside the book, submitting the form and trying to open a preview outside the reader. I ran all of them at widths from small phones to wide monitors, to keep the layout responsive on as many devices as possible, before releasing it for internal validation.

Results

Same criteria on both home pages, on November 2, 2026.

What I would do differently

In the final version, I would move the institutional pages to Astro and keep React only where there is interaction: the catalog, the preview reader and the form. Almost the whole site is content that rarely changes, so visitors would get ready-made HTML instead of waiting for JavaScript to build the page. That matters most on phones, where much of the audience comes from.

The preview server and the database would stay the same. The change only touches the layer visitors see, without redoing what has already been validated.

Context

Assessments are given by the municipalities. Students answer on answer sheets with a QR code, which are read by a phone camera and graded by the platform.

Reaver was born as a complement to this process, for the step that comes after grading: understanding the results.

The recordings on this page show the real app, running with a fictitious municipality, schools and students.

The problem

The data came out scattered and confusing. It did not point straight to the mistake, the reason, how or when.

Putting that reading together by hand took hours and, often, days of work from another department, which depended on it to move on with its own process.

Why Python

Python fits almost anything, accepts almost anything, is easy to read and is great for automation. The team already used the language, which removed friction from adoption and maintenance.

For the interface, PyWebView opens a window with HTML and CSS using the browser the system already has. The app stays light, runs without a server and does not ship a whole browser with it, as Electron would.

How it works

The hardest challenge was the first step: fetching information that would normally only come out in an exported file, such as CSV or JSON, and organizing it without that file.

How it was validated

I led the project. The QA, development and testing team validated every part. Then Reaver was validated by the people who actually use the report data every day.

It took two rounds of fixes to reach the final product.

Results

The numbers are measured automatically by the tool itself. The change went beyond time: it improved the logistics of a whole internal process in another department.

It started as a simple job, built to clear a bottleneck. Then it was improved and became a project integrated into Hub Rever. Reaver did not stop there: its potential was noticed to the point that it became an essential part of the Hub.

What I would do differently

Looking back more calmly, I would have invested more time in the visuals. The deadline was short and the main goal was achieved, with validation from the technical team and from the people who use the reports, but the look did not turn out 100% the way I wanted.

In internal tools, visuals often take a back seat to the deadline. Even so, it is the first thing I would improve in a next version.

The problem

More than 20 conversations at the same time, almost all with the same questions.

Everything went through a shared number, logged in on several devices. Conversations got lost, priorities were forgotten and, worst of all, the person on the other side was left without a solution to their problem.

The hub was designed to tackle exactly that: leave no one without a solution.

How it works

When a question falls outside the knowledge base or the case needs a person, the bot hands off the conversation with its context, and the agent does not have to ask everything again.

Decisions

I chose n8n because it is practical, fast and visual. With the help of a language model, you can go from a sketch to a working flow quickly, and anyone on the team understands what each step does just by looking.

The hard part

Nothing broke. The hard part was structuring everything end to end. There are many variables and many types of requests, and I had to map absolutely all of them before writing the first answer.

How I tested it

I tested with the people who handle customers every day. I found out where the information comes from, in what format it arrives and what the team answers in each situation. From that, I wrote the correct answers and built the knowledge base the bot looks up.

Each type of request became a test case with a question and an expected answer, including the cases the bot must not answer and needs to hand off. The hub only went live when it passed on both sides.

Results

What it is

An integrated learning system focused on learning recovery, reading fluency and better results in external assessments.

Each person in the network has their own profile, with its own permissions: the education department, school management, coordinators, teachers and students.

The recording at the top is the platform's front door, with a simulated login and fictitious credentials. What comes after the login cannot be shown.

How it works

Beyond assessments, the platform brings together reading fluency records, an HTML digital book with accessibility features, games and videos.

What it solves

It takes guesswork out of teaching decisions. The education department sees the whole network, the school compares classes and the teacher sees which skills each student got stuck on, in time to act within the same school year.

My role

I am part of the team that ensures the quality of each release. Nothing moves to the next phase without our validation: test cases, defect reports, retesting and sign-off with the people who will use it.

Day to day, I support the networks that use the platform, with document checks, data processing and issue analysis. That routine is what gave birth to Reaver.

How I approach quality

I cannot show internal screens, so I show the shape of the work. The examples below are sanitized, with demo data and fictitious numbers, but they follow the kind of testing we do every day.

Tracking board for one release, with generic feature names and sample counts.

A release up close

Every release from the development team follows the same path before it reaches the networks. What changes in each one stays within the team; what can be shown is the process.

1. Reading the releaseUnderstanding what changed, for whom and what may have been affected along the way.
2. Test cases by profileEach change becomes cases for the education department, management, coordination and teachers, including what each one must not see.
3. Running on web and mobileThe same cases run on a computer and on different devices, always with demo data.
4. Defects and fixesWhatever fails becomes a report with steps, expected result, actual result and evidence.
5. RetestThe fix is tested again, together with the neighboring screens, so nothing breaks along the way.
6. Sign-offOnly what passed on both sides moves on: with the technical team and with the people who will use it every day.

Profiles and permissions

Each profile sees a different part of the platform. Testing access also means testing what each one cannot see or change.

"Out" marks what is not part of that profile's test.

In the school networks

Municipalities telling, on their own channels, how Projeto Rever reached their schools.

What it is

A deskbot built with AtomS3 and Echo Base, inspired by Capri, the construct from the Cyberpunk universe. She became my partner for work, development, studying, reminders and conversation.

She has 21 facial expressions, her mouth follows the sound of her speech and the screen turns off on its own when she goes quiet.

21 expressions

Every AI response arrives with an emotion, and the firmware turns that emotion into a face: how open and tilted the eyes are, iris size, gaze direction, mouth shape and the movement of the whole face. The face below runs the same code as the device, ported to the browser, and goes through all 21 expressions on its own.

Listen to Capri

Real recordings, with the voice coming out of the device itself. She speaks Portuguese: the questions were mine and stay as text, while the audio is her answer, cleaned up to sound clear, and each one has an English transcript.

Why it exists

No copy and paste, no attached files. Just: "Capri, help me with this."

I wanted an assistant that could help me through speech alone. I could have picked one of the thousands of ideas already out there, but where would the challenge be? Where would the fun be?

And why Capri? Because I love the Cyberpunk universe, and there is nothing better than an AI that "is not an AI", with a strong personality, to live on my desk.

Constraints

• Zero cost. No paid API, subscription or rented server.
• Privacy, as far as possible. Sensitive folders blocked, nothing personal in the repository and credentials encrypted for my Windows user.
• Compound requests. "Open YouTube, set the volume to 10 and go full screen" has to become three actions, in the right order.
• No LLM running on the PC. No heavy model kept in memory. Tools only run when they are called.
• Awareness of the world and the workspace. Understanding the context: the active window, the open document, what is on screen and what was copied.

How I solved it

The core exposes the PC's actions as MCP tools, and the AI decides when to use them. A name index in SQLite, updated by Windows events, makes file search instant. A supervisor keeps everything running and restarts it without duplicating processes.

Security came along with it: per-folder permissions, local confirmation for high-impact actions and reversible operations with a backup copy. Text read from a page, the screen, a document or the clipboard never becomes a command.

The PC app

So I would not depend on a terminal day to day, I built Project Capricorn, a Windows app that shows Capri's status, starts, stops and restarts her, adjusts her spontaneous messages, monitors the device over USB and lists everything she has done.

The look is mine from start to finish: the logo, the neon green and magenta palette, the interface and the glitch intro, designed to feel like a piece of the same universe as Capri.

• Truly lightweight. In the system tray, it uses 25 to 40 MB of RAM. The window only exists while it is open and gives the memory back when closed.
• A 3D model in pure CSS. The 11 devices on the compatibility list become models that spin on the GPU and stop when the window loses focus.
• Updates without a console. The app checks GitHub, lists what changed, updates in the background and reopens on the new version. The same path rolls back to the previous version.
• Nothing comes from the internet. Fonts and images ship with the app.

Challenge

Every name changes with the occasion. The same window, button or folder shows up with different names in different situations, and Capri has to find the right target in all of them. The solution was to search by equivalence, without depending on accents, letter case or the exact text, and to cover every variation in the tests.

Capri keeps evolving, and the idea is to take her as far as possible. Today's biggest challenge is her voice. She speaks with the voice of the official Xiaozhi server, which provides speech recognition, the AI model and speech synthesis for free, but does not let you change that voice. Getting close to the original voice means taking that step out of the official server and building my own: speech becomes text, the answer is generated and a custom voice is synthesized, all outside of it.

In practice, it means changing the whole architecture without giving up what she already has: zero cost, fast responses and no heavy model running on the PC.

How I tested it

I built a lab in which a model plays the role of Xiaozhi's brain, with the same persona and the same tools. Each tool is simulated, the result goes back to the model and compound requests run to the end. Finally, the calls are compared with what was expected and each area gets a score. The scenario phrases are made up, so nothing personal goes into the test.

I also separate the levels of evidence, because they are not the same thing: delivered, installed, tested on the PC and tested by voice on the device. A change only counts as done at the last one.