My 2025 AI design and development stack for blogs

Five years ago, designing a blog looked drastically different than it does today. If I were to make a blog back then, I would have probably chosen a CMS like WordPress or, heaven forbid, Drupal or Joomla. I probably would have selected a template that looked good enough and started from there, making targeted changes to build out my personal brand.

Maybe I would have worked with a designer to do some concepting as well. Realistically I wouldn't have wanted to spend the money when I can get by on my own (I'm no Picasso but I think I do alright alright alright). If I decided to go that route, it would have involved a design tool like Figma or Sketch, numerous meetings, some asynchronous communication, wireframes, and finally a polished design that I could start implementing.

Then of course I'd have to navigate the mess of plugins and configurations. WordPress has historically struggled a ton with security flaws, so I'd need to stay on top of all of that as well.

I'd have to select a hosting provider from a bunch of legacy players that all kind of suck. And then once all of that is done, I could finally get down to writing the content.

Thank GOD we are past that.

Design Process

Prototyping

Designing AI-first today means that instead of needing to use a template or hire a designer, I can start by rapidly prototyping with my favorite AI tools. For web applications, many would probably recommend Lovable or Replit, but when it comes to raw design, I think the best prototyping companion is GPT-5.

GPT-5's canvas is really good. All you have to do is describe in as much detail what you're looking for from the design and you can start concepting right away. It won't be perfect, and a lot of it may look AI-generated, but for experimentation, you really can't beat it. It'll allow you to try out a bunch of "looks and feels" very rapidly to help you nail down the vibe you're going for.

I like to use separate chats for this. After 5-6 back-and-forth chats, the AI can usually produce a design that I like enough to store in my inspiration repository. I like to use figma for this because it's nice to see the designs side-by-side but insert your tool of choice here.

It's worth noting that I tried out Claude, Grok, and Gemini for this as well, and they just didn't feel as polished as GPT-5.

Another great strategy is to ask for an image of the site instead of the code. I find that this can produce some really interesting concepts that would be too challenging for the AI to implement on its own. This will amp up the creativity significantly.

Consolidation

Doing this is essentially creating an AI-generated "mood board" that lets you explore concepts side by side and pick and choose elements from each. In my process I usually settle on a main design that I like the best and then select elements from the other designs to add to it.

If you had the AI generate code for you, you've already got a great starting point. If you used an image, you'll have to work a little harder to get the AI to actually implement the design. It helps if you have experience breaking apart engineering tasks at this point, but here's a general breakdown that I like to use:

Have it implement the page structure (nav, colors) with placeholders for elements that will be more challenging for it to oneshot.
In separate chats, take a screenshot of the challenging elements and then ask the AI to just implement that element. You may or not be able to accomplish this because let's face it, sometimes beauty needs the human touch.
Take the code that the AI outputs and provide it to your main design chat.

You've essentially just broken it down for the AI into smaller chunks. In my experience they just aren't smart enough yet to do this themselves.

Also, I would avoid going to an IDE or CLI AI agent until you are past this step. They tend to overcomplicate this. You really just want one big file at this point that shows your design language.

Development Process

Selecting your Blog Technology

Okay so now you've got one big file that contains the design of your homepage. NOW you can actually start the real engineering of the site, and you have to make some engineering choices.

For example, what technology will you use for your blog?

First let's think about what we really need from our tech stack.

We need to pull content from some central repository
We need SEO for each of the blog post pages so that people can find the content

So looking at these requirements, the main technical decisions you need to make are:

What framework to use for the website
What framework to use for the content repository

Website Framework

The second requirement, needing SEO for blog posts, basically throws out the idea of using a single page application (SPA). When I originally started working on grafficmedia.com, I wanted to test the limits of my understanding of static site generation and hydration, so I didn't heed this advice. I used vite to render my react into html and js files and served them from netlify. I wrote some crazy prerendering scripts for my content (well, with heavy help from AI) to generate html files for each of the posts which were output to the build folder. And it worked! Like actually surprisingly well. I was able to get the search engines to crawl the site. The blog posts had meta information so the previews on social platforms looked great.

But soon complexity started to creep in and I started getting hydration issues. So I decided to move away from vite to NextJS, which has all of that SSR technology baked in and removes the need for static site generation. I'll touch more on other reasons NextJS was great for my needs later.

Content Repository

The content repository is where the blog posts will get pulled from to be displayed on the website. CMS systems usually provide some admin interface for you to write your posts and save them. They are stored in some database and then fetched when they are served on the website.

I like simple solutions, so I didn't really want to use any traditional CMS technology. I'm a developer and I don't want to have to log into some separate admin interface to write my content. It's just unnecessary and adds complexity. I want to write in markdown files that sat right next to my code and are checked into my github repository. I don't want some complex WYSIWYG editor - it clogs up my thinking and takes me out of the process of actually writing.

This is a personal choice because of my background. You might want to use a headless CMS (WordPress is still a decent choice for this) and a javascript framework for pulling that content in like Gatsby.js. If I was building for a non-technical client, I'd probably go this route so they have an editor to work in.

So my repository was going to be dead simple – just markdown files in a content directory.

Rendering the content

NextJS is so good at so many things, but what made it particularly great for this use case is that every page has server-side rendering by default. You can just write javascript functions to get your data, and if the functions use resources that are only available in a NodeJS (server) context, it'll just run them on the server automatically [note - verify this]. So in the case of my markdown files, in order to generate the content for the page, all we had to do was parse the contents of the the markdown files in an asynchronous function that used the file system package (fs) and a package called gray-matter, which pulls out both the data and content from the markdown files.

On the page for each blog post, we simply get the slug from the url params and then use that to get the appropriate blog post from the markdown files. We use the data to fill out the appropriate metadata (for social sharing / SEO) and then use the content to fill out the page. To actually render the markdown, I use a package called next-mdx-remote, which converts markdown to html.

Voila! We now have a blog that pulls from markdown files. It has great SEO and lives right next to my code. If I make updates to the content, all I have to do is deploy the site.

The beauty of this system is that it's actually crazy easy to power all sorts of content types from markdown files. My projects page also uses markdown files. And if I ever want to add more, it will be super fast to do so.

The AI development tools I used

I wrote very little of this code by hand.

Cursor is my IDE of choice. I've tried out VSCode CoPilot and Claude Code, and I just strongly prefer having the context of the codebase available to me so I can see the edits that the AI is making.

When I switched from vite to nextJS, I just asked the cursor agent to do it for me. It very nearly one-shotted it. There were a handful of errors and design problems during the switch, but it took me all of a few hours to resolve them.

This is insane. It would have taken me a good couple of days to do this myself I think.

Now, it is important to note that when it comes to AI, knowing the right questions to ask is incredibly important. I don't think I would have gotten here as smoothly if I didn't already know about the benefits and limitations of the technologies. But it's really incredible what a productivity boost using AI agents is.

Deployment

A quick note on deployment. For small sites like mine, the easiest thing to do is just use vercel. I thought about deploying to a Hetzner server just to practice my server administration skills, but for ease, I went with vercel. They are a great company, but you have to be careful not to exceed your quotas because costs can arise quickly. When that happens, I recommend self-hosting 😊

So now I have a blog

I think it looks pretty good. I'm happy with the developer experience. I can write freely in an experience that I like.

And most of all, making my blog from scratch was fun!

Writing about it was fun too. I hope you enjoyed the ride 👋.