I Was Building a Portfolio. Then I Made It Salesforce.

1. The Problem With Another Developer Portfolio

I was sitting in front of my monitor, looking at my brand-new portfolio website, and feeling completely detached from it.

On paper, everything looked great. The typography was sharp, the gradients were vibrant, and the cards had sleek glassmorphism blurs with buttery hover micro-interactions. If you glanced at it for three seconds, you would think: nice website.

The problem was that it didn’t belong to me. It belonged to the internet’s collective average of what a modern software portfolio is supposed to look like in 2026.

I had built that initial version the way many developers build things today: with an AI coding partner in my terminal. Within minutes, I went from an empty directory to a functioning multi-section site. The AI generated a standard hero section with a floating badge, a row of circular tech-stack icons, an interactive skills grid, a card-based project carousel, and a contact form with rounded buttons.

It was fast, frictionless, and completely hollow.

I call this phenomenon AI slop. Not because the code was broken or the layout was ugly—visually, it was polished to a high sheen—but because it was utterly devoid of intent. When you ask modern AI models to build a portfolio without giving them an uncompromising vision, they do what statistical machines do: they give you the mathematical mean of every developer website created over the last four years. Dark backgrounds, purple-to-cyan radial glows, floating pills, and interchangeable buzzwords.

I scrolled up and down the page for ten minutes. I changed the copy. I swapped the accent colors. I adjusted the card padding. None of it helped. The site looked like a portfolio built by a developer who had never worked a single day on a real-world enterprise system. It was an aesthetic costume, not an expression of my craft.

2. The Salesforce Question

For the past several years, my professional life has centered around the Salesforce ecosystem.

I work as a Salesforce QA and SDET. My daily reality is not centered around building flashy landing pages; it involves testing complex business workflows, validating automation, writing deterministic end-to-end Playwright suites against enterprise interfaces, interrogating Service Cloud architectures, and making sure mission-critical software doesn't break when users need it most.

I spend hours every day immersed in Salesforce interfaces. I navigate record pages, inspect modal workflows, jump across workspace tabs, configure permissions, and evaluate how information density serves real people trying to get their jobs done.

“Why is my portfolio pretending to be a generic developer website when the Salesforce ecosystem is where I actually spend my working life?”

That was the turning point.

Most developer portfolios try to project an idealized, generic version of software engineering. They hide the specific tools and business environments their creators work in, replacing them with generic tags like #React, #Node, or #FullStack. But enterprise software isn't generic. Salesforce isn't generic. The Salesforce design language—structured, deliberate, information-dense, and built around clarity—has a very distinct personality.

What if, instead of running away from that reality, I leaned directly into it? What if my personal portfolio wasn't just another personal landing page, but an authentic piece of software that felt like Salesforce?

3. What If My Portfolio Felt Like Salesforce?

The moment that idea landed, I knew I had to be careful.

There is a big difference between designing a thoughtful, system-inspired user experience and creating a shallow parody. I didn't want to just slap a blue cloud in the navbar, paste a generic blue hex code across the buttons, and call it a day. That would have been just as superficial as the purple gradients I was trying to escape.

The real challenge was capturing the genuine feeling of interacting with Salesforce:

• The deliberate balance of information density and scannability.
• Workspace-style navigation that prioritizes context over infinite scrolling.
• Records and detail pages that treat work history, case studies, and skills as structured entities rather than plain text blocks.
• Clean separation of metadata, activity timelines, and related items.
• Subtle, purposeful interaction states rather than chaotic, ungrounded animations.

Enterprise software has a specific rhythm. When a support agent or an operations engineer opens a record in Salesforce, they aren't looking for cinematic scroll-jacking or floating 3D spheres. They are looking for context, relationships, and clarity. They want to see where they are, what belongs to what, and what actions they can take next.

I wanted someone familiar with the Salesforce ecosystem to land on my portfolio, pause for a moment, and smile because the visual hierarchy, the layout anatomy, the tab behaviors, and the micro-details felt instantly recognizable.

4. Turning a Portfolio Into an Experience

The first casualty of this new mindset was the traditional single-page portfolio layout.

Almost every developer website follows an identical script:

In that structure, content is flat. Everything is stacked vertically, competing for attention as the user scrolls past. It encourages passive skimming rather than active exploration.

I wanted the portfolio to behave like an application. Instead of forcing visitors down a single linear corridor, I structured the interface around workspaces and records:

• Context is preserved: You don’t lose your place when diving deeper into a project or role.
• Relationships become clear:Skills aren't just isolated bubbles; they are linked to the projects and roles where they were actually applied.
• Navigation feels intentional:Users explore what interests them through tabs, sub-panels, and focused detail views, rather than mindlessly scrolling through sections they don't care about.

It stopped being a digital resume and started feeling like an interactive record of my engineering journey.

5. Salesforce as the CMS

Once the interface began taking shape around the Salesforce user experience, a second realization hit me.

If the front end was designed to look and feel like Salesforce, having static JSON files or a third-party markdown CMS sitting behind it felt like a missed opportunity. The website would only be wearing a Salesforce costume while remaining fundamentally detached from the platform.

Why not connect the loop completely? What if Salesforce itself became the content management engine powering the portfolio?

When I update my career milestones, write new case studies, or modify my profile metadata, I don't touch a headless CMS dashboard or push a commit with edited JSON files. I log into Salesforce.

As a QA engineer working in Salesforce, the best way to prove that I understand how the platform operates under the hood isn't writing a paragraph that says “I know Salesforce.”It's building a fast, highly polished user experience whose very existence depends on Salesforce operating reliably in the background.

6. The AI Iteration Trap

I built this project in close collaboration with AI tools, and that process was both a superpower and a minefield.

On the positive side, AI compressed the feedback loop down to seconds. I could conceive a layout idea, describe the structural hierarchy, and see a prototype render immediately. When I wanted to test how a specific workspace panel handled mobile viewports or how an information badge responded to high-density layouts, I didn't have to spend two hours wiring boilerplate styles before evaluating the idea.

But that speed created a dangerous side effect: feature accumulation without cohesion.

When iteration costs nothing, your brain naturally stops filtering out bad ideas. Every time the AI rendered a screen, it would suggest three additional widgets:

• “Should we add a dynamic activity feed here?”
• “What about a floating quick-action drawer?”
• “We could add an interactive analytics graph to this corner!”

Because saying “yes” took zero effort, the website quickly started turning into a visual circus. In my early iterations, I had cards competing with sidebars, pills competing with badges, and miniature dashboard widgets cluttering every available pixel.

I had to learn a tough discipline: AI is an extraordinary accelerator, but it has zero taste. It does not know when an interface feels cluttered. It does not know when an animation distracts from the content. It will happily keep adding decorative layers until your product looks like a theme park.

7. The Challenges I Didn't Expect

Transforming this concept into a refined product surfaced a series of design and product tensions that I hadn't anticipated at the start:

The Enterprise Density Dilemma

Salesforce interfaces are built for power users who need high data density to process tickets and close deals efficiently. But personal portfolios are visited by recruiters, hiring managers, and fellow engineers who might only spend 90 seconds exploring your work. In my first pass, the screens looked like an air traffic control monitor. I had to learn how to adapt enterprise patterns—keeping clean structure and clear typography—while giving personal storytelling enough negative space and breathing room to remain inviting.

Avoiding the Theme Replica Trap

There is a fine line between drawing deep inspiration from a design system and creating an unlicensed replica. I didn’t want the portfolio to look like a captured screenshot of an internal CRM. It needed to be a bespoke product that paid homage to Salesforce foundations—its interaction logic, spacing harmony, and visual cleanliness—while expressing my individual identity.

Preserving Design Decisions Across Iterations

One of the most frustrating aspects of working with AI is its tendency to suffer from design amnesia. You can spend an entire session perfecting a subtle border radius, calibrating muted text contrast, and dialing in micro-animations. Then, two prompts later, the AI replaces your carefully tuned styles with generic, high-contrast, oversized default components. I realized I couldn't rely on the AI to “remember” our aesthetic direction; I had to explicitly constrain the design tokens and reject drift.

8. The Fight Against “AI Slop”

This project forced me to define what “AI slop” actually means in modern design and engineering.

AI slop is not buggy code. In fact, AI-generated code is often syntactically clean and runs without throwing console errors. AI slop is the absence of point of view. It’s what happens when you let the machine make the conceptual decisions.

The difference between those two outcomes isn't the model you use. It's whether you treat the AI as the architect or as the hands.

9. Designing for People Who Know Salesforce (and Those Who Don't)

One of the most delicate design challenges was navigating the dual audience of the portfolio.

On one side, there are visitors who live and breathe Salesforce: technical architects, QA leads, engineering managers, and developers who work in the ecosystem. For them, the subtle nods—the way records are structured, the terminology, the status indicators, the clean hierarchy—act as an instant cultural handshake. It signals that I don't just put “Salesforce” on my resume; I understand the platform’s philosophy deeply.

On the other side, there are visitors who have never logged into a CRM: recruiters, hiring managers from non-Salesforce backgrounds, or developers from other stacks.

To balance this:

• The structural logic stays enterprise-grade: Clean categorization, clear entity hierarchy, responsive panels, and intuitive tabbed views.
• The language stays human: I avoided unnecessary corporate jargon. Case studies explain the problem, the testing approach, and the engineering impact in clear, plain English.
• The navigation remains universal: Even if you’ve never seen a Salesforce workspace, clicking through projects, viewing details, and reading testimonials feels as effortless as using any modern web application.

10. When the Portfolio Became a Product

About halfway through this journey, a subtle shift occurred in how I spoke about the project.

I stopped saying: “I'm working on my portfolio.”

I started saying: “I'm building a small Salesforce-inspired product that happens to house my career.”

That mental shift changed everything. When you think of something as “just a portfolio,” you cut corners on product thinking. When you think of it as a product, you start caring about the deeper craft:

• How does the data model in the backend stay resilient when content updates?
• How does the layout adapt gracefully across every viewport from an iPhone to an ultra-wide display?
• How do loading states, fallbacks, and skeleton screens behave when network conditions are poor?
• Does every interaction provide immediate, predictable feedback?
• Does the interface feel coherent from the first click to the last?

11. What I Would Do Differently

If I were starting this project again from scratch tomorrow, here is what I would do differently:

1. Establish the Design System on Day One: In the early days, I let AI generate ad-hoc styles for different sections. That led to inconsistencies where spacing scales diverged. If I started over, I would define my core design tokens and typography hierarchy before generating a single UI screen.
2. Give AI Narrower, Highly Constrained Tasks: AI performs best when the problem space is small and boundaries are rigid. Whenever I gave broad prompts, I received generic slop. When I gave precise layout constraints, the results were brilliant.
3. Sketch Information Architecture First: Because generating screens with AI is instant, it is tempting to design directly in code. Taking 15 minutes to sketch the hierarchy on paper saved hours of iterative cleanup later.
4. Resist Decorative Distractions: Early on, I spent far too much time tweaking background particle effects and spotlight glows. The moment I stripped away the decorative fluff and focused on typography and content structure, the site became infinitely more powerful.

12. The Final Realization

Building this project taught me something fundamental about personal branding and software engineering.

The goal of a personal website isn't to look like a generic template from Dribbble or a tech startup landing page. The goal is to reflect who you actually are and how you think.

For years, I treated my specialization in the Salesforce ecosystem as something to list under a “Skills” bullet point. I treated it as a tool I used, rather than an integral part of my engineering identity.

By tearing down the generic portfolio and rebuilding it from the ground up—with an interface inspired by Salesforce design principles and content powered directly by Salesforce itself—I finally built something that feels honest.

It doesn’t look like everyone else’s portfolio. It looks like my work. It reflects the systems I test, the interfaces I navigate, and the enterprise standards I care about every single day.

I started this journey just trying to build a place to put my resume. Somewhere along the way, by fighting through the noise of AI slop and embracing the ecosystem I work in, I ended up building something that truly represents my craft.