How GoodCraft uses AI

Why I'm writing this

I run GoodCraft out of Knoxville. The work has been across architecture and engineering firms, specialty manufacturers, logistics companies, multi-location services, and a few one-person operations with a portfolio of brands. Some three-person teams, some four-hundred-person firms. What unifies them isn't size, industry, or geography — it's manual work that should already be software, and someone holding the gap together by hand.

Most consulting sites pitch generic AI receptionists, AI SDRs, AI sales coaches — features that demo well and fall apart at the boundaries your customers actually care about. Owners, COOs, VPs of Operations, and the Director-of-Operations who's quietly the CFO too have been pitched enough of that in 2026 to spot it a mile out. So I'm not going to do that. Here's the actual stack.

Short version: if you're thinking about hiring me, you should know what's behind the work. And I want to be on record about which tools I trust, which ones I don't, and which ones I won't recommend until they earn it.

What I use to do the work

The work splits into three buckets: shipping client systems, running my own operations, and writing. Each one has a different tool mix.

For shipping client systems, the core stack is Claude Code (Anthropic), Cursor for tight code editing loops, a few open-source agent runners I've forked or written from scratch, and a small set of automation tools I configure into customer environments. The thing AI is good for here is not 'recreate this from a screenshot' or 'spin up a Lovable app for me.' It falls apart fast on real systems. The thing it's good for is 'here's the stack, help me wire these specific small details up the right way over time.'

Concrete example. On a recent transportation client, we had a list of customer locations that needed to land in the CRM with the right metadata, get plotted on a map, and have specific data points pulled off each location. The right move wasn't 'here's an image of what I want, recreate it.' That doesn't actually work. The right move was: here's the stack, here's the data shape, walk me through plotting these the right way, validating each one, wiring the CRM fields. Small, specific, correct. The 'tool' is the configuration plus the guardrails, not the LLM underneath.

For running my own operations, I lean on Customer.io for messaging, a Laravel stack for most internal tools (this site too), and a personal agent that runs morning briefings, monitors a few systems, and does first-pass research before I read it.

Quick note on Laravel. The default ask of any AI tool gets you Next.js or pure Node or pure React. For a team of one trying to maintain something for years, that's not the right answer. Laravel is. PHP backend, batteries included, easy to reason about by yourself a year from now. I use a lot of Laravel products and ship a lot of Laravel code, and I'd recommend it to most owner-run teams over the JS-first defaults.

For writing, this essay included, I draft in Obsidian, use Claude as a sparring partner for argument structure, and never let it write the final voice. AI writing has a tell. Buyers can hear it. So can I.

What I don't trust yet

Most no-code AI agent builders. The ones marketed to non-technical operators usually solve the easy 30% of a workflow and leave the gnarly 70% to a human. The real cost is the maintenance debt. Every time the workflow changes, somebody has to go remember how the no-code config worked. That's not 'no-code.' That's 'someone-else's code.'

Generic AI receptionists, AI SDRs, AI sales coaches. They work great in a demo and fall apart at the boundaries that matter to real customers. I've seen too many bookings and tickets get dropped because the AI sounded right but did the wrong thing.

Hyper-local fine-tuning before the prompt engineering is settled. Most teams don't have a fine-tuning problem. They have a prompts-and-context problem, and fine-tuning is the expensive way to solve the cheaper one.

The shape of the actual work

Every engagement starts the same way: a paid Working Session, then (when it makes sense) a Diagnostic. Two weeks of looking. Map workflows, list tools, find the manual operations, rank the opportunities. The only difference between buying just the Diagnostic and going further is what I do with the map after.

When the work moves to a build, I pick the highest-leverage item and start. Not in slide decks. In the actual environment. The goal is something running in production inside four weeks, usually a configured agent for one specific workflow, attached to one specific tool, that the team actually uses.

From there, the work compounds. Each working agent unlocks the next workflow it can connect to. The team starts noticing things they want to automate that they wouldn't have thought to ask for on day one.

When I leave, what stays is real software. Spec, tests, guardrails, escalation paths, plus a short ops runbook the team can read. Maintained with normal expectations, not babysat.

What I won't ship

An AI feature that exists because it's the AI feature, not because it solves a real problem. Most of the AI fatigue I'm seeing in the market is from teams who got pushed into AI for AI's sake. I'm allergic to it.

An automation that depends on an LLM where deterministic code would do. If the workflow is rule-based, write the rules. The LLM is overkill, expensive, and adds non-determinism you don't need.

A leave-behind that requires a maintenance contract to keep running. The point of the work is independence. If the team needs me on call to keep the lights on, I haven't done the job.

What I'm still learning

A few things I'm still figuring out, in public. Multi-agent orchestration patterns when the agents need to negotiate with each other. The right boundary between 'agent does it' and 'human does it' for high-judgment workflows. How to communicate AI confidence to non-technical operators in a way that's useful instead of confusing.

If you ask me about something I don't know yet, I'll tell you. That's table stakes for an honest practitioner in 2026. Not a weakness.