Well here we are in 2026 and after 2 previously failed attempts throughout 2025 to build this website, I finally have something I would consider "complete".

I originally started this whole journey of building a personal website as an excuse to learn Go, Googles general-purpose programming language, and was going to combine it with htmx as a low code solution to get up & running with minimal time investment. But then I asked myself the foolish question of "how can I make it better?"

This kicked off a whole insane rabbit-hole process where the end result of simply creating a blog post looked something like this:

I will admit I am still somewhat proud of this.

Did it allow for better scalability? Of course. Does it have better separation of concerns? Damn right. Would it take significantly more time and effort to implement yielding no visible gains to the end-user? Absolutely! When we take a step back and think about what is the end application feature set that we are trying to achieve, we can see that all that is required is the ability to display text and images that a creator (in this case only myself) creates then display it to a user. With this in mind is scalability really an issue? As much as I would like a world where my personal website brings in millions of users at a time that just isn't the reality, so should I really be catering for it? No, in fact if I was to implement this grand plan it would most likely have the opposite effect because introducing more external dependencies means more time waiting on network calls, slowing down application performance.

But what about separation of concerns? Even as a solo developer it is still good to have high cohesion & low coupling in your application but this does not mean we need to distribute our areas of concern across multiple systems and services. Having an all-in-one (monolithic) application is considered a taboo by a lot of people, especially since the popularity of microservices, but sometimes it is the correct solution. The time it takes to deploy my application is next to nothing and thanks to Vercel it is completely seamless to the end-user, this means I can version my content alongside my code and simply use the existing deployment process to push my content changes to the end-user. This allows me to completely eliminate the need for a content management API as well as the database for storing the content, I can also remove the dependency on Auth0 as it is no longer required for the security of the API. Cloudinary can be eliminated too which was to be used for media hosting alongside the secondary repository for content versioning and it's integration flows, thus significantly simplifying our application landscape.

Can we simplify all this further though? As the keen-eyed of you may have spotted previously I had originally intended to use Render to host my application because it allowed me to deploy Docker images containing my application and have a developer experience that was consistent with my deployed environments. But how many developers are working on this project? One. How many deployed environments do I have? That's right, one (1). I do not have an issue of trying to scale a development team or setup multiple server instances which eliminates some of the major benefits of using a tool like Docker. I can also remove the concerns around even establishing an environment in the first place by offloading the responsibility to a serverless hosting service like Vercel which will take care of this problem for me.

The final thing to look at is our choice of technology, Vercel does not support the hosting of Go based applications and Go itself is not a language designed for building visual experiences. It would be far more sensible to use a proper frontend language and framework, enter Vue and Nuxt. Neither of these technologies were something I was familiar with but I have been thoroughly impressed by how easy it is to get up and running as well as the ability to create content using a language I was already familiar with, Markdown.

NuxtContent is the specific Nuxt module we'll take a look at as it enables us to render Markdown and insert Vue components amongst the rendered text, as so:

CodePreview

content/index.mdcomponents/LandingHero.vue

---
title: The Mountains Website
description: A website about the most iconic mountains in the world.
---

::landing-hero
---
image: /blog/you-arent-gonna-need-it/everest.jpg
---

#title
The Everest.

#description
The Everest is the highest mountain in the world, standing at 8,848 meters above sea level.
::

We first define our page metadata at the top of the markdown file (title, description). We then create an instance of our LandingHero Vue component by using the ::landing-hero syntax, passing in the expected prop value of image which contains the location of our mountain image. Lastly we set the values we want for the title and description, these values will be substituted into their respectful slot elements in the Vue component. The end result is what you see in the preview tab where the content from the Markdown file has been inserted into the Vue component and rendered successfully.

There is a ton more you can do with Vue and Nuxt but this post was not meant to be an exhaustive demonstration of the frameworks capabilities, I simply wanted to highlight that there already exists light-touch tooling capable of meeting my applications feature set requirements that did not require me to write my own templating system or build a content management API.

With all this said our final architecture now looks something like this:

It's basic, but it works.

A far simpler design and if I was not requiring some form of routing for sending traffic to either the application server or the email server (not part of this solution) I could simplify things even further.

So what is the key take away I hope to leave you with? Well as the title of this post suggests, 'You Aren't Gonna Need It'. It's easy for us as engineers or developers to get carried away trying to come up with that perfect solution capable of handling everything and anything thrown at it, but first consider your actual feature requirements and what resources are available at your disposal. Chances are you do not have all the time in the world to build your dream application, maybe you do not even have a team to help you build it either, and does the problem you are trying to plan for really exist?

Trim the fat whenever you can and always remember all code is a liability, the less we have of it the easier it is to maintain.