Where the best cities share a desk.

Next.js · TypeScript · React · Tailwind CSS · dark28.pt ↗

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 · bylx.dev ↗

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.

E-commerce · Stripe · MB Way · Hostinger · konochan.pt ↗

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 · lupa.road ↗

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.

Google Apps Script · Google Workspace · Automation

The question

A 40+ person team at Accenture was losing hours every week to repetitive Google Workspace workflows — manual reporting, copy-paste pipelines, spreadsheet drudgery. No budget line, no IT ticket. What could one person automate from inside?

What I built

A set of Google Apps Script automations and lightweight internal tools, deployed to the whole team and used in production daily.

• Automated reporting flows that replaced manual spreadsheet work
• Dashboards for team visibility without leaving Workspace
• Lightweight internal tools shaped around how the team already worked

Technical decisions

Apps Script, deliberately — it lives where the work already happens. Zero install, zero procurement, corporate-compliant by default.

Scripts as products — permissions, error handling, and documentation, because a tool 40 people depend on can't behave like a weekend script.

What I learned

Automation adoption is a UX problem: the hard part isn't the code, it's making a tool people trust enough to change their routine for. Corporate code stays private — the process is what transfers.