Rebuilding My Web Stack in 2026 (Part 2): Tools, Environments, and Lessons Learned

In Part 1 of this Developer’s Journal series, I walked through the decision to finally shut down my old legacy server and sunset a group of aging web sites.

That wasn’t just a technical decision. It was a personal one.

It meant letting go of years of work. Old projects. Old methods of how I used to build things. Some of that code dated back over a decade (or more!). Some of it probably should’ve been retired a long time ago. But I stubbornly kept them running up until Dec of 2025.

And once that decision was made, there was no turning back.

Now came the real question:

If I’m rebuilding everything… how do I do it the right way for the future?

That meant stepping back and looking at every part of the stack—from code to infrastructure—with fresh eyes.

This part focuses on the tools, environments, and real-world lessons learned while moving from legacy hosting to a modern cloud-based web platform.

Back to the Basics with PHP

PHP was where I started, mostly out of instinct.

It had been the backbone of so many of my earlier projects, and jumping into PHP 8.x felt, at first, like reconnecting with something familiar.

But pretty quickly, I realized this wasn’t the same PHP I remembered. It had grown up. Faster. Cleaner. More structured. More opinionated about how things should be done. That’s a good thing—but it comes with a learning curve

I had to get comfortable with:

• Namespaces actually being part of everyday structure
• Composer becoming a requirement, not an option
• Deprecated functions no longer quietly “working anyway,” but outright breaking things
• Writing code that’s not just functional, but modern and maintainable

It wasn’t about relearning PHP from scratch.

It was about unlearning just enough of the old habits to make room for better ones. I like where PHP has come, so it was a familiar and welcome return to something I knew so well.

JavaScript: It Never Stops Evolving

Despite having shifted my career focus to the front end for a period starting in 2013, JavaScript has always felt like something I’m trying to keep up with, because honestly, it never stops evolving or moving forward.

Over the years, I had already spent time deep in:

• Node.js
• Express back-ends
• Building and using NPM packages
• Modern front-end tooling with frameworks like Angular

So I wasn’t coming in cold. But even still, the ecosystem today is massive. Frameworks. Libraries. Build tools. Runtimes. Package managers. It’s a lot. And it grows just a little more every day.

At one point, I had to stop and ask myself a simple question:

Do I really need all of this?

That’s where I landed on a decision that might surprise some people.

For this rebuild, I chose to go mostly with Vanilla JavaScript. Not because frameworks like Angular or React aren’t powerful. They absolutely are.

But they come with trade-offs:

• Constant updates
• Dependency chains you don’t fully control
• Long-term maintenance overhead

And one of my main goals with this rebuild was simplification.

Modern JavaScript, especially ES6 and beyond, has come a long way. Browsers are more capable than ever. For what I’m building right now, I don’t need a full framework layer.

So I made the call:

Keep it lean. Keep it simple. Keep it maintainable!

Returning to MySQL (With a Better Perspective)

Coming back to relational databases after spending so many years with NoSQL systems like MongoDB was… interesting. On one hand, it felt entirely familiar.

On the other, I realized how much more intentional modern database design has become.

In the past, I leaned toward flexibility:

• Looser schemas
• Minimal indexing
• A focus on getting things working quickly
• Sometimes overbuilding by putting option lists inside the database

Now, the mindset is different. You think about:

• Structure first
• Performance from day one
• Proper indexing as a requirement, not an afterthought

It wasn’t a difficult transition, but it was definitely a more disciplined one.

The Biggest Shift: From Hosting to Infrastructure Ownership

This is where things really changed. My old sites lived in a world where infrastructure was mostly invisible.

Shared hosting. Grid hosting. Control panels. Click a few buttons, upload some files, and you were live. It worked. And for a long time, it was enough. But it also came with limits.

Limits on performance. Limits on flexibility. Limits on what you could actually build. No root access meant you had to work with what you were given.

Moving to a modern cloud host flipped that entire model on its head. Suddenly, nothing was abstracted anymore.

I had:

• Full control
• Full access
• Full responsibility

And that last one is the part that hits you the hardest.

Enterprise Experience… Without the Safety Net

Here’s the interesting part. None of this was new to me. I’ve worked with cloud infrastructure in enterprise environments before. I understand the concepts. The architecture. The tooling.

But in those environments, you have:

• Platform teams
• Security teams
• DevOps professionals
• Established pipelines
• Guardrails everywhere

This time, it was just me. Which meant translating all of that enterprise knowledge into something practical, secure, and manageable for a single developer.

No shortcuts. No safety nets. That was a completely different experience.

Back to the Command Line Again

And with that shift came something I hadn’t leaned on heavily in a while: the command line.

SSH sessions. Package installs. Apache configs. File permissions. APT installs and updates. systemctl commands.

These were things I had done before, but not owned end-to-end like this, in a long time. And there’s a difference between using a system and owning it.

Owning it means:

• You break it, it stays broken until YOU fix it
• You secure it, or it’s vulnerable and it WILL get exploited
• You maintain it, or it falls behind and also becomes vulnerable.

It forces a different level of awareness. In today’s AI powered world, you have no choice but to absolutely prepare for the worst and lock down each and every part of the pipeline. Because if there’s even the smallest of gaps, someone WILL find a way to exploit it.

Building a Real Development Workflow

To make all of this actually work, I had to set up a proper development pipeline.

And not just one environment mind you—but THREE:

• A local Windows-based WAMP setup (my primary dev tool)
• A Linux dev server running on an old laptop
• The live production environment in the cloud

All tied together through GitHub. On paper, it sounds clean. In reality, each environment had its own quirks.

Things that worked locally didn’t always work in production. Database configs behaved differently. Permissions caused issues. Version mismatches popped up constantly.

At first, it was complicated and messy.

But it forced me to tighten everything up. After rolling up my sleeves more than a few times and doing a lot of trial and error, I eventually got all three environments lined up on the same versions, the same tools, and the same general permissions model.

Building All of This… While Life Changed

At the same time all of this was happening, life shifted too.

I started my newest dev efforts while I was going through an expected period of unemployment. And right as I was preparing to spin up my new cloud server, I started a new job. It wasn’t remote anymore. The commute and reality of working four out of five days in an office came roaring back.

And suddenly, time became a much more limited resource. That changed how I worked entirely. No more long, unstructured coding sessions. No more meandering research sessions and POC and trial experiments.

Everything had to be:

• Focused
• Intentional
• Planned

It wasn’t always easy, but it made the work sharper. And that leads directly into the next topic…

The Reality of AI in Modern Development

If there’s one thing that truly separates this rebuild from anything I’ve done in the past, it has to be the inclusion of AI into my toolbox.

Tools like ChatGPT and GitHub Copilot became an almost essential part of my daily workflow. And I call them tools. Because they not replacements for coding or developer skills, but accelerators.

They helped me:

• Quickly build complex architectural and development plans
• Validate ideas
• Fill in gaps when working out complex problems
• Explore alternate approaches
• Speed through repetitive work

Things that used to take hours sometimes took minutes.

But, and this is important, they’re not perfect.

AI will absolutely:

• Hallucinate problems, solutions and code that doesn’t exist
• Suggest things that don’t work right
• Send you down the wrong path if you’re not paying attention

So you still need experience—and a lot of due diligence. You still need judgment. If anything, AI makes that more important, not less.

The Real Takeaway

At the end of all of this, the biggest change wasn’t technical. It was mental.

I stopped thinking:

“How do I keep my old sites and server running a little longer?”

And started thinking:

“How do I build this so it’s solid now—and ready for what comes next?”

That shift changed everything. It was a welcome and necessary one. And I’m excited to have a fully modern, future-ready platform to build and grow on.

What Comes Next

At this point:

• The old server is gone
• The new cloud environment is in place
• The workflow is dialed in

After months of rebuilding, debugging, and tightening everything up… I was finally ready to get the server ready for all sites to be fully public once again.

In Part 3, I’ll walk through the new ecosystem:

• What’s live now
• What each site is doing
• What’s still in progress

If you’ve made a similar move—into cloud, modern stacks, or adopted AI-driven workflows—I’d love to hear how it’s gone for you.

Previous Article:

Part 1 – Letting Go of My Legacy Sites and Server

Coming up next:

Part 3 – Launching the New Ecosystem: What’s Live Now

_{Code Photo by Ferenc Almasi on Unsplash}. _{Servers Photo by Domaintechnik Ledl.net on Unsplash}