I Built the Blog. Publishing Was the Next Problem

My First Problem With Publishing Bousslog

When I started thinking about publishing more posts on Bousslog, I had one problem that sounded simple at first: I needed a CMS to make publishing easier.

I didn’t want to open the project every time I wanted to write a post, find the right file, edit everything inside the code, commit the changes, push them to Git, and then wait for the deployment. That was fine while I was building the site, but I knew I didn’t want that to become my normal writing workflow.

My first thought was WordPress.

The problem was hosting. I would have another server to pay for every month and another thing to manage. Managed WordPress hosting would make some of that easier, but it was also more expensive, and I didn’t really want to spend that kind of money just to get an admin page for a personal blog.

Bousslog was already a Next.js project running on Vercel. I didn’t need another server for the site itself, so adding one only because I wanted a CMS didn’t make much sense to me.

I also didn’t have a big budget for it.

So I started looking for another way.

I Didn’t Need Another Platform

I searched for different CMS options, but I kept finding the same kind of answers.

WordPress. Shopify. Other systems that were either much bigger than what I needed or still brought me back to hosting and setup that I was trying to avoid in the first place.

I even asked ChatGPT and explained what I was trying to do.

At first, the suggestions weren’t really solving my problem. I kept explaining that I already had the website, I already liked the design, and I wasn’t looking for something that would take over the whole project.

I only wanted an easier way to manage the posts.

After going back and forth for a while, TinaCMS came up.

That one made more sense.

It could work with the Next.js project I already had, and I could keep using Vercel. I didn’t need to move Bousslog somewhere else just to get a CMS.

So I decided to try it.

I Only Wanted TinaCMS for Posts

Once I started setting it up, I had to make another decision.

I didn’t want the CMS connected to everything.

I had already built the design the way I wanted it. I didn’t need an admin panel for changing the background, moving sections around, editing the homepage layout, or controlling every little part of Bousslog.

That would only give me more work.

I know enough code to change those things myself when I actually need to.

What I wanted Tina to manage was much smaller: the posts.

The title, description, cover image, tags, article content, and the things around publishing it.

That was it.

Keeping the scope small made much more sense for me.

But getting there wasn’t as simple as installing Tina and calling it finished.

The Default Workflow Wasn’t My Workflow

Tina worked, but some parts of the authoring experience didn’t fit the way I wanted to publish.

There were things I wanted to happen automatically that still needed manual work. Some fields didn’t make sense for the way Bousslog worked, and once I started using the CMS properly, I also started finding small problems around saving, updating, previewing, and publishing.

Sometimes I would save something and expect the post to update in one way, but it didn’t behave the way I expected.

Publishing also needed to be clear.

I didn’t want saving a draft and publishing a post to feel like the same action. A draft could still be unfinished. Publishing meant I was actually ready for people to see it.

Then there were smaller things that only become important once you start using the CMS every day.

Deleting a post was one of them.

I wanted the delete action to be clear and available where I was already managing the post instead of feeling hidden somewhere else.

So little by little, I started changing the workflow around what I actually needed.

That took some time, but it was also when Tina started feeling less like something I had installed and more like part of Bousslog.

The Part That Finally Made It Feel Right

The biggest improvement for me was getting the writing and preview experience together.

When I create a new post now, I have the things I actually need: title, description, cover image, tags, and the article itself.

At the same time, I can see the real post preview on the left side while I’m writing.

That was important to me.

I didn’t want to write everything inside an admin form and then keep jumping somewhere else just to check how the article actually looked on the site.

Now I can write something, save it, look at the preview, go back and change something, and check it again without leaving that workflow.

When I’m actually happy with the post, then I can publish it.

I also added the things I was missing around that flow, including a clearer delete action and the checks I wanted before a post became public.

Once all of that was working, I finally felt like the CMS was finished enough for what I needed.

Not finished because it had every feature a CMS could have.

Finished because I could finally write and publish without thinking about the machinery behind it every time.

The Workflow I Wanted From the Beginning

Before TinaCMS, publishing a post meant opening the code again.

I had to create or edit the post file, check it locally, do the Git steps, push the changes, and then wait for Vercel to deploy them.

None of those steps are difficult by themselves.

The problem was having to repeat them every time I had something new to write.

I didn’t want writing a blog post to feel like I was going back to development work every single time.

Now the workflow is much closer to what I wanted from the beginning:

Write → Preview → Save → Verify → Publish

I can focus on the article instead of thinking about files, Git, or deployments every time.

And honestly, that was the point where I felt relieved.

That part of Bousslog was finally done.

What I Learned From It

I started this because I was looking for a CMS, but I think I was asking the wrong question at first.

I didn’t really need a big CMS.

I needed a small publishing workflow that could sit on top of the project I already had.

That difference mattered.

If I had gone directly with WordPress just because it was the obvious CMS answer, I probably would have ended up paying for and maintaining more than I actually needed.

TinaCMS wasn’t perfect the moment I installed it either.

I still had to change things, remove things I didn’t need, and make the workflow fit Bousslog instead of changing Bousslog to fit the CMS.

But that ended up being the better approach for me.

I kept the site I had already built. I kept the design in code. I kept Vercel. And I added a CMS only where I actually needed one.

For Bousslog, that was enough.

It ended up being the right choice for me.