How I Manage 8+ Website Projects Without WordPress

I run more than eight websites.

They are not big commercial platforms. They are mostly my own things: open source software sites, forums, blogs, documentation pages, experiments, and small community projects. Some are serious. Some are just fun. All of them need to be easy to update, easy to deploy, and simple enough that I can come back months later and still understand what is going on.

And no, I do not use WordPress.

That is not a dramatic statement. WordPress works for many people. It has a huge ecosystem, tons of plugins, and a long history. I just do not like working with it for my own projects. For the way I build and manage websites, it feels too heavy, too plugin-driven, and too far away from the clean development workflow I want.

I also have not found a traditional CMS that I really want to use.

So I built my own way of managing website projects.

The Kind of Website Setup I Actually Want

When I think about managing multiple websites, I do not want every project to become its own little universe.

I do not want one site deployed one way, another site deployed a totally different way, and a third site using some random plugin or dashboard I forgot about. That gets messy fast.

What I want is a repeatable baseline.

A website should have a clear structure. It should have content files. It should have a modern frontend. It should have version control. It should have automated checks. It should have a clean deployment path. And most importantly, it should not require me to remember a bunch of custom steps every time I want to change something.

That is the main idea behind my website workflow.

Not a big platform. Not a traditional CMS. Not a tutorial-style setup with a million moving parts.

Just a practical system that lets me manage multiple sites with the same general approach.

Going Back to the 1999 Feeling

I started building websites around 1999.

Back then, websites felt simple. You had files. You edited them. You uploaded them. The page was live.

Of course, the web is very different now. We have modern JavaScript frameworks, component-based UI, CSS systems, CI/CD, cloud hosting, containers, Kubernetes, edge platforms, and all kinds of automation.

But I still like the old idea that a website should feel understandable.

I do not want my personal websites to feel like black boxes. I do not want the whole thing to depend on a dashboard, a database, and five plugins that may or may not be maintained next year.

So my goal became simple:

Build websites with the modern tools I like, but keep the mental model close to files, components, content, and deployment.

That gives me the best of both worlds.

My Modern Website Stack

Most of my current website projects use a modern JavaScript and CSS stack.

For a site like mrakbook.com, the project is built around a Next.js application, custom design, reusable components, and content stored in files. The repo is organized in a small monorepo-style structure, with the main website living as its own service and deployment handled through my internal platform tooling.

That means I can keep the website flexible without turning it into a CMS-heavy project.

The frontend can still be modern. I can use React. I can use Next.js. I can create my own layout, typography, navigation, article templates, and UI structure. I can keep the design clean and specific to the site instead of starting from a generic theme.

At the same time, the content stays manageable. It is not locked inside WordPress. It is not buried in a database. It is not dependent on a plugin.

It is just part of the project.

Why I Prefer This Over WordPress

The biggest reason I avoid WordPress for my own sites is control.

I want control over the code. I want control over the design. I want control over the deployment. I want control over the performance. I want control over how content is structured.

With WordPress, I often feel like I am managing the system around the website more than the website itself.

Themes, plugins, admin pages, security updates, database backups, plugin conflicts, editor behavior, caching layers - all of that can be useful, but for my projects it is usually more than I want.

For my own websites, I prefer a developer-first workflow.

That means Git, code review, versioning, automation, and reproducible deployments.

It also means I can treat each website like a real software project, even if it is just a personal blog, forum, or open source project page.

A Monorepo-Style Project for Each Website

For each major website, I like having a clear project structure.

In the case of mrakbook.com, it is a monorepo-style setup. The website is one service inside the project, and the supporting platform tools live next to it. That makes the project easier to reason about.

The website is not just a random folder of files. It has a service structure, application code, reusable components, content, configuration, local commands, and deployment workflows.

This helps a lot when managing multiple websites.

Instead of asking, "How did I deploy this one again?" I can follow the same pattern across projects.

That is the real value.

Not complexity. Consistency.

My Internal Platform Layer

Over time, I built a small internal framework around my projects.

The goal is not to make things fancy. The goal is to make them predictable.

I have a platform CLI that gives me one common way to run, check, test, build, and deploy services. For mrakbook.com, that internal tool is called PLSR, and it acts as the project's service orchestrator. It discovers services, reads their configuration, and exposes consistent commands for local development and CI/CD.

That may sound more complicated than a simple website needs, but it actually makes things easier when you run many websites.

Instead of remembering different commands for different projects, I can use the same workflow.

Run the site. Check the site. Test the site. Build the site. Deploy the site.

The details can change behind the scenes, but the developer experience stays familiar.

Keeping Deployment Practical

I like automation, but I do not like unnecessary ceremony.

For these websites, I did not want every project to become a giant Terraform project. I did not want to manage a pile of Helm charts manually. I did not want each site to have its own custom deployment logic that only makes sense for that one project.

That kind of setup can be powerful, but it can also become heavy very quickly.

So I focused on a practical baseline.

GitHub Actions handles CI/CD. Versioning is part of the workflow. Quality checks run before release. Deployment logic is standardized as much as possible. The platform boundary stays consistent.

For hosting and infrastructure, I use AWS and related cloud services where it makes sense. I care about cost stability, portability, reliability, and being able to move pieces around without rewriting everything from scratch.

That balance matters to me.

I want enough infrastructure to be serious, but not so much that the infrastructure becomes the project.

GitHub Actions as the Automation Backbone

GitHub Actions is a good fit for the way I manage these websites.

Every project already lives in Git. Every change has history. Every release can be tied to a commit or version. So it makes sense to keep the automation close to the code.

My CI/CD flow is designed around standardization and quality.

Before something becomes production, I want checks. I want version consistency. I want the project to build cleanly. I want the deployment path to be repeatable.

This is not because every personal website needs enterprise-level process.

It is because once you manage many websites, even small inconsistencies become annoying.

Automation removes that friction.

The Baseline Matters More Than the Tools

The exact tools are not the point.

Today, I may use React, Next.js, GitHub Actions, AWS, Kubernetes, Argo CD, or custom platform scripts. Tomorrow, some of those tools may change.

The important part is the baseline.

I want every website project to answer the same questions clearly:

• Where does the content live?
• How does the site run locally?
• How does quality get verified?
• How does deployment work?
• How hard is it to come back later?

Content should be easy to find, easy to edit, and versioned with the project.

There should be one clear way to start it and check it.

Type checks, builds, tests, and release gates should run consistently.

Deployment should be automated, repeatable, and not dependent on memory.

After a few months away from a project, I should still be able to open it, understand it, and make a change without digging through old notes.

That is what I care about most.

Why This Works for Multiple Websites

When you only have one website, almost any workflow can work.

When you have eight or more, the workflow starts to matter.

Small differences become expensive. One-off scripts become confusing. Manual deployment steps become risky. Random plugin decisions become long-term maintenance problems.

That is why I prefer a standardized approach.

Each website can have its own design, personality, content, and purpose. But underneath, the structure should feel familiar.

This lets me focus on the actual project instead of constantly rebuilding the same foundation.

For open source software pages, I can focus on explaining the project.

For forums, I can focus on the community.

For blogs, I can focus on writing.

For personal experiments, I can focus on testing ideas.

The website system stays out of the way.

What I Learned Over the Years

A lot of this came from experience.

I learned from building things the wrong way. I learned from maintaining old projects. I learned from people who were better than me at infrastructure, automation, frontend architecture, and release management. I still occasionally get help and ideas from other engineers.

Over time, I realized that I did not need the biggest system.

I needed the system I would actually keep using.

That is a big difference.

A good personal website workflow should not feel like a corporate platform copied into a hobby project. It should feel lightweight, understandable, and strong enough to trust.

That is the balance I keep trying to improve.

My Current Philosophy

My current approach to managing website projects is simple:

• Use modern frontend tools.
• Keep content close to the code.
• Avoid heavy CMS dependencies.
• Automate the boring parts.
• Standardize the workflow.
• Make production boring.

That last one is important.

I do not want deployments to feel exciting. I want the writing, design, product ideas, and community work to be exciting. Deployment should be boring, predictable, and repeatable.

That is what makes it sustainable.

Final Thoughts

I do not think everyone should avoid WordPress.

For many people, WordPress is the right tool. For teams that need editorial workflows, non-technical publishing, plugins, themes, and a familiar admin interface, it can make a lot of sense.

It is just not the way I like to manage my own websites.

For me, a website is still a software project. Even when it is small. Even when it is personal. Even when it is just a blog or an open source landing page.

I want clean files, modern UI, version control, automation, and a deployment process I can trust.

That is how I manage more than eight websites without WordPress, without a traditional CMS, and without turning every project into a huge infrastructure exercise.

Simple where it should be simple.

Automated where it should be automated.

Custom where it actually matters.