My Current Stack for Getting Things Done
Every year or so, I take stock of what I'm actually using day to day. Not what I signed up for, not what's sitting in my bookmarks bar collecting dust, but the tools I reach for when there's real work to get done. After more than a decade of building websites, running campaigns, and managing projects, my stack has gotten simpler, not more complex. That's intentional.
Here's what I'm running right now, why it works, and a few things I've stopped using that you might want to reconsider too.
Development: Keep It Close to the Metal
My editor is VS Code. It has been for years, and nothing has pulled me away. The extension ecosystem is mature, the Git integration is solid, and it stays out of my way. I don't need a full IDE. I need something fast that lets me write code and move on.
For version control, it's Git on the command line plus GitHub for remote repos. I've tried various GUI clients over the years, and I always come back to the terminal. Once you internalize the core commands, it's faster than clicking through menus.
On the web development side, I still lean heavily on plain HTML, CSS, and vanilla JavaScript for most client projects. I know that's not trendy. But for the majority of small business and portfolio sites I build, a static or lightly dynamic setup outperforms a framework-heavy approach in every way that matters: speed, maintainability, and cost. When a project genuinely needs a framework, I'll reach for one. But I'm not going to introduce build tooling and dependencies just to render a contact page.
For hosting, I've settled on a mix of Netlify and a straightforward VPS depending on the project. Netlify is hard to beat for static sites and simple deploys. For anything that needs server-side logic or more control, a basic Linux server with Nginx does the job without monthly surprises on the bill.
Analytics: Just Enough Data
Google Analytics 4 and Google Search Console. That's the core of my analytics setup, and honestly, it covers about 90% of what I need to know for most projects.
GA4 had a rough start, and I won't pretend the interface is pleasant. But it's stabilized, and the event-based model actually makes more sense once you stop trying to use it like Universal Analytics. I set up a handful of custom events that matter for each project, conversion tracking for the important actions, and I ignore the rest. The mistake I see most people make is tracking everything and reading nothing. Pick five metrics that actually inform decisions, and check those.
Search Console is underrated. It's free, it tells you exactly what Google sees, and the performance report gives you real keyword data that GA4 doesn't. I check it weekly for every active project.
I've tried Plausible and Fathom for privacy-focused analytics, and they're genuinely good products. For clients who want a simpler dashboard or have strong privacy requirements, I'll recommend them. But for my own work, the depth of GA4 plus Search Console is hard to replace.
Project Management: Simple Wins
This is where I've changed the most over the years. I used to run everything through elaborate project management platforms with custom fields, automations, dependencies, and Gantt charts. Now I use Notion for documentation and long-term planning, and a plain task list for daily execution.
Here's my honest take: most freelancers and small teams don't need Jira. They don't need Monday.com. They don't need a tool that takes longer to configure than the project takes to complete. A clear list of what needs to happen this week, who's responsible, and what's done is enough for 80% of the work I do.
For bigger client projects with multiple stakeholders, I'll use Basecamp. It keeps communication and tasks in one place, the client can access it without a learning curve, and it doesn't try to be everything. That matters more than features when you're coordinating people who have their own jobs to do and limited patience for new software.
Communication: Fewer Channels, More Clarity
Email is still the backbone. I use Fastmail for personal and client email because it's reliable, private, and the search actually works. For real-time communication with clients who prefer it, Slack works fine, but I'm intentional about setting expectations. Slack is for quick questions and updates, not for project decisions that need a paper trail. Those go in email or Basecamp.
For video calls, Google Meet handles everything I need. I've used Zoom plenty, and it's fine, but Meet requires no extra software for most people, and the quality is comparable. One less app to manage.
The biggest productivity gain I've made in communication isn't a tool. It's a habit: I batch my responses. I check email and messages at set intervals instead of reacting to every notification in real time. That single change has given me back more focused work time than any app ever could.
Automation: Targeted, Not Excessive
I use Make (formerly Integromat) for automations that actually save time. The key word is "actually." I've watched people spend hours building a Zapier workflow that saves them three minutes a week. That's not productivity, that's procrastination wearing a clever disguise.
My automations are boring and practical: new form submissions get piped into a spreadsheet and trigger a notification. Completed invoices update a project tracker. Weekly analytics summaries get compiled and emailed to clients who want them. Nothing flashy. Just fewer things to remember.
I also use cron jobs on my servers for maintenance tasks like backups, certificate renewals, and log rotation. Automation should be invisible. If you're constantly tinkering with it, it's a hobby, not a system.
What I've Stopped Using
A few tools I've deliberately moved away from: Trello (too shallow for real project management, too much overhead for simple task lists), Canva (fine for quick graphics, but I'd rather write good CSS), and any "all-in-one" platform that promises to replace five tools but does none of them well.
I've also stopped chasing new tools. Every week there's a new app that promises to revolutionize some part of the workflow. Most of them are solving problems I don't have. The tools that stick around in my stack are the ones that do one thing reliably and then get out of my way.
The Real Point
Your stack should serve your work, not the other way around. If you're spending more time configuring tools than using them to produce results, something's off. Start with the simplest thing that could work, and only add complexity when you hit a real limitation, not a hypothetical one.
That's the approach that's kept me productive and sane for over ten years. Your mileage may vary, but I'd bet the principle holds.