Search for a command to run...
How I turned a visual showcase into a fast, CMS-powered professional platform for recruiters, search engines, and AI-assisted discovery
No comments yet. Be the first to comment.
Nothing is broken. Nothing is slow. Yet one small interaction subtly interrupts the experience, and it highlights an important lesson about designing AI products.
A long context window sounds like an obvious advantage for an AI agent. The agent can retain more search results, tool outputs, intermediate reasoning, and evidence. Give it enough context, and perhap
Building the frontend architecture, guided journey, and integrations for a new insurance purchasing feature
Designing the frontend flow and integrations behind a multi-stage insurance experience
A portfolio is often treated as a visual résumé: a polished landing page, a few project cards, and a contact link.
I wanted mine to do more.
This rebuild was about turning my portfolio into a durable professional platform. One that clearly communicates my work to recruiters and collaborators, remains easy to maintain as my work grows, performs well on real devices, and gives search engines and AI-assisted search systems enough structure to understand what I do.
The result is a portfolio centered on writing, projects, research, and professional experience with a CMS-backed architecture, structured SEO, an AI portfolio assistant, and production performance monitoring.
The previous version of my portfolio was highly visual and animation-driven. It represented a particular stage of my work well, but over time I wanted something more focused, calmer, and easier to evolve.
The question guiding this rebuild was:
Can a personal portfolio behave more like a professional knowledge base than a static showcase?
That meant optimizing for several audiences at once:
Recruiters who need to understand my profile quickly.
Technical readers who want to explore my work and writing.
Collaborators who want evidence of depth across software architecture, web engineering, AI, and research.
Search engines that need clear semantic structure.
AI-assisted search tools that rely on crawlable, structured, sourceable web content (GPT, Gemini, or Claude).
The visual redesign was only one layer. The larger change was architectural.
Instead of making every important thing compete on one long home page, the new portfolio is organized into clear destinations:
Feed: Writing and technical insights
About: experience, education, skills, and interests
Work: Projects & Case studies
Résumé and Academic CV downloads
The homepage now acts as a live writing surface rather than a generic hero section. It pulls in recent technical articles from Hashnode, which makes the portfolio feel active and gives visitors a direct way to understand how I think.
This was intentional. A portfolio should not only say what you do; it should make your thinking visible.
One of the biggest changes was moving important portfolio content away from hardcoded front-end constants into a structured CMS model using Sanity.
The content system now manages:
Projects
Professional experience
Education
Skills and interests
Research publications
Social profiles and site settings
This matters because a portfolio should be easy to maintain over years, not only easy to launch once.
Instead of rewriting layouts whenever I add a project or publication, I can update structured content and let the presentation layer remain consistent. The application uses typed queries and adapters so CMS content is transformed into reliable UI data.
A polished portfolio should feel fast before a visitor has time to think about performance.
I focused on a modern application stack built around Next.js, React, TypeScript, Tailwind CSS, and server-rendered content. The architecture avoids unnecessary client-side work, serves content through revalidation, and keeps visual movement restrained enough that it supports the experience rather than competing with it.
After deployment, the results were encouraging.
| Metric | Result |
|---|---|
| PageSpeed desktop performance | 100 |
| PageSpeed mobile performance | 95 |
| Best practices | 100 |
| SEO | 100 |
| Accessibility | 86 |
| Vercel desktop Real Experience Score | 100 |
The real-user desktop metrics were also strong:
| Desktop field metric | Result |
|---|---|
| First Contentful Paint | 0.9s |
| Largest Contentful Paint | 2.9s |
| Interaction to Next Paint | 64ms |
| Cumulative Layout Shift | 0 |
| Time to First Byte | 0.46s |
These scores are not the finish line, but they validate an important principle: adding richer content, a CMS, analytics, and AI functionality does not have to produce a slow site.
Lighthouse and PageSpeed are useful because they provide a controlled test environment. But real-user monitoring tells a more complete story.
That is why I also integrated Vercel Analytics and Speed Insights. They help me understand how the deployed site behaves for actual visitors rather than only during a single synthetic audit.
The early desktop field data shows a Real Experience Score of 100. Mobile data is also healthy, but it highlights the next improvement area: Largest Contentful Paint.
At the time of measurement, mobile results showed:
| Mobile field metric | Result |
|---|---|
| Real Experience Score | 85 |
| First Contentful Paint | 1.65s |
| Largest Contentful Paint | 3.51s |
| Cumulative Layout Shift | 0 |
| Time to First Byte | 0.69s |
This is exactly why field monitoring matters. A mobile Lighthouse score of 96 is excellent, but real-user data shows that mobile LCP still has room to improve.
The goal is not to hide that difference. The goal is to use it to guide the next iteration: identify the mobile LCP element, improve its loading path, and continue monitoring the effect with a larger sample size.
SEO is often added near the end of a project. In this rebuild, it was part of the architecture.
The portfolio includes:
Page-specific metadata
Canonical URLs
Open Graph metadata
A dynamic social-image route
robots.txt
XML sitemap generation
Semantic, server-rendered page content
Structured data using JSON-LD
The structured data describes the site as more than a collection of pages. It communicates entities and relationships such as:
The portfolio owner and professional identity
Social profiles
Writing and articles
Software projects
Research publications
Education and professional experience
Case studies and external links
This helps search engines interpret what the portfolio represents rather than just indexing isolated text fragments.
Search is evolving. People increasingly ask tools like ChatGPT, Claude, Gemini, and Google AI-powered search experiences questions such as:
Who is this person?
What projects has this developer built?
Find research on this topic.
What should I read from this engineer?
A portfolio cannot force an AI system to use or cite it. These systems vary, their results can change, and an answer alone does not prove that a model has been trained on a website.
But a site can make itself easier to discover and understand.
For this portfolio, I added several foundations:
Crawlable, server-rendered public pages
Clear page hierarchy and descriptive content
Structured metadata
JSON-LD for key entities and content types
Explicit bot access rules in robots.ts
An llms.txt file that identifies the canonical portfolio and its important pages
The claim is not “AI has learned my portfolio.”
It is:
The portfolio is designed to be accessible to crawlers and easier for search engines and AI-assisted search systems to interpret, cite, and navigate when they choose relevant public sources.
I will also be testing discoverability over time by checking:
Google Search Console indexing and crawl status
Search results for my name, role, projects, and research
AI-assisted search responses that visibly cite the portfolio
Referral traffic and crawler activity where available
If an AI-assisted search result cites the portfolio directly, that is useful evidence of source-level discoverability. If it only finds my LinkedIn, GitHub, or Hashnode profile, that still shows entity discoverability but it is not the same as a direct citation of the portfolio.
One of the more experimental parts of the rebuild is an AI portfolio assistant.
The assistant is designed to help visitors explore my public work, research, technical writing, and professional background through natural questions. Rather than being a generic chatbot, it is grounded in portfolio-specific knowledge and can guide visitors toward relevant projects, articles, and downloadable materials.
The implementation also includes practical safeguards:
Request validation
Message-length and conversation-size limits
Rate limiting
Timeout handling
Clear error states
Source links and suggested follow-up questions
A dedicated API route
The purpose is not to replace the portfolio’s navigation. It is to give visitors another way to discover the most relevant parts of the work.
The PageSpeed audit reached 86 for accessibility, which is a good result but not yet where I want it to be.
That is an important part of this case study: a performance score or successful deployment should not be treated as proof that a website is complete.
The next refinement pass will focus on the specific accessibility audit findings, including accessible names, semantic control labeling, contrast, and any remaining interaction details. Accessibility improvements are not cosmetic cleanup, they make the portfolio more usable and understandable for more people.
The main lesson is that a modern personal portfolio should be treated as a real product.
It should be:
Visually intentional
Fast on real devices
Stable during loading
Accessible
Easy to update
Searchable
Structured for machines as well as humans
Honest about remaining tradeoffs
Measurable after deployment
The redesign gave me a cleaner visual identity, but the more valuable change is that the site now has a foundation for long-term growth.
It can host new writing, projects, research, case studies, and professional updates without needing another full rebuild every time my work evolves.
