DEV Community

Cover image for Building a System Thinker's Portfolio
Sahil Sharma
Sahil Sharma

Posted on

Building a System Thinker's Portfolio

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

“That which does not kill us makes us stronger.”

Three months ago, I was at a meetup showing my portfolio to a senior engineer. He scrolled through, nodded, then casually asked: "Why MobileNet over ResNet here?"

I just... froze. Not because I didn't know—I had a whole mental essay about efficiency vs accuracy. But my portfolio? Just said "EcoVision: A smart waste classification app" with a screenshot and some tech badges.
That's when it clicked: I was showing what I built, not how I think.

I'm Sahil, joining IBM as a Software Engineer soon. I care a lot about systems thinking—like, probably too much. My friends joke that I optimize things that don't need optimizing yet. But that's just how my brain works. I don't just want things to work. I want them to work right.

But how do you show that in a portfolio? How do you prove you think about CAP theorem and scaling bottlenecks when all you've got is a project card?
That "but why?" question stuck with me. This portfolio answers that "but why?" Plus all the failures and late-night debugging sessions where I learned way more than any course taught me.

Portfolio

🔗 Live Portfolio: https://portfolio-frontend-980859154686.us-central1.run.app/
🔗 Direct Cloud Run Origin Embed:

(This portfolio is deployed to Google Cloud Run using the required challenge label: --labels dev-tutorial=devnewyear2026)

How I Built It

The Problem I Was Solving

Here's the thing: I spent months building a data cleaning pipeline. Then at a career fair, I had 45 seconds to explain it before the recruiter moved on. Or I'd show it to another engineer who wanted to know about my strategy, and my description just said "handles missing values." Yeah, super helpful.
I needed the portfolio to talk differently depending on who's looking. Recruiters don't care about my database indexes. Architects don't care about my button animations.

But there was another problem I kept ignoring: updating the damn thing. Every portfolio I'd built before required me to:

Open VS Code
Edit a JSON file or React component
Commit changes
Push to GitHub
Wait for deployment
Hope I didn't break anything

This drove me insane. I'd avoid updating my portfolio because the friction was too high. And a stale portfolio is worse than no portfolio.

So I made a decision: I'm building a proper backend with an admin panel.

The Admin Panel

This is where the systems thinking actually kicked in. I asked myself: "What would make maintaining this portfolio actually sustainable?"
The answer wasn't "make prettier project cards." It was "remove every possible friction point from updating content."
I built a full admin dashboard with:

  1. Firebase Authentication for secure login
  2. Full CRUD operations for everything (Projects, Writings, Systems, Vault, Arena)
  3. Markdown editor
  4. Image URL management (no more hardcoding paths)
  5. Draft/Published status (work on stuff without breaking production)

And since this is the admin panel, it's not accessable to anyone except me

The Gemini Thing

First attempt: I wrote three versions of each project description. Recruiter. Engineer. Architect.
I finished one project and gave up. Keeping three descriptions in sync is actual hell.
Then I had this probably-stupid idea: what if AI just... does this? But not the generic "summarize this" that everyone's doing now. I wanted it to actually get into character.
Here's what I built:

prompts = {
    "recruiter": """
    You're in a career fair. You have 30 seconds to explain 
    why this project matters before they walk away.
    Focus on impact and outcomes, not implementation.
    """,

    "engineer": """
    You're doing a technical deep-dive with a peer.
    Walk through the architecture, design patterns, and 
    interesting problems you solved. They want details.
    """,

    "architect": """
    You're being interviewed by a principal engineer.
    They want to know about scalability, trade-offs,
    failure modes, and what you'd do differently.
    Be honest about limitations.
    """
}
Enter fullscreen mode Exit fullscreen mode

And it actually works! It's basically three versions of me, each talking to their audience. Without me maintaining three separate docs.

The Tech Stack (Why I Actually Picked These)

FastAPI + Firestore:
I wanted to ship fast. Not performance-fast (though it is), but iteration-fast. No running migrations at 2 AM. Been burned by schema changes way too many times.
React + Vite:
CRA died on my machine. Three times. Vite starts in 0.4 seconds. That's the whole reason.
Tailwind:
Hot take: I don't enjoy writing CSS. I like building features. Tailwind got me a decent UI in way less time.
Cloud Run:
Didn't want to manage servers. Write code, deploy, done. Auto-scales. Zero config. Never SSH into anything. And most importantly, low cost.
Mermaid:
I was tired of drawing diagrams in Figma, exporting PNGs, and having them outdated instantly. Mermaid? Write markdown, get diagrams. Architecture changes? Change the code. Done.

What I'm Most Proud Of

1. The Honest Parts
Every project has "Failure Points" Like:

AI Dependency Failure:
"Due to API rate limits, invalid key, and downtime, the analysis fails".

Most portfolios only show wins. Mine shows reality. Because knowing where stuff breaks matters more than knowing where it works.

2. The AI Thing Actually Helps
I've seen "AI-powered portfolios" that are just ChatGPT with no context. Mine sends actual architecture details, tech choices, and failure points to Gemini.
So the explanations are actually useful. It analyzes the system and explains trade-offs. Sometimes catches things I didn't mention.

3. The "Systems" Page
This is my favorite. It's not a tech list; it's why I use these tools and where they fail.
Like:

Firestore:
What I use it for: Auth, realtime stuff, MVP hosting
Why: Fast prototyping
Where it breaks: Complex queries get annoying

This leads to way better interview conversations.

4. It's Fast
Backend under 100ms
Lazy-loaded components
Optimized images
Rate limiting (after I accidentally DDoS'd myself testing)

5. I Actually Use The Admin Panel
This isn't just for show. I update my portfolio regularly now because it's actually easy. The friction is gone. That's good system design—optimizing for long-term use, not just initial build.

Performance is a feature.

Check It Out

Things to try:

Projects → Any project → "Architect (Deep Dive)"
Watch AI analyze system design
Systems → My honest takes on tools
(VS Code lags on big repos—I said it)
Vault → Knowledge stuff
CAP Theorem, SOLID, Circuit Breakers
Project Pages → HLD/LLD sections
Mermaid renders from markdown

Real Talk

A year ago, I was watching tutorials trying to understand async/await. Now I built this whole thing running on Google Cloud. Difference wasn't talent. Just building stuff, breaking it, fixing it, repeat.

If you're thinking "I can't build this"—I get it. Felt that way a year ago. But you don't get ready by waiting. You get ready by building.
Start small. Solve a real problem you have. Make it work. Make it better. Think about trade-offs. Write down where it breaks.
And next time someone asks "but why?"—you'll have an answer that's not "the tutorial said so."

Built at 2 AM. Lots of coffee. Gemini helped. Debugging never ends.

Top comments (0)