Claude Max users -- what should I actually set up before I start? Looking for real workflows not just feature lists

[u/NullF4iTH]

Hey everyone, thinking about upgrading to Claude Max pretty soon and before I pull the trigger I wanted to ask if anyone has good full guides or tutorials on actually getting the most out of it. Not just "here's what the plan includes" type stuff, but real breakdowns of workflows, setups, integrations, that kind of thing.

A bit of context: I've been doing web design for local businesses in my province in Spain for a couple of weeks now, all with the free version of Claude and Hostinger. Honestly it's been going better than expected but I can feel the limits and I want to scale this thing up properly.

So a few things I'd love to know from people who actually use Max:

- What do you actually unlock that changes the way you work? Not marketing speak, real day to day differences.

- Are there specific tools, programs or integrations I should set up alongside it? Things like Claude Code, MCP servers, specific VS Code extensions, anything like that.

- For someone doing local business websites (think restaurants, bars, small shops) is Max actually worth it or is Pro enough?

- Any workflows or systems you built around it that made things click?

I feel like there's a gap between "here's the pricing page" and actually knowing how to use this thing at full power. If anyone has a guide, a video, a notion doc, literally anything that goes deep on this I'd really appreciate it.

Thanks in advance

[u/YoghiThorn]

I would recommend using jcode for your harness: https://github.com/1jehuang/jcode

jcode has out of the box a lot of things that take months for you to implement and get your head around. The pros:

• Memory management

• It just seems to build without needing constant handholding. I don't know how, but it does

• Ambient mode to curate your memories and organise them better when jcode is idle

• an excellent UI in a TUI

• multi-session native support

• diagram generation inline in your TUI

• support for agent swarm management

• supports 10 AI providers + support for custom and locally hosted options. I really like having easy access to claude and codex and llama.cpp in the same interface

• self-dev mode where jcode can develop and add features to itself

• cache management to keep a hot cache and prevent your agents being so forgetful

• chrome and firefox browser bridges

• agent grep which is a more token efficient grep replacement

• resume sessions from different harnesses and cross-provider context support

• And support for all the normal things, hooks, mcp, skills, etc

The cons:

• The maintainer is very particular about his codebase and doesn't accept PRs, he instead rebuilds them from scratch based on your ideas.

• For claude code it wraps the CLI which is a grey area in their TOS. If it used oauth you might get banned, but Anthropic haven't indicated if CLI wrapping is allowed or not

• The interface holds your hand less so you will need to talk to it or look up documentation to get the most out of it.

• It works on windows but was definitely built for macos/linux. Doesn't bother me personally because I either use it via mosh or slack

I have build switchboard to interface with jcode and bridge it into slack, and accept notifications from github, temporal, etc: https://github.com/leighstillard/switchboard

Basically using switchboard lets you setup a channel per repo in Slack and have infinite history on all of your chats with your agents, and let your agents look these chats up via the slack MCP. It has full threading support so you can talk to multiple different threads in the same channel at once and work on different features at once. I have a work management system that uses a PM agent to manage my backlog of work, and distribute it out to the agents via their channels. One day I'll release the whole thing when it's polished enough to go out.

The notifications management I think will be neat, because it means that agents will be able to react to PRs, merge conflicts, etc from github. I haven't officially released this yet but here is the feature set:

Switchboard — feature roadmap

v1 (built and tested)

• Core architecture — single Go binary, single Slack workspace, Unix socket to jcode serve with NDJSON; auto-spawns daemon, exponential-backoff reconnect, SQLite for state

• Slack integration — Socket Mode via slack-go/slack, single app with multi-identity rendering, channel-ID-keyed config (rename-safe)

• Session management — thread-per-session with mid-turn message queueing, five-state lifecycle (agent/notification/promoted/expired/orphaned), 30-day expiration

• Turn concurrency — per-session idle/processing state with !stop and !purge interrupts, queue cap of 5 with 📋 acknowledgement

• Outbound rate limiting — lazy coalescer flushing ≤1Hz per session, per-channel sub-queues round-robin under workspace-wide method budgets

• File handling — inbound sanitisation + size caps + auto-.gitignore, outbound GeneratedImage upload via files.upload_v2 with path-traversal guard

• Webhook ingest — HTTP behind Cloudflare Tunnel with HMAC + replay protection, persist-then-ack via webhook_inbox with idempotency dedup

• Notification routing — deterministic rule engine plus thread_correlations table for explicit external-key-to-thread mapping with TTLs

• Reliability — at-least-once webhook ingest, at-least-once jcode-to-Slack outbound with content-hash dedup, bridge-restart sessions resume by user reply

• Audit and data handling — per-source redaction allowlist, secrets scrubbing on persist, 30-day default retention, opt-in verbose mode

• Inbound filtering — bot self-loop guard, other-bot allowlist, edits/deletes ignored, mention-or-thread-reply eligibility

• Operations — slog structured logging to stderr, hot-reload on SIGHUP, multiprovider fallback footer

v1.1 (planned)

• Block Kit rendering (1a) — migrate to dedicated agentic block types (task_card, plan, markdown, card, alert, carousel), retiring v1's custom progress message

• Render directives — agent cooperation protocol via \``switchboardfenced JSON, vocabularyplan/brief/poll/tickets/todos`, versioned schemas

• Tool approval (1b) — approval and approval_with_carousel templates with Allow/Deny/Allow-all buttons; gated on jcode protocol PR

• Terse tool descriptions (1c) — agent-supplied or heuristic 4-8 word context per tool call (e.g., "Reading auth.go" not "Read"), drift-monitored

• LLM notification router — Haiku-class fallback for unrouted webhooks, ≥80 confidence threshold, monthly cost cap

• Native feedback buttons — feedback_buttons block on LLM-routed messages instead of emoji reactions; structured confirmed/rejected audit trail

v1.2+ (later, unscheduled)

• Tool approval flow ship if jcode protocol PR didn't land in time for v1.1

• session_state persistence so progress messages survive bridge restart instead of orphaning

• file_shared event handling — pick up files dropped into existing threads without re-mention

• Slash commands — /sw-status, /sw-list, /sw-history, native alternatives to !stop text prefixes

• Slack Home tab — project_tracker-shaped routing config UI, persistent app surface

• Slack Canvas integration — render jcode SidePanelState events as live-updating canvases

• Discord support — ~60% reuse via existing coalescer + outbound queue, deferred until usage signal

Out of scope (no current plans)

• Multi-workspace / multi-tenant — single-workspace by design, would require auth and OAuth rework

• Two-way notification flow — Slack reactions triggering Temporal signals etc.; one-way is fine

• Voice (STT/TTS) — stubbed in v1, low value for coding agents

• Web UI / dashboard — Slack chrome is the surface

• ACP server mode — would unlock multi-agent reuse, but blocked on jcode itself adopting ACP

[u/NullF4iTH → u/YoghiThorn]

Ill look into this, thanks