The Story of This Website

It's likely a natural inclination to have somewhere on the internet to call your own, a digital extension of a desire for territory. And I assume that for most people this desire is satisfied by a social media profile. But I think "social" media SUCKS, so my presence (if at all) on those platforms I keep limited.

Which is why I built this website. It's mine, it’s fully customisable, and it’s free from the brain-rot SLOP that you get on every social media platform. Here people can find some information about me, see what I've been up to via my projects and articles, and get in contact with me.

The Stack

Next.js: The core framework for its routing and server-side rendering capabilities.
TypeScript: Used throughout the codebase to ensure type safety and improve code quality.
React: The library that powers all the user interface components.
Tailwind CSS: The styling framework used for its utility-first approach, which allows for rapid, consistent UI development.
Vercel: The platform used for deployment and hosting, providing a smooth path from development to production.

Development

When it comes to making a website, there are roughly three options:

Use an "all-in-one" builder (Wix/Squarespace): Non-technical, expensive!
Hire a developer or agency: Non-technical, expensive!
Do it yourself, from scratch or with a template: Technical, cheap!.

I created this website just after finishing university, so as you might guess, being broke and with time on my hands, I decided to build it myself. As my speciality is data science, not web development, the extent of my web-dev knowledge before this project was my base of programming knowledge + a small amount I learnt about the internet and HTML in school/college. Everything else I taught myself.

It took a little over a week to get from my starting point, to a fully working live website ready to fill with content. To organise the project, I used a general project lifecycle approach, split into three distinct phases.

Phase I: Specification and Requirements

Obviously I needed a vision for what the website would look like. This included the functionalities I wanted, my budget, and time constraints. Whilst it might sound simple, this is very important as planning and research becomes pretty rough if you don't know what to plan or research.

Phase II: Research and Planning (The most important)

I spent a good few days researching and planning the project. Due to my relative lack of web-development knowledge, this was a substantial amount of learning. I learnt what was required for the website and about the current state of the web development field so that I could make informed choices regarding the technologies I used. This involved learning about things such as the pros and cons of common tech stacks, different deployment platforms, frameworks, and more. All of the decisions made factored in maintenance and cost, but also scalability if I wanted to build something bigger in the future, seeing the skills developed here as a potential investment.

How I did it conceptually:

Since web development is a large field, the most important thing that I did during this research and planning was managing complexity. On a psychological level, this is the secret sauce that I used to keep me motivated to work on the project.

I found that the key skill to research like this is metacognitive regulation. Specifically, I worked top-down, from the higher-level concepts downwards, marking rabbit holes which require further knowledge for the decision to proceed down or avoid. This strategy generally, at any given time, kept my next steps known and within my zone of proximal development.

How I did it practically:

Since teaching quality at universities nowadays is... you know. I am very familiar with self-learning and researching. Particularly regarding use of large language models (LLMs) for modern learning. Using careful context and prompt engineering I had my current daily LLM understand my requirements, figure out my current knowledge level, outline a learning plan and engage in active-recall centered conversations to build my knowledge fast and efficiently. This was also supplemented with youtube videos, which lead to feeding ideas into the conversations and so on. Dynamic, focused research.

Phase III: Execution — Coding and Deployment

Once I started coding, I had a fully functional live site in four days. I began with the homepage, then implemented the content system for the articles and projects, tweaking styling continuously as I went.

The code itself was mostly vibe-coded, and at this moment in time the term "vibe-coded" can mean a variety of things so I will elaborate a bit on my process. First, the LLM would be given very specific context files and instructions (more complex than it sounds). Then individual portions of code would be generated, and chiseled down manually or by prompts into a working, tested state.

When using LLMs to help code, I believe it is absolutely necessary to understand exactly what your code does, and the important parts of the syntax. This approach allows one to focus almost entirely on the logic, structure and purpose of the code, whilst abstracting away superfluous specifics. Your brain quite literally only has so much RAM. This is how I implement generative AI in my data science work.

However, since this project was not so critical, and I don't have a particular interest in going into web-dev, I’d call what I was doing B-Grade vibe coding: I understood everything at least at the block level — how components fit together, what each file was for, and the logic tying it all up — but I wasn’t memorising every detail of the syntax.

Whilst this approach did speed things up considerably overall, I was very quickly reminded why this can be a bad idea. At one point, the LLM I was using assumed the existence of a config file that had been required in older Tailwind versions but was no longer needed. That single wrong assumption wasted more time than it should have, but it was also a useful reminder about versioning and the importance of good context engineering. In short, AI can accelerate the process, but you still have to keep it on a leash.

Another, rather embarrassing, mistake I made early on was pushing big commits directly to main and just crossing my fingers that the deployment would work. Of course, it didn’t always. A few failed builds later I realised that proper branching with preview deployments is the way to go. It’s a very noobie error to make, but one that I’ve corrected and learnt from.

Despite these mistakes, the website came together pretty quick. I learnt a great deal and now have my very own website exactly how I want it :)

Potential Future Plans

There can always be more things!

Some of my plans for the future include:

Adding more content: The most important next step is to populate the site with more projects and articles!
Implementing a contact form: To make it easy for people to get in touch.
Content database: As the amount of content grows, I may explore migrating from local MDX files to an external database to improve content management and scalability.

This Website!