This is my personal portfolio. A space where I share my projects and experiences. I created it to be simple, fast, and built to evolve over time rather than act as a static website.
The site is designed to grow alongside my personal projects. As I take on new projects, I will continue to expand this website with new projects and try to document them in the "Info" page.
Dark theme with a professional blue palette, deep backgrounds to keep it clean. Colours are defined as global CSS variables so every component pulls from the same set of tokens rather than scattering hardcoded values through the codebase.
UI is separated into reusable components inside the /components folder. Components such as header, sidebar, footer, and page-specific bits each have have their own file.
This app is built with a focus on performance and maintainability, and ensure that its mobile-friendly (Although some components need to be scrollable horizontally due to width constraints).
Navigation uses a collapsible sidebar on desktop (a component from shadcn/ui) and a sheet drawer on mobile (also a component from shadcn/ui), so the content stays visible on any screen size.
This project came from wanting to practice full-stack development using tools I hadn’t worked with much before. Most of my professional experience has been with JavaScript and TypeScript on both the frontend and backend, so I decided to rebuild some familiar project ideas using a C# .NET backend — a language I wanted to get more comfortable with.
The backend is a C# .NET Web API built around controllers. Each controller handles a specific resource and follows standard REST such as GET to fetch data, POST to create, and so on. Routing in .NET works differently from Node.js frameworks as it uses attributes directly on the controller methods (like[HttpGet] and[Route]) rather than a centralised router file. The backend uses dependency to keep services separate from the controllers, which makes the code easier to extend later. Data is currently served as mock data with no database but the service layer is structured in a way that a real database could be implemented to only require changes in one place.
The frontend is a Next.js app that calls the API using the native fetch API. Project cards are rendered from a list returned by the API, and each card links to a dynamic detail page using Next.js file-based routing (/projects/[id]). The data for each detail page is fetched at request time so the frontend always reflects what the backend sends — nothing is hardcoded in the UI.
The architecture diagram on the project page shows the full request flow from the browser through the API and back, including where a database would fit if one were added. I drew it with Draw.io. The main thing I took away from this project was how .NET handles things like serialisation, middleware, and dependency injection compared to what I was used to in Node.js — they solve the same problems but with very different patterns.
