"It's Not Working" — Hex Troubleshooting Guide

You tried the hex. You picked your six tools. You cut the subscriptions. You went through the audit, made the hard choices, and committed to the constraint. And now — two weeks in, maybe three — something isn't working. A task comes up that your hex doesn't seem to handle. A workflow that used to be smooth now has a gap. You hit a wall, and the temptation is to conclude that the hex was a nice idea but doesn't work in practice.

This article is for the person who's actually trying — not the person arguing with the concept from the sideline, but the person who adopted the hex and hit a wall. The wall is real. The question is whether the wall means the hex is wrong, or whether it means there's a specific, diagnosable problem with your implementation that has a fix. In my experience — having worked through this with dozens of people — it's almost always the second.

The Three Types of "Not Working"

When someone tells me the hex isn't working, the problem is almost always one of three things: a skill gap, a comfort gap, or a genuine gap. Diagnosing which one you're dealing with is the first step, because each has a different fix.

The skill gap is the most common. You cut a tool that handled a specific task, and now you're trying to do that task with a tool that's still in your hex — but you don't know how. You used to use Grammarly for editing and now you're trying to use Claude, but your editing prompts are weak and the output isn't as good. You used to have a dedicated image tool and now you're using GPT image generation through your LLM, but the results aren't matching what you got from the specialist tool. The problem isn't that the hex tool can't do the job. The problem is that you haven't learned how to make it do the job.

Skill gaps feel like tool gaps. "Claude can't edit as well as Grammarly" is a statement that feels true when your Claude editing prompts are basic. But someone who's spent a month learning Claude's editing capabilities — building custom prompts, using projects with style guides, iterating on the workflow — gets results that match or exceed Grammarly for most use cases. The skill gap is temporary. The solution is to invest the time you're saving on tool management into learning the tools you kept.

The comfort gap is subtler. You cut a tool and you miss it — not because the work requires it, but because you were used to it. The interface was familiar. The workflow was automatic. You didn't have to think about it. Now you're doing the same task in a different tool, and it feels harder. Not because it is harder — because it's unfamiliar. The discomfort of unfamiliarity masquerades as a performance problem.

The comfort gap resolves itself with time — usually two to three weeks of consistent use. The new tool becomes familiar. The new workflow becomes automatic. The discomfort fades. But during those two to three weeks, the temptation to re-add the old tool is intense. The fix is to commit to the timeline. If after three weeks the new workflow is still measurably worse — not less comfortable, measurably worse in output quality or speed — then you may have a genuine gap. But wait the three weeks before deciding.

The genuine gap is the rarest of the three, but it exists. Sometimes the hex audit was wrong. Sometimes a capability that seemed redundant turns out to be essential. Sometimes the tool you kept for a slot genuinely can't handle something you need. When this happens — when you've invested time in the skill, waited out the comfort adjustment, and the gap remains — the hex framework accounts for it.

Diagnosing Your Specific Problem

When you hit the "not working" wall, run through these checks in order. Don't skip to the third one. Most people jump to "I have a genuine gap" before they've ruled out the first two, and that's how tools creep back into the stack.

Check 1: Is this a skill problem? The question to ask: have I spent at least five hours learning how to do this specific task with my current tool? Not five hours using the tool generally — five hours focused on this specific capability. If the answer is no, you haven't hit a wall. You've hit the learning curve. The fix is dedicated practice. Watch a tutorial. Read the docs. Ask in a community forum. Build a custom prompt or workflow. The time you invest here pays compound returns because every skill you develop with your hex tool is a skill you keep — unlike the tool you were about to re-add, which would have consumed ongoing bandwidth without building any transferable capability.

Check 2: Is this a comfort problem? The question to ask: if I'm being honest, could I produce the same output with my current tool — just more slowly or less conveniently? If the answer is yes, the gap is comfort, not capability. The fix is patience. Give yourself the full three-week adjustment period. Track your output during that period. If your output quantity and quality hold steady despite the discomfort, the discomfort is the adjustment cost of a better system, not evidence that the system is broken.

Check 3: Is this a real gap? The question to ask: I have spent time learning this tool, I have waited out the adjustment period, and I still cannot produce the output my work requires. Is that true? If the answer is genuinely yes — and you've been honest with checks 1 and 2 — then you've found a real gap. The hex isn't serving your work at this point, and it needs adjusting.

Fixing a Real Gap

If you've diagnosed a genuine gap, the fix is not "add back the old tool." The fix is a structured adjustment that maintains the constraint while addressing the problem.

Option 1: Swap, don't add. If a capability is missing from your hex, ask whether another slot is underperforming. Maybe the tool in your data/knowledge slot isn't pulling its weight — you use it twice a month and it could be handled by your LLM's built-in capabilities. Free that slot and fill it with the tool that addresses your gap. The hex stays at six. The composition changes. This is the most common fix and the one that works best, because it maintains the discipline of the constraint while adapting to reality.

Option 2: Expand to seven with justification. If no slot is available for swapping — every tool in your hex is producing essential, unique output — then adding a seventh tool is legitimate. But do it formally. Write down: what the tool does, why none of your current six can cover it, what output it produces, and how often you'll use it. This isn't bureaucratic theater. It's a check against impulse. If you can't write a compelling justification, the gap probably isn't as real as it feels. If you can, you've made a deliberate choice — which is what the hex is about.

Option 3: Accept a manual workaround. Sometimes the gap is real but small — a task that comes up once a month and takes 30 minutes to do manually. Adding a tool for a task you perform twelve times a year is almost never worth the bandwidth cost. The manual workaround is the right answer for low-frequency gaps. Not every task needs a tool. Some tasks just need 30 minutes and a straightforward process.

The Patterns That Predict Sticking Points

After working through hex implementations with enough people, I've noticed that certain sticking points recur predictably. Knowing them in advance doesn't prevent them, but it does prevent you from concluding "the hex doesn't work" when what's actually happening is a normal adjustment.

Week 1-2: The tool grief period. You miss the tools you cut. Every task feels harder than it should. You're slower than you were. This is normal. It's the cost of any workflow change, and it passes. The danger is re-adding tools during this period "just temporarily." Temporary re-additions become permanent re-additions, because once the tool is back, removing it requires going through the grief again.

Week 3-4: The capability discovery period. You start finding features in your hex tools that you didn't know existed. Claude can do something you thought required a separate tool. Your automation platform has a connector you'd never tried. This period is where the hex starts paying dividends — the constraint forced you to go deeper, and depth reveals capability that was always there but invisible when you had 14 tools at surface level.

Month 2-3: The edge case period. The daily workflow is smooth. But you hit an unusual task — quarterly report, new project type, one-off client request — that doesn't fit neatly into your hex. This is where the "is it a real gap or a comfort gap?" diagnosis matters most. Most edge cases can be handled by your existing tools with some creativity. A few can't, and those are the cases where the structured adjustment protocol applies.

Month 4+: The steady state. The hex is running. You've gone deep on your tools. The quarterly review surfaces minor adjustments but no major overhauls. You notice something unexpected: you're spending more time on the work and less time thinking about tools. That was the point.

When to Ask for Help

The hex is a self-directed framework. Most people who commit to it can implement it on their own, using the PDF, the articles on this site, and their own discipline. But some people hit walls that self-diagnosis doesn't resolve. The tool audit keeps coming back ambiguous. The skill gap feels bottomless. The quarterly review reveals problems but not solutions. The stack keeps creeping back up despite good intentions.

If that's where you are — genuinely trying, genuinely stuck — there's a specific kind of help that works for this problem. Not a course. Not a tutorial. Not another article. A session where someone who's done this before sits with you, looks at your actual work, and helps you figure out what's wrong with your specific implementation.

That's what the Done-With-You sessions are built for. Three working sessions where we audit your actual week, map your actual outputs, build your hex together, and troubleshoot the sticking points in real time. You leave with a working hex — not a PDF about the concept, but a configured stack that runs. It exists because the hex is simple to understand and sometimes hard to implement, and the gap between understanding and implementation is exactly where focused help makes the difference.

If you're stuck and you've tried everything in this article, that's the next step. Not because the hex failed — because your specific implementation needs someone with pattern recognition across dozens of hex builds to see what you're not seeing. The constraint works. The implementation is where help matters.

The Most Important Sentence

If you take one thing from this article, take this: "not working" is not the same as "not comfortable." The hex will feel wrong for the first two to three weeks. That's the adjustment. The question isn't whether it feels right today. The question is whether your output — the things your work produces — is better, worse, or the same after 30 days. If it's better or the same with fewer tools and less overhead, the hex is working. Even if it doesn't feel like it yet.

This article is part of the Hex FAQ series at CustomClanker.

Related reading: The Hex Explained, Building Your First Hex, The Done-With-You Model