- Published on
How I Evaluate a Modern Web Stack
A dated check-in on the criteria I use to choose a web stack: durability, operability, agent access, and the cost of future change.
Stack choices are bets about the future. I evaluate them less by how quickly they produce a demo and more by whether a team can operate, change, and eventually hand off the resulting system. My criteria are durability, ecosystem depth, deployment clarity, access for automation and agents, and the cost of reversing the decision later.
My professional foundation is in open-source PHP content management systems, especially Drupal and WordPress. Working more directly with AI-assisted development gave me a useful reason to test those criteria against a different ecosystem, including React and Next.js.
This is a dated stack check-in, not a permanent recommendation. It records what I chose in October 2025, why the pieces fit the work, and what I would reevaluate as the surrounding ecosystem changes.
GitHub: The Hub
The backbone of my preferred stack is GitHub. This is the one part of the stack I don't optimize for portability. I find GitHub to be cost-effective, full-featured, and a platform I can rely on for the long term. I am paying $4/month for a Team account at GitHub to use the features I highlight below.
GitHub’s primary function is managed Git hosting, and it’s the industry standard for version control and collaboration. Beyond the basics, it offers a rich ecosystem of tools that are central to my setup:
GitHub Command Line Interface (CLI)
I use AI coding tools directly in the terminal and a key part of working with an agentic coding partner is having robust command-line tools the AI agents can interact with. The GitHub CLI is well-maintained, feature-rich, and makes it easy for AI agents (and me) to execute tasks directly from the command line.
GitHub Issues
GitHub Issues are a core feature within repositories used to track, plan, and discuss work. They're a flexible way to manage development and collaboration.
Anyone who has worked on my teams knows that rule number one before starting any coding is to “make a ticket.” This simple process ensures we document our intention before starting work. A well-written issue can be passed between contributors, support measuring outcomes against intentions, and serve as living documentation of the codebase.
Having this project management tool natively integrated with the code repository keeps everything connected and simple to use.
Continuous Integration / Delivery
GitHub's CI/CD features are excellent for automating workflows that respond to repository activity such as commits, merges, and pull requests. These automations are key to my development process - below is an outline of my process:
- Write code locally on a feature branch aligned to a GitHub Issue.
- Test local changes.
- Push the branch to GitHub.
- On the push activity a new environment is automatically updated with the code from that branch.
- Review and QA on that remote environment.
- Once approved, merge the branch via pull request.
- Following the merge the pull request and associated issue are automatically updated and closed.
The automated provisioning of a lower environment and release orchestration saves an enormous amount of time and keeps deployment friction low.
GitHub Pages
GitHub Pages is one of my favorite GitHub features and something I don't think enough people take advantage of. It's a static site hosting service that takes HTML, CSS, and JavaScript files directly from a repository, optionally runs a build process, and publishes a website with no separate hosting required.
GitHub Pages doesn’t support interpreted languages like PHP, so if your project requires server-side functionality, you’ll need an external host. For static websites, though (like this blog), it’s fast, reliable, and free.
Web Application and Database Hosting
For projects that require dynamic hosting or databases, I look for solutions that emphasize portability. If a service changes its pricing, features, or policies, I want the freedom to migrate quickly without major rework.
I initially used Vercel to host a Next.js application and found the developer experience fantastic. However, I've since chosen to migrate to Netlify and Cloudflare, which offer similar features and align better with my values. This transition highlights why portability matters, I have made architecture decisions prioritizing making it easy to move.
For databases and authentication, I've had a great experience with Supabase. It made adding authentication and authorization straightforward, and its web dashboard and SQL Editor are easy to use while still supporting advanced features like row-level security.
Conclusion
I’m prioritizing rapid prototyping and app development, and this stack is hard to beat. It keeps you close to your code, removes deployment friction, and scales as your project grows. The learning curve is reasonable, documentation is plentiful, and the productivity gains are immediate.
With this flow, I spend more time building and the tools fade into the background.