Where the best cities share a desk.

• Next.js
• TypeScript
• React
• Tailwind CSS

The question

Lisbon's Tram 28 passes through layers of history that most tourist guides ignore. I kept finding apps that told the same polished story and skipped the uncomfortable parts — the dictatorship, the colonial memory, the religious weight embedded in the architecture. What if a route helped you understand a city instead of just photograph it?

What I built

An editorial web app that transforms the Tram 28 into a self-guided dark tourism experience. Users discover landmarks filtered by historical theme, read narrative context for each stop, and build a personal plan of places to visit and track.

• Editorial homepage with thematic framing
• Landmark discovery by theme (dictatorship, colonialism, religion, death)
• Detail pages with narrative context per stop
• Save landmarks and track visited places
• Route direction toggle and dark/light theme
• Fully responsive, mobile-first

Technical decisions

Next.js (App Router) — editorial content needs good SEO and fast initial load. Server components simplified data fetching and nested layouts.

TypeScript throughout — enforced clear data contracts between components and caught two broken data shapes before they hit the UI.

Tailwind CSS — rapid iteration on a content-heavy interface without fighting specificity. Consistent spacing without thinking about it.

localStorage + custom hooks — one useLocalStorage hook persisted all user state across four features with no backend required.

What I learned

Designing content-first changes the UI. The narrative weight of each stop shaped the information hierarchy — generic card components didn't work because the content resisted being genericised. TypeScript caught real bugs, not theoretical ones. App Router's server/client boundary required rethinking where state lives.

• HTML
• CSS
• Vanilla JS
• PHP

The question

Developer portfolios all look the same: hero, grid, footer. Mine had to prove something instead of claiming it. Could a pixel-art desk — where Rio de Janeiro and Lisbon share a window — carry an entire portfolio, built with nothing but the fundamentals?

What I built

An interactive scene where every object does what it looks like it should: the camera opens the gallery, the phone opens the contact form, the MP3 player opens a working player, the mouse runs from your cursor, and the keyboard lights up as you type.

• Pixel-art parallax hero on a 64×64 grid with layered PNGs
• Object hotspots with sprite-sheet and steps() hover animations
• Custom pixel cursor with sakura-petal trail
• Working MP3 player with a 17-track lo-fi playlist
• PHP contact form with honeypot and graceful non-JS fallback
• Keyboard-accessible case-study modals

Technical decisions

Vanilla ES modules — parallax, cursor, audio, modals and forms are isolated modules with a single init each. There is nothing to hydrate, so a framework would only add weight.

Coordinate-driven scene — layers map pixel-grid references to CSS custom properties; the whole parallax is one rAF listener writing --move-x and --move-y.

CSS partials with explicit import order — tokens → base → cursor → hero → sections → responsive. The design system lives in :root.

steps() everywhere — easing is quantised so motion stays pixel-crisp instead of smoothly un-retro.

What I learned

Constraints are a design system. Refusing frameworks forced clean module boundaries; refusing smooth easing forced intentional animation. And accessibility inside a fully custom scene — focus states, aria labels, a form that works without JS — is where the real engineering happened.

• Agent Skill
• Python (stdlib only)
• Markdown
• MIT

The question

Every freelancer in Portugal asks the same thing in March: is it worth assigning this invoice to my activity? I could not find an answer that started with the arithmetic instead of the portal. Under the regime simplificado the answer is close to binary — expenses only matter once 15% of gross service income passes the automatic deduction — and almost nobody is told that before they start classifying receipts one by one.

What I built

An open-source assistant packaged as an agent skill: it runs inside Claude and any agent that reads the agentskills format, asks two or three questions, and does the threshold maths before it mentions invoices at all. It explains, calculates and recommends — it never submits anything to the Portal das Finanças.

• Works out the year's threshold first and says, in one sentence, whether invoices change anything
• Handles mixed activity (sales, services, other services) and income on top of a salaried job
• Reads the e-Fatura CSV export locally and proposes a classification invoice by invoice
• Shows a preview and asks for confirmation before listing what to click in the portal
• Ends with one next action and the year's deadlines

Technical decisions

The maths before the portal — the whole point is the question nobody answers first. Getting the order right is the product; the parser is the easy half.

Python with no dependencies — parse_efatura.py is stdlib only and reads the CSV on your own machine. Tax data does not leave the computer, and there is nothing to install or trust.

Volatile values in one file — IAS, thresholds and deadlines live in references/valores-anuais.md, apart from the structural rules that do not change every year. Updating for a new tax year is one file, not a hunt.

The human clicks — it is not tax advice, and it does not act. The line between "explains" and "submits" is the safety property; it is written into the skill's inviolable rules, not just the README.

What I learned

Writing software for a rule someone else wrote means reading the primary source: the CIRS articles, not the blog posts about them. And shipping something in public with "tested by one person — her own return" on the label is a different kind of honesty than a portfolio demo, because strangers rely on it.

• PHP 7.4
• Anthropic API
• Stripe
• HMAC

The question

A one-star review lands on a Sunday night. The right reply is not hard to write — thank them, acknowledge the problem briefly, invite them to continue in private, stay under eighty words, never admit liability. It is just that it takes twenty minutes, it comes out the same every time, and the person who runs a restaurant is not a copywriter. So why twenty minutes?

What I built

Paste the review — Google, iFood, TripAdvisor, anywhere — choose one of three tones, and get three replies in about ten seconds. Edit and publish wherever it came from. Five a month for free with no account at all; unlimited on a Pro tier at R$ 29 a month through Stripe. Portuguese and English. The market is Brazil.

• Three options rather than one, because the useful part is choosing
• The rules of the trade live in the prompt: thank, acknowledge, take it offline, under eighty words, never admit liability, never offer compensation the review did not ask for
• The free tier runs in the browser with no signup screen anywhere
• Pro cancels from Stripe’s own portal — no cancellation flow to build, and none to make deliberately hard

Technical decisions

No account on the free tier — what kills a tool like this is the signup screen, not the price. The free path never asks for an email, so the distance between pasting a review and having three replies is one click.

The key never reaches the browser — generation happens server-side. That is also the only reason a quota can exist at all: anything counted in the browser is a suggestion, not a limit.

Pro is a signed token, not a user table — after checkout the server verifies the session with Stripe and issues an HMAC-signed licence with an expiry. No accounts, no passwords, no personal data to protect, nothing to leak. The signature is compared with hash_equals, so a wrong one takes exactly as long to reject as a right one takes to accept.

The free count is client-side on purpose, and the code says so — an abused free call costs about a tenth of a cent, so per-IP hardening was priced and postponed rather than pretended. That reasoning is a comment in the repository, not a secret.

What I learned

It is finished. The payment path runs end to end — checkout, verification, licence, renewal — and it has never taken a single payment, because I never told anyone it existed. Building was the easy half, and it is the half I am good at. The lesson is not about code: from the outside, a product nobody has heard of and a product that does not work look exactly the same.

• E-commerce
• Stripe
• MB Way
• Hostinger

The question

Could I take a brand from zero to real orders — not a portfolio mockup, but a shop with actual customers, payments, and parcels that have to arrive?

What I built

A kawaii and handmade-resin e-commerce brand, built and operated solo: visual identity, product catalogue, checkout, and everything that happens after someone pays.

• Full store setup on Hostinger, from DNS to checkout
• Stripe and MB Way payment integration for the Portuguese market
• WhatsApp integration for order support and customer contact
• Brand identity, product photography, and packaging design
• Inventory, pricing, and customer support operations

Technical decisions

Platform over custom code — the goal was a working shop, not a stack demo. Hostinger shipped the store in weeks instead of months.

Local payment rails — MB Way is how Portugal actually pays online. Supporting it mattered more than any feature.

WhatsApp as CRM — customers already live there; meeting them in their channel beat building one.

What I learned

E-commerce is UX plus logistics — the interface is the easy half. Running the store taught me what "done" means when customers are real. The shop is currently on pause while I focus on development work; the brand, the systems, and the lessons stay.

• WordPress
• UX
• Branding

The question

A Lisbon optical clinic had a website that undersold the business — dated, hard to navigate, and impossible for the owner to update. How do you rebuild trust online for a business whose whole trade is precision?

What I built

A full WordPress rebrand: new visual identity applied to a restructured site, designed so the owner can maintain it without calling a developer.

• Theme customisation aligned with the new brand
• Restructured content and navigation around what customers ask first
• Plugin selection and configuration kept deliberately minimal
• Responsive layout and performance cleanup
• Handover so the client edits content independently

Technical decisions

WordPress, on purpose — the client needs to edit content themselves. The right stack is the one the business can maintain after you leave.

Fewer plugins, fewer problems — every plugin is a future update, a security surface, and a support call. The build stayed lean.

What I learned

Client work is a different discipline: listening before building, designing within the client's capacity, and writing handover docs as carefully as code. The best compliment was silence — the site just works.