When I decided to build my own portfolio website, I did not want it to feel like a generic template with a name, a job title, and a few links.
I wanted something that actually reflected how I work.
I wanted one place where I could showcase my projects, technical documentation, resume, and the kind of IT and systems work I enjoy doing. I also wanted the website itself to become part of the portfolio instead of just being a container for it. If someone visited it, I wanted them to see not only what I have done, but also how I think about organization, layout, iteration, and polish.
If you want to see the finished result, you can view my portfolio here: dev.hunterryskoski.com
Why I Chose to Build It Myself
A lot of portfolio sites feel interchangeable. They look fine, but they do not really say much about the person behind them.
I wanted mine to feel more personal and more practical.
My work has continued to grow across documentation, endpoint management, reporting, and project write-ups, so I needed a site that would be easy to update over time. I did not want to rebuild everything every time I added a new project or wanted to expand a section.
The Stack I Used
I built the site with:
- Next.js
- React
- TypeScript
- Tailwind CSS
I used Next.js with the App Router to structure the homepage, project pages, documentation pages, and shared layout components. That gave me a clean and scalable way to organize the site as it grew.
I used React and TypeScript to make the site easier to maintain and update without everything becoming messy over time.
I used Tailwind CSS for layout, spacing, gradients, responsiveness, card styling, typography, and hover effects. It made it much easier to build quickly while keeping the design consistent.
Why This Stack Worked Well
One of the biggest wins was how easy it became to expand the site without starting over.
Because the site is built around the App Router, I can keep adding new pages and sections as needed. That matters a lot for a portfolio, because a portfolio is never really "done." It changes as your work changes.
Tailwind also made a huge difference. Instead of fighting a giant CSS file, I could move quickly on layout and styling while still keeping things consistent. That helped me spend more time improving the experience and less time wrestling with structure.
How I Used Codex During Development
One of the most interesting parts of this project was how I used Codex.
I did not treat it like a one-shot website generator. I treated it more like a coding partner.
That meant giving it a specific task, letting it inspect the existing codebase, and then iterating from there. Sometimes the task was something bigger, like building a new section or creating a page. Other times it was more focused, like fixing a layout issue, updating a resume link, cleaning up a component, or helping push finished changes to GitHub.
That approach worked much better than vague prompting.
The more grounded the task was, the more useful the collaboration became.
What AI Helped With — and What It Didn’t
Codex helped me move faster, but it did not replace judgment.
That part still mattered just as much.
I still had to decide what belonged on the site, what tone felt right, what should be published, and which ideas were actually worth keeping.
It was a good reminder that AI can accelerate implementation, but it does not make product decisions for you.
My Workflow
The workflow I settled into was pretty simple:
- Describe the change in plain language.
- Point Codex to the relevant page or component.
- Let it inspect the existing code before making assumptions.
- Review the result and iterate on wording, layout, or behavior.
- Run checks like linting to make sure things are clean.
- Commit and push only when the change matches the direction I want.
Once I started working this way, the project felt much more manageable. Instead of thinking, "I need to build an entire portfolio site," I could focus on one decision at a time and keep moving.
Real Things I Built and Refined
A few examples of what that looked like in practice:
- Building and refining the homepage layout
- Updating the resume button to point to a new PDF
- Creating the Projects section and a dedicated page for this website
- Cleaning up components that were not behaving the way I wanted
- Committing and pushing completed changes to GitHub
That kind of incremental progress made the whole project feel realistic instead of overwhelming.
What I Ended Up With
The final result is a portfolio site that feels much closer to how I actually work.
It includes a homepage, resume section, project pages, and documentation sections, with enough structure to keep growing over time. Just as important, the process gave me a workflow I would use again: move from idea to implementation faster, keep momentum on the project, and still review each change carefully before it goes live.
That is probably my favorite part of the whole thing.
I did not just end up with a website. I ended up with a better process for building future projects.
Lessons I Learned
A few takeaways stood out to me:
- AI works best when the task is specific and grounded in a real codebase.
- It is more useful as a collaborator than as a one-shot generator.
- Small, iterative requests usually work better than huge vague prompts.
- You still need to review the output and keep your standards high.
I think those lessons are the part that will stick with me the most going forward.
Final Thoughts
Building this portfolio changed how I think about AI in development.
The value was not that it replaced my thinking. The value was that it helped me keep momentum, execute faster, and spend more of my time making decisions instead of getting stuck in the slower parts of implementation.
Codex helped me build the site faster, but the project still felt like mine at every step.
Top comments (4)
Really like how you framed AI as a “coding partner” instead of a generator—that matches my experience as well.
I’ve been using Cursor and found a similar pattern: the quality of output depends heavily on how specific and grounded the task is.
vague prompts → messy output
context-aware, incremental tasks → actually useful results
Your workflow (especially letting the tool inspect the existing code before making changes) is something more people should adopt.
Also agree that AI helps with execution, not decision-making—that part still stays with the engineer.
Curious—did you find any limits where Codex struggled even with good context? For example around larger refactors or architectural changes?
There were a few places - one specific example was adding a page visit counter. I wanted to put it in the footer of the page, but upon each update to the page, the counter restarted. I explained that, and it was fixed temporarily, but then when I made a minor adjustment to my homepage, it reverted back to zero. I ended up removing it since it didn't serve a real purpose and was being too finicky.
That’s a great example—and honestly a very real one.
I’ve run into similar issues where AI can fix something locally, but doesn’t fully account for how state or lifecycle behaves across updates. Things look “correct” in isolation, but break once you make adjacent changes.
The decision to remove it makes sense too—feels like a good reminder that not everything needs to be solved technically if it doesn’t add real value.
Out of curiosity, do you think that was more of a state management issue (e.g. client vs persistent storage), or more about how the tool was modifying code incrementally?
I think it was probably a mix of both, but more on the incremental code change side. The counter likely needed some kind of persistent storage behind it, but the bigger issue was that each small homepage change seemed to undo or overwrite part of the earlier fix. That was one of the clearer examples for me where AI was helpful for implementation, but still needed me to catch when a “working” solution wasn’t actually durable.