Builder Notes: AI Tools I Actually Use

A tour of my working stack: Claude Code, n8n vs. Make, open-source agents, and how I decide what earns a spot — every tool tested on my own three companies.

Key takeaways

My stack philosophy: boring core, sharp edges

Bench one: Claude Code

Bench two: workflow automation platforms

Bench three: AI tools and models

Bench four: open-source agents

How tools earn a spot on the bench

The scrap bin: what didn't make the bench

Where to start, by situation

Every builder I respect has a workshop, and every workshop tells you the truth about its owner. Not the tools they bought — the tools with worn handles.

This page is a tour of mine. I run three companies — an MSP, a business phone company, and an AI automation agency — which means I get to test tools twice: once on my own operations, and again on client deployments where I'm accountable when something breaks at scale. Fair warning on bias: my agency sells implementation of some of what's below. I'll flag it where it matters, and nothing here is sponsored — every opinion was paid for in my own time and, occasionally, my own outages.

The hands-on write-ups below are the deepest content on this site. This page is the map: what's on each bench, why it earned its spot, and where to start depending on what you're building.

Two rules govern everything I run.

The core stays boring. Identity, email, files, backups, phones, security — the layer everything else depends on — should be mature, vendor-supported, and dull. Nobody ever built a great company on an exciting backup solution. I keep the full picture of that layer in my SMB tech stack guide.

The edges stay sharp. On top of a boring core, I deliberately run bleeding-edge tools where the upside is real and the blast radius is contained: AI coding agents, workflow platforms, open-source agent frameworks. When a sharp-edge tool breaks, I lose an afternoon. When a boring-core tool breaks, I lose customers. Knowing which layer a tool belongs to is most of tool strategy.

One more rule, learned expensively: every tool is a workflow bet, not a product bet. I don't adopt tools because they're good; I adopt them because a specific workflow I care about gets meaningfully better. That framing kills most shiny-object purchases on contact — a great product that improves nothing I actually do is just a subscription with good marketing. It also means two companies can look at the same tool and both be right to disagree about it, which is why every comparison I write leads with "it depends on what you're doing" and then does the unfashionable work of specifying what it depends on.

Everything below lives on the sharp-edge benches, organized the way the workshop actually is.

The tool that changed how I work more than anything since the smartphone. Claude Code is an AI agent that lives in your terminal — it reads your files, writes code, runs commands, and executes multi-step work while you supervise. I came to it as an operator who codes, not a full-time developer, and that's exactly the audience it quietly serves best. It is also, not coincidentally, the tool I've written the most about, because six months in I keep finding new depth.

Start here if you're new:

Then go deeper — this is where the compounding returns live:

And the applied series, where it meets real work:

My editorial position, condensed: autocomplete tools make you faster at typing; agentic tools make you faster at finishing. That distinction is worth more than any feature checklist.

Before AI agents were interesting, workflow platforms were quietly doing the unglamorous work of making systems talk to each other, and they still carry most of the production load in every business I run or advise. If bench one is the power tools, this bench is the jigs and fixtures — less exciting, more load-bearing.

The perennial question is n8n or Make, and I've deployed both enough to have an earned answer rather than a preference:

One operator's note: the platform matters less than the discipline around it. An n8n instance with named owners, error alerts, and documentation beats a prettier stack with none of that, every time.

The fastest-moving bench, and the one where I re-evaluate most often. Model capabilities shift quarter to quarter; my picks are current as of the linked posts' publish dates, and I update the stack piece when my daily drivers actually change — not when a launch video is impressive.

A bias note that belongs on this bench specifically: I clearly work deeply in Claude's ecosystem — bench one is evidence enough. I hold the comparisons to the same standard anyway, and when a competitor wins a category in my testing, the post says so.

The bench I'm most excited about and the one I'd caution most people about, in the same breath. Open-source agent frameworks — Open Claw, Clawdbot, MCS servers — give you capabilities that commercial products either don't offer or charge enterprise prices for. They also hand you the keys, the liability, and the maintenance. Self-hosting an agent is adopting a very capable animal.

The Clawdbot and MCS shelf:

My honest position on this whole bench: the security posts are not the boring ones, they're the load-bearing ones. Every capability post above assumes you've read them. That's also the bench where the build-vs-buy line gets personal — running these is genuinely fun if you're wired that way, and genuinely a part-time job if you're not. If you read this section and felt tired rather than curious, that's useful information: it means you want the outcome, not the workshop — which is exactly the situation my agency's done-for-you workflow automation exists for. Disclosure repeated for the people skimming: that's my company.

People assume I chase new tools. It's closer to the opposite — the bar for getting into this workshop is high precisely because I try so many things that don't make it. My evaluation, in the order I actually apply it:

1. Does it survive a real task in week one? Not a demo — a task I already needed done. Tools get one honest week embedded in real work. Most fail here, and that's fine; the week was cheap.

2. What happens when it's wrong? Every tool fails. I care how: loudly or silently, recoverably or destructively, in ways I can see coming or not. A slightly weaker tool that fails loudly beats a stronger one that fails silently, every time, in every category.

3. What's the exit cost? Before I depend on anything, I ask what leaving looks like. Open formats, exportable data, and portable workflows keep vendors honest. This is half of why n8n and the open-source bench appeal to me despite their rough edges.

4. Does it compound? The best tools get more valuable as they accumulate my context, workflows, and muscle memory. Claude Code is the clearest example — month six is worth far more than month one. Tools that are the same on day 300 as day 3 are commodities, and I treat them accordingly.

5. Total cost, honestly counted. Subscription price is the visible sliver. Setup time, maintenance, the learning curve, and the cost of the eventual migration are the iceberg. Free tools are frequently the most expensive thing in the shop.

A workshop tour that only shows the keepers is a showroom, so here's the scrap bin — categories of tools that came in, got their honest week, and went back out. I'll spare specific vendors the naming-and-shaming (my testing is a sample size of my companies, not a lab), but the patterns are worth more than the names anyway:

The scrap bin isn't a graveyard of bad products. Most of these are good products that lost to my rule five: the total cost of adding them exceeded the marginal value over what the bench already held. That's the quiet math that tool marketing never shows you.

And the discipline that matters as much as choosing: when to switch. I switch when a tool caps a workflow I care about, when maintenance outgrows value, or when the category has genuinely moved on — and not because something newer is shinier. Switching costs are real; I budget roughly one meaningful stack change per quarter, because more than that means I'm collecting tools instead of building with them. Chasing every launch is how a workshop becomes a museum of abandoned enthusiasm.

I update this page as benches change. If a link's opinion conflicts with something newer here, trust the newer date.

I write these from the operator's seat — I run an MSP, a phone company, and an automation agency, and every tool above has been tested on my own businesses before I wrote about it. More on the blog or get in touch.

Frequently Asked Questions

What tools do you actually use every day?

Daily drivers: Claude Code for building and operations, n8n for production workflow automation, and Claude for analysis and writing. A tool must survive weeks of real work before earning daily status.

Should I learn n8n or Make first?

Make if you are non-technical and want results this week; n8n if you want self-hosting, control, and better economics at volume. The trade-offs are scored in the full n8n vs. Make comparison.

Is Claude Code only for developers?

No. It is an agent that happens to speak code — useful for operations, analysis, file wrangling, and automation glue. Non-developers face a steeper first hour, which the terminal and SMB guides address.

Are open-source AI agents safe for a small business?

They can be, with access controls, sandboxing, and monitoring — work that commercial products bundle and open source hands you as homework. Read the security guides before granting any agent real permissions.

How do you evaluate a new AI tool?

One real task in week one, then four questions: how it fails, what leaving costs, whether it compounds with use, and total cost beyond the subscription. Most tools exit at step one.