Why I stopped making "landing pages" and turned my portfolio into an OS

Alex Lanção — Sat, 29 Aug 2026 12:35:26 +0000

If you are a Front-end or Full Stack developer, you’ve probably been through this: you build a great-looking portfolio, put up a picture of yourself, list your skills with progress bars (which don't really mean much), and add links to your GitHub.

The problem with this standard "institutional page" model is that it only tells people what you know how to do. I wanted a portfolio that proved what I know how to do. The famous "Show, don't tell."

It was with this mindset that I decided to step away from the obvious and rebuild my portfolio from scratch. The goal wasn't just to have a showcase for recruiters, but to force myself to face real architectural challenges that I encounter in my day-to-day work.

The idea: An interactive portfolio (macOS Replica)

I decided to create an ecosystem running straight in the browser, simulating an operating system.

Project link: https://www.alexlan.com.br/
Repository: https://github.com/lancao2/portfolio-alexlan.com

More than the aesthetics, what motivated me were the technical "pain points" that a project like this brings. Developing a highly interactive portfolio simulates complex engineering problems. I've highlighted here some of the main challenges I faced and how I solved them:
The hell of cascading re-renders (Drag & Z-Index)

The window manager was, by far, the trickiest part. How do you handle dozens of windows that need focus, dynamic z-index, and simultaneous dragging without killing React with re-renders?

The solution was to divide responsibilities. The orchestration logic (which app is open, which has focus) I kept in a traditional Context API. But the physics of dragging (the X/Y coordinates) was isolated. I delegated the movement to Framer Motion, which mutates the CSS transform directly in the DOM (requestAnimationFrame).

In other words: I can drag a window across the screen at a constant 60fps without React even knowing about it. The global state is only updated at the exact moment of the click, just to change the window's priority.

Real functionality vs. "Pretty Mockup"

I didn't want it to be just a visual toy; it needed to have utility.

Integrated Scheduler: Right in the Menu Bar (the top clock), I embedded my Google Calendar schedule. Anyone can open it and book a 30-minute chat with me right there, friction-free.
Messaging App: A functional chat connected to a MySQL database (hosted on Aiven via Prisma ORM) where it's possible to send me a direct message through the "system".
Hybrid Mobile First: A desktop interface doesn't fit on a mobile screen. Instead of blocking mobile users, the system restructures the layout (the "Finder" turns into a native bottom tab navigation).

Why I recommend making out-of-the-box portfolios

Institutional projects are easy. They will rarely test your limits on global state management, performance optimization, advanced componentization, or DOM interaction.

When you try to build something non-standard (a window system, a simple game, an interactive data visualization tool), you run into architectural problems that large companies face all the time. You train for the market while building your own personal brand.

I invite you all to test the application out and, most importantly, take a look at the source code! I'd love to hear your thoughts on the architecture I used and how you would solve the window management problem.

DEV Community: Alex Lanção

Why I stopped making "landing pages" and turned my portfolio into an OS

Real functionality vs. "Pretty Mockup"

Why I recommend making out-of-the-box portfolios