One Portfolio, Two Audiences

Dalligton Augusto — Sun, 01 Feb 2026 22:08:04 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I’m a Fullstack JavaScript Developer from Brazil, who cares about how products are built and communicated, not just how they look.

This portfolio was designed as a product experiment: one layout, two audiences. Recruiters see outcomes and clarity, while developers see decisions, trade-offs, and work-in-progress. My goal was to represent how I actually work, not to present a perfectly polished narrative.

Portfolio

https://portfolio-concurso-833741946840.us-central1.run.app/

How I Built It

Design & Product Thinking

The project started with Google Studio, where I defined the initial layout, content hierarchy, and the idea of supporting two audiences without duplicating the UI.

Instead of aiming for a final visual design, I focused on structure, clarity, and extensibility.

Development, Refactoring & Tooling

The first implementation was built with React.

As the project grew, the architecture no longer matched the product goals. At that point, I used Google Antigravity (with gemini 3) as my primary IDE and refactoring assistant to:

analyze architectural issues
refactor components and routing
migrate the project to Astro with React islands
improve performance and content separation

Antigravity helped me move faster during refactoring while keeping changes controlled and intentional — similar to how I’d use an AI-assisted IDE in a real production environment.

What I'm Most Proud Of

1. One Portfolio, Two Audiences

This portfolio was intentionally designed with two modes: one for developers and one for recruiters — without changing the layout.

Recruiter mode focuses on outcomes, responsibilities, and clarity.
Dev mode exposes decisions, experiments, trade-offs, and even unfinished parts.

Same product. Same structure.
Different conversations.

What I’m proud of here is not a feature, but the intentional separation of communication without fragmenting the experience.

Dev Mode Is Allowed to Be Honest (and a Bit Playful)

In Dev Mode, I allowed myself to break some portfolio conventions:

playful micro-copy
extra technical details
visual hints that only developers notice

Some sections are incomplete. Some ideas are half-implemented.

That’s deliberate.

I wanted this mode to feel closer to exploring a real codebase than browsing a marketing site — because that’s how software actually looks while it’s being built.

Showing Work-in-Progress Instead of Hiding It

I didn’t finish everything — and I chose not to hide that.

Instead of polishing every edge, I prioritized:

architectural clarity
performance foundations
content structure

This portfolio represents a snapshot of an evolving product, not a “final version”.
I believe showing what I chose not to finish says more about my priorities than pretending everything is done.

A Real Technical Journey (Not a Straight Line)

The implementation followed a very real development path:

I started with Google Studio to define the initial layout and content structure
Moved into Antigravity, where I fixed early UX issues and implemented missing details
As complexity grew, the initial React setup stopped making sense
I refactored the project to Astro with React islands, improving:
- performance
- content isolation
- long-term maintainability

That refactor cost time, but it aligned the architecture with the product goals.

Thinking in Products, Not Pages

What matters most to me is that this portfolio behaves like a product, not a static page.

Every decision — layout, copy, performance, unfinished parts — reflects how I:

reason about trade-offs
prioritize impact over polish
design for different audiences

If someone finishes this portfolio thinking
“I understand how this person thinks”,
then it worked.

What I learned building this:

A portfolio doesn’t need to be perfect — it needs to be intentional.

Treating it like a real product forced me to make real decisions: what to build, what to delay, what to refactor, and what to leave explicit as unfinished.

If judges remember one thing, I hope it’s this:
"This developer thinks in systems, not just screens."