From Static Portfolios to Living Knowledge Platforms: How I Built My AWS Community Builder Portfolio with AI and AWS
What if your portfolio could explain your architecture even when you're offline?
What if a technical portfolio could do more than display projects? What if it could explain the thinking, decisions, and learning behind them?
As an AWS Community Builder, I have created technical projects, written blogs, earned certifications, supported community initiatives, and documented my learning across several platforms.
My code was on GitHub.
My articles were on Medium and Dev.to.
My professional updates were on LinkedIn.
My certifications, projects, mentorship work, and technical experience were all stored in different places.
Everything existed, but it was scattered.
I did not want to build another basic portfolio containing only project cards and social links.
I wanted to create a living engineering knowledge platform one place where people could understand not only what I built, but also how I think as an engineer.
To turn that idea into a working website, I used:
- Kiro as my AI-assisted development partner
- React and TypeScript for the frontend
- Vite as the development and build tool
- Tailwind CSS for the interface
- GitHub for source control
- AWS Amplify for hosting and automated deployment
This is the complete story of how I built it.
1️⃣ The Problem: My Technical Work Was Scattered
A traditional portfolio usually includes:
- An introduction
- A list of skills
- Project cards
- Certifications
- Contact details
That format can look professional, but it often leaves important questions unanswered.
For example:
- What problem was each project solving?
- Why were certain technologies selected?
- What challenges appeared during development?
- How did the engineer organize the application?
- What lessons came from the project?
- Where can someone read the complete case study?
A visitor might need to open GitHub, LinkedIn, Medium, Dev.to, and several project repositories just to understand one person’s technical journey.
I wanted to solve that fragmentation problem.
Instead of building a website that simply says:
“Here are my projects.”
I wanted it to say:
“Here are my projects, the decisions behind them, the lessons I learned, and the resources you can use to explore them further.”
2️⃣The Vision: A Living Engineering Knowledge Platform
I began with one guiding question:
What if my portfolio could explain my engineering work even when I was not present?
That meant the website needed to bring together:
- My professional introduction
- AWS and cloud projects
- AI and DevOps projects
- Technical blog posts
- Certifications
- Work experience
- Community contributions
- Mentorship activities
- GitHub repositories
- Contact and social links
I also wanted the structure to grow with me.
When I complete a new project or publish a new article, I should be able to add it without redesigning the entire site.
That requirement influenced the architecture of the application.
3️⃣ The Code: Designing
Before creating the React application, I organized the content I wanted to include.
I created a main project folder called:
rajpreet-aws-portfolioInside it, I created a separate folder for the website content.
rajpreet-aws-portfolio/└── website-content/ ├── about-me.txt ├── blogs.txt ├── certifications.txt ├── projects.txt ├── social-links.txt └── images/I verified the structure from Windows Command Prompt using:
tree /fThe output confirmed that my initial content structure was ready:
This step may appear simple, but it helped me separate two different concerns:
The information I wanted to communicate
The application that would display it
Instead of beginning with empty components and placeholder content, I first created a place to organize my real professional information.
Choosing the Technology Stack
I selected a lightweight frontend stack that would be easy to maintain and deploy.
Layer | Technology | Purpose |
|---|---|---|
Frontend | React | Build reusable interface components |
Language | TypeScript | Add type safety and improve maintainability |
Development tool | Vite | Provide a fast local development server and production build |
Styling | Tailwind CSS | Create responsive and consistent layouts |
AI development partner | Kiro | Turn structured prompts into implementation tasks |
Source control | GitHub | Store and version the application |
Hosting | AWS Amplify | Build, host, and automatically redeploy the website |
The stack was intentionally simple.
This was a frontend portfolio, so I did not need to introduce unnecessary infrastructure.
AWS Amplify gave me the AWS deployment experience I wanted without requiring me to manually manage servers.
4️⃣ The First Challenge: The Project Directory Was Not Empty
I originally tried to create the Vite project in the root portfolio directory.
C:\Users\Rajpr\rajpreet-aws-portfolio>npm create vite@latest . -- --template react-tsHowever, that directory already contained the
website-content folder.Because the directory was not empty, creating the Vite application there was not the cleanest approach.
Instead of deleting the content I had already organized, I created a separate application directory:
rajpreet-aws-portfolio/├── app/└── website-content/This produced a much clearer structure:
rajpreet-aws-portfolio/│├── app/│ └── React application│└── website-content/ └── Portfolio content and imagesThat small adjustment became an important organizational decision.
The application code and the source content remained separate.
5️⃣ The Creation: React and TypeScript Application
From the
app directory, I created the React and TypeScript project using Vite.C:\Users\Rajpr\rajpreet-aws-portfolio\app>npm create vite@latest . -- --template react-tsVite asked me which linter I wanted to use.
I selected:
ESLintIt then asked whether it should install the dependencies and start the application.
I selected:
YesVite scaffolded the project and installed the required packages.
Seeing
found 0 vulnerabilities confirmed that the initial dependency installation completed successfully.The development server then started automatically.
Opening that URL in the browser showed the default Vite application.
That was my first working milestone.
6️⃣The Milestone: Localhost
At this stage, I did not yet have a portfolio.
I only had a working React environment.
But this validation was important because it confirmed that:
- Node.js and npm were working
- The dependencies were installed
- React was running
- TypeScript was configured
- Vite could serve the application
- The local environment was ready for development
I prefer validating the foundation before introducing design, content, and deployment changes.
A successful localhost page meant I could move forward confidently.
7️⃣The Prompts: Kiro
The most interesting part of this project was how I worked with Kiro.
I did not enter one vague prompt such as:
“Build my entire portfolio.”
Instead, I broke the website into smaller tasks and used focused prompts for each stage.
My workflow looked like this:
Define the requirement ↓Write a focused Kiro prompt ↓Kiro creates or updates the files ↓Review the implementation ↓Run the website locally ↓Refine the prompt ↓Test againKiro was one AI development tool, not several independently deployed agents.
However, I structured the prompts as if I were assigning responsibilities to different members of a software team.
For example:
- Planning responsibility
- Component development responsibility
- UI and responsive design responsibility
- Review and refactoring responsibility
- Build-verification responsibility
- Deployment-preparation responsibility
This approach made the workflow feel like an AI-assisted engineering pipeline.
8️⃣The Prompt Engineering: Software Engineering
One of my biggest lessons was that the quality of the implementation depended heavily on the quality of the prompt.
A broad prompt such as:
“Create a project section.”
leaves several important decisions undefined.
A stronger prompt would be
That prompt defines:
- The component’s purpose
- The framework
- The language
- The styling system
- The expected fields
- The responsive requirement
- The design direction
- The separation between content and presentation
Writing prompts started to feel similar to writing technical requirements.
The more precisely I described the expected behavior, the better the result became.
9️⃣The Website: One Section at a Time
I used Kiro to help create the portfolio incrementally.
The website was divided into sections such as:
- Navigation
- Hero section
- About Me
- Featured Project
- Projects
- Blogs
- Certifications
- Professional Experience
- Community Contributions
- Contact
- Footer
Instead of generating all sections at once, I focused on one component at a time.
This helped me:
- Review each component properly
- Identify layout issues earlier
- Test responsiveness
- Correct inaccurate content
- Keep the visual design consistent
- Avoid building multiple features on top of an unresolved problem
The process was slower than accepting one large AI-generated result, but it produced a website I could understand and explain.
A Prompt-Driven Development Workflow
Conceptually, the workflow looked like this:
My Portfolio Vision │ ▼ Requirements and Content │ ▼ Kiro Prompt │ ▼ React + TypeScript Implementation │ ▼ Tailwind CSS Presentation │ ▼ Human Review │ ▼ Local Vite Testing │ ▼ GitHub │ ▼ AWS Amplify │ ▼ Live PortfolioThe human-review step was essential.
Kiro accelerated implementation, but I remained responsible for:
- Content accuracy
- Component organization
- Design consistency
- Professional presentation
- Testing
- Final approval
🔟The Live Development: Vite
As Kiro updated the project files, Vite automatically detected the changes.
My terminal displayed updates such as:
This is Vite’s Hot Module Replacement workflow.
When Kiro or I changed a component or stylesheet, the browser refreshed the affected part of the application without requiring me to stop and restart the entire server manually.
That made the feedback cycle much faster:
Prompt ↓File update ↓Vite detects the change ↓Browser refreshes ↓Review the result ↓Refine the promptAt one stage, the local route appeared as:
This happened after the Vite base path was updated for the portfolio project.
Favorite Architectural Decision
One of the most useful decisions was keeping the portfolio content separate from the visual components.
The original content files included:
Inside the React application, this information could then be converted into structured portfolio data.
Instead of hardcoding every project directly into a visual card, the application could use reusable data objects.
For example:
interface Project { title: string; description: string; technologies: string[]; githubUrl?: string; articleUrl?: string;}A reusable project card could then display each project from the data source.
This provides several advantages:
- New projects are easier to add
- Components stay reusable
- Content can be updated without redesigning the page
- The layout remains consistent
- The website can grow without duplicating code
This was the first step toward making the portfolio a living platform instead of a fixed page.
1️⃣1️⃣ The Test: Application
During development, I used the Vite server to validate the website locally.
npm run devBefore deployment, I also prepared the application for a production build.
The testing process included checking:
- Navigation links
- Responsive sections
- Project cards
- Blog links
- Certification details
- Contact information
- Desktop layout
- Mobile layout
- TypeScript compilation
- Browser console output
Testing locally before deployment reduced the risk of publishing a broken version.
1️⃣2️⃣ The Portfolio: AWS Amplify
Once the application was ready, I pushed the source code to GitHub and connected the repository to AWS Amplify.
The deployment workflow became:
Local Development │ ▼Git Commit │ ▼GitHub Push │ ▼AWS Amplify Build │ ▼AWS Amplify Deployment │ ▼Public Portfolio URLAWS Amplify was a good fit for this frontend application because it handled the hosting workflow without requiring me to manage a server.
After the repository and branch were connected, Amplify could build and deploy the application.
The most useful part was continuous deployment.
https://main.d2nh1yvhiu7vyp.amplifyapp.com
1️⃣3️⃣The CI/CD Workflow: GitHub and AWS Amplify
I connected my GitHub repository to AWS Amplify to create an automated CI/CD workflow. Every time I update the portfolio and push the changes to the
main branch, AWS Amplify automatically detects the commit, installs the dependencies, builds the React application, and deploys the updated version.Local Code Changes ↓Git Commit ↓Push to GitHub ↓AWS Amplify Detects the Commit ↓Install Dependencies ↓Build React Application ↓Deploy Updated WebsiteThis workflow removed the need for manual deployments. GitHub acts as the source of truth, while AWS Amplify handles continuous integration and continuous delivery. The deployment history in Amplify also makes it easy to review whether each build succeeded or failed
git add .git commit -m "Update portfolio content"git push origin main
The GitHub push would trigger a new Amplify build and deployment.
That means the portfolio can continue evolving as I:
- Publish new blogs
- Add new AWS projects
- Earn new certifications
- Update my experience
- Add community contributions
- Improve the interface
This automatic update process is one of the reasons I describe the project as a living platform.
What Kiro Helped Me Do
Kiro helped accelerate:
- Project configuration
- Component creation
- Tailwind integration
- Layout development
- Responsive design
- Content organization
- Reusable component creation
- File updates
- Iterative improvements
It reduced the amount of repetitive implementation work required.
More importantly, it allowed me to focus on what I wanted the platform to communicate.
What Kiro Did Not Do
Kiro did not decide:
- Why I needed a living knowledge platform
- Which projects represented my best work
- What information was accurate
- How my professional story should be presented
- Which community contributions mattered
- What reviewers should learn from the website
- Whether the final result reflected my personal standards
Those decisions required my judgment.
The AI tool helped execute the vision.
It did not create the vision.
1️⃣4️⃣The Real Lesson: Speed Is Not the Same as Understanding
It would have been possible to ask Kiro for a complete website and accept the first result.
That may have produced a website more quickly.
But I would not have understood every part of it.
By building section by section, I learned:
- How the React components were organized
- How TypeScript supported reusable data
- How Vite handled local development
- How Tailwind controlled the visual system
- How GitHub connected development to deployment
- How AWS Amplify published future updates automatically
AI made the process faster, but the step-by-step workflow helped me retain ownership of the implementation.
Speed is useful only when you understand what you are shipping.
What Makes This More Than a Portfolio?
The current version brings together my:
- Projects
- Articles
- Certifications
- Experience
- Community work
- Mentorship
- Technical interests
- Professional contact information
However, the larger idea is that this content can continue becoming more structured and useful.
A static portfolio says:
“This is what I have completed.”
A living knowledge platform says:
“This is what I have completed, how I approached it, what I learned, and how the work continues to evolve.”
Each improvement can be introduced incrementally through the same workflow:
Define ↓Prompt ↓Generate ↓Review ↓Test ↓Push ↓Amplify DeployFinal Thoughts
This project started with a simple goal: organize my technical work in one professional location.
It became an experiment in:
- Prompt-driven development
- AI-assisted engineering
- React component architecture
- Structured technical content
- Continuous deployment
- AWS hosting
- Professional storytelling
The most important lesson was not that AI could generate a website.
The lesson was that AI became most valuable when I gave it clear requirements, reviewed its work, tested the result, and remained responsible for the final decision.
- Kiro accelerated the implementation.
- React and TypeScript provided the application structure.
- Vite created a fast development workflow.
- Tailwind CSS supported the visual design.
- GitHub managed the source code.
- AWS Amplify turned the local application into a continuously deployed public website.
Together, they helped me move from scattered technical content to a platform that can grow with every new stage of my AWS journey.
For me, that is what being an AWS Community Builder represents:
Not only building technology, but organizing and sharing the knowledge so other builders can learn from it.
Discussion
How are you using AI-assisted development tools in your engineering workflow?
Are you asking for complete applications in one prompt, or are you breaking the work into smaller requirements, reviewing the output, and learning from each step?
Share your experience in the comments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article