Skip to content
fghisi.com.br

· 9 min read

From code to management, and back to code: building amardoar with AI

How an old idea of helping others became a website, and what I learned building it with an AI as a pair programmer.

Where I come from

I started my career writing software. I worked at technology companies in Blumenau and Curitiba, Brazil, and specialized in backend development with Python. Over time, I moved on to building cloud solutions on AWS. For many years, my days were made of code, deploys and problems that only showed up in production.

Today I lead the technology area at PagueVeloz by Serasa, organized in three fronts: product teams, which build acquiring, core banking and back office; Platform Engineering, covering developer experience, security, observability, DevOps/SRE and cloud; and the Data team.

The move from hands-on work to technical leadership changes the kind of problem that fills your head. Lines of code give way to decisions: priorities, architecture, people, deadlines. One thing does not change: in the payments market, I believe speed is the real competitive advantage. Fast decisions, short cycles and technology that removes friction instead of adding process.

This project was partly born from that urge: to build with my own hands again, and to see in practice how AI changes the way we build.

Timeline: backend with Python in Blumenau and Curitiba, cloud solutions on AWS, technical leadership at PagueVeloz, and amardoar Backend with Python Blumenau and Curitiba Cloud solutions AWS Technical leadership PagueVeloz by Serasa amardoar back to code
Figure 1. From backend with Python to the cloud, from the cloud to technical leadership and, with amardoar, back to building.

An idea from many years ago

For a long time I carried an idea: to make the path between people who want to donate and those who care for others easier. Many people want to help but don't know where to start or whom to trust. On the other side, serious institutions do enormous work and get little visibility.

The idea came from something simple: the wish to help others. I strongly believe in doing good to others, no matter who they are, without expecting anything in return. What was missing was turning that wish into something concrete, which would also help other people do the same.

amardoar is that idea leaving the drawing board. Today it brings together charities from the state of Santa Catarina, organized by cause and by city, and takes you straight to each one's official channels. amardoar does not receive money or act as an intermediary: help is arranged directly with the institution. (The amardoar page itself is in Portuguese for now.)

This project is my love for others turned into action.

The name joins the two words of its purpose in Portuguese, amar (to love) and doar (to donate), and so does the logo: a heart split into two halves, one of each color, that only makes sense whole.

Building with an AI as a pair

The whole site, this blog and amardoar, was built in sessions with Claude Code, Anthropic's coding agent that works directly in the repository: it reads the code, runs commands, opens the site in a browser to check the result, and creates branches and pull requests on GitHub.

The most interesting part was not the speed, although it is real. It was the division of roles. I described the intent ("I want something that feels like technology, but minimalist"), the AI explored and brought concrete options, and the decision stayed with me. That is how it went with the logo, with four proposals drawn side by side, with the project's name and with how to measure visits.

Working cycle with the AI Me: intent what and why AI: options explores and proposes Me: decision taste, ethics, priority AI: implements on a new branch AI: verifies build + browser Pull request to develop Me: review merge or adjust Release develop → main
Figure 2. The cycle of each change. Highlighted, the two steps that never left my hands: deciding and reviewing.

I also set working rules, as I would with a team. The main one: every change on a new branch, with a pull request to develop, which then moves on to main. That kept each change small, reviewable and easy to undo. Almost 30 pull requests later, the history tells the site's evolution step by step.

The technical side

A static site with Eleventy

The site is generated by Eleventy, a static site generator in Node.js. Posts are Markdown files; layouts use Nunjucks; interface texts in Portuguese and English live in data files. At build time, everything becomes plain HTML, CSS and JavaScript in _site/, which any host can serve, with no database or application server.

For a personal site, this means fast loading, low cost and almost nothing to attack. amardoar has its own HTML, CSS and JavaScript and is copied as is to /amardoar/, without going through the blog layout.

Architecture: sources, Eleventy build, static site and hosting src/ posts/*.md _includes/ (Nunjucks) _data/ (site, i18n) css/ js/ img/ amardoar/ analytics.njk Eleventy npm run build _site/ Static HTML, CSS and JS CSS/JS with a hash in the URL /amardoar/ copied as is /js/analytics.js (GA4) published on Hostinger
Figure 3. From source code to the published site: everything becomes static files at build time.

A logo that is a terminal line

I asked for something that felt like technology, but minimalist. Out of four proposals, I chose the terminal one: a > prompt followed by fghisi and a blinking cursor.

The technical detail I like most: the "hisi" text is the JetBrains Mono font converted to vector shapes with the Python library fontTools. That way the logo does not depend on loading the font. The >fg symbol was redrawn on the same grid and with the same stroke weight as the font, so the whole logo reads as a single monospaced line. The colors use currentColor, so the logo follows the light or dark theme on its own.

Theme, motion and accessibility

  • Light/dark theme: colors are CSS variables (--bg, --fg…) redefined for dark mode. The "auto" mode follows the system through prefers-color-scheme; a manual choice is stored in localStorage and applied by a script in the <head>, before the first paint, so the screen does not flash.
  • Page transitions: the View Transitions API fades between pages and when switching themes, with the header standing still.
  • Reduced motion: every animation is turned off with prefers-reduced-motion. Anyone who asks the system for less motion sees a static site.

amardoar's animated heart

The top of amardoar is a <canvas> animated from the logo itself. The two halves of the heart are the same SVG paths as the brand, drawn with Path2D. They come in from opposite sides and fit together (amar + doar). Then small hearts, the donations, travel to the center along a quadratic Bézier curve, and the heart pulses slightly as each one arrives.

Path of a donation: a quadratic Bézier curve from the starting point to the heart P0: start P1: control point (shapes the curve) P2: the logo heart B(q) = (1−q)²·P0 + 2(1−q)q·P1 + q²·P2 q = p² (speeds up at the end)
Figure 4. Each donation follows a quadratic Bézier curve. With q = p², it moves slowly at first and speeds up at the end.

This part taught me something. In the first version, the hearts sped up at the beginning (ease-out) and spent almost the whole trip hidden behind the logo: at 61% of the time, they were already 94% of the way there. Inverting the curve to q = p² (ease-in) was enough: they stay visible around the heart and only speed up at the end, as if they were being absorbed. To save battery, an IntersectionObserver pauses the animation when it leaves the screen.

Real data, nothing made up

The prototype started with fictional institutions, with stories, numbers and even sample Pix keys (Pix is Brazil's instant payment system). When switching to the real list of institutions from Santa Catarina, the rule was clear: make up nothing about real institutions. Each card shows only what can be verified: name, city, cause and the link to the official website. Not even the logo is generated: it comes from the institution's own website.

Search ignores accents, so "criancas" finds "Crianças" (Portuguese for "children"). The technique is to normalize the text (normalize("NFD")) and strip diacritics before comparing. Filters consider each institution's main and secondary causes.

When checking the links, two domains turned out not to exist and one site was down. That is the kind of thing that slips through without a verification step.

A real production problem: caching

After the first release, the site looked "broken": the logo misaligned, the header unstyled and no effects. The HTML was new, but the browser was using the old CSS, because the host tells browsers to keep CSS and JS for 7 days.

The classic solution is cache busting: an Eleventy filter computes a hash of each file's content and adds it to the URL.

<link rel="stylesheet" href="/css/style.css?v=9b68ea03df">

When the file changes, the hash changes, and the browser downloads the new version. When it does not change, the cache stays valid.

Measuring while respecting privacy

To find out whether the project interests people, the site uses Google Analytics 4, but only after consent, as Brazil's data protection law (LGPD) recommends. Before "Accept" is clicked on the banner, no Google script is loaded. Besides visits, the site records events that answer concrete questions: which institutions get clicks, which causes and cities are filtered the most, and whether search is used, without sending the typed text.

Consent flow: without acceptance, nothing is measured Visitor Banner accept / decline Accepts: GA4 loads visits + clicks on institutions, filters and search Declines: nothing is measured no Google script is loaded
Figure 5. Measurement only exists after consent. The choice can be changed through the "Cookies" link in the footer.

What I learned

  • AI speeds up execution; direction stays human. Choosing the logo, the name, what to measure and, above all, what not to do (such as making up data about real institutions) were my decisions. It is the same role I play as a manager: giving context and intent, and letting execution flow.
  • Verifying is part of the work, not an extra. The heart hidden behind the logo, the 7-day cache and the broken links only showed up because every change was tested in the browser and checked against the data.
  • Light process works for personal projects too. Small branches and pull requests kept the evolution safe and the history readable, without bureaucracy.
  • Fail fast and fix fast. There were mistakes, such as a commit straight to the main branch and a CSS rule in the wrong place. Each one became a rule or a test. In the end, that is what speed is: short cycles with learning at every turn.

Next steps

Today amardoar is focused on Santa Catarina. If the site shows engagement, and the metrics will tell, the next steps are two:

  • Expand to other states, bringing the same curation to new regions.
  • Open up the possibility of donating through amardoar itself. Today amardoar does not accept payments: all help goes straight to the institution. In the future, it may receive donations on the site and split the payment among institutions, meaning a single donation automatically divided among several causes. That is where the project meets my day-to-day work, since I work precisely with payments technology.

If you know a serious institution that should be there, want to help in some way or just want to talk about the idea, connect with me on LinkedIn.

Visit amardoar →