DEV Community

Cover image for One Portfolio, Two Audiences
Dalligton Augusto
Dalligton Augusto

Posted on

One Portfolio, Two Audiences

New Year, New You Portfolio Challenge Submission

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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."

Top comments (0)