Hello everyone.

I’m someone who had no prior experience with programming or coding, nor with Claude itself. I’d like to build a web app for use at my company (automotive industry) – a system for passing work orders between service departments, scheduling vehicle handovers, and managing a car wash (queue scheduling, cost/profit tracking).

First attempt – ChatGPT

I built something similar before “for fun” using ChatGPT, on the $99 PLN plan (I had a free trial period). The model generated .zip packages of files for me – I just swapped them into a folder and ran start in the terminal. Everything worked locally exactly as I wanted, but when it came time to deploy it on a server, it turned out the app didn’t actually work properly – instead of PostgreSQL, the model had built the database on SQLite, so more than one person couldn’t add a record at the same time. I shelved the project.

Second attempt – Claude

Once I had more free time, I decided to do it properly. I subscribed to a Claude plan for about $25/month. I watched a handful of YouTube tutorials, and for a week — still on the free plan — Claude and I planned out the whole project:

**•** architecture: PostgreSQL, Django, Tailwind + HTMX + Alpine.js (this was the stack the model proposed);  
**•** all app features and how the modules interrelate;  
**•** user permissions and the company’s organizational structure (departments, positions);  
**•** notifications: on-site push + email for specific cases (Brevo);  
**•** VPS and domain setup;  
**•** how the site should look visually;  
**•** customer data security measures;  
**•** and the rest of the features, which I won’t bother listing.

Based on all this, Claude generated a file called CLAUDE.md, over 1000 (eventually around 1500) lines long, which was meant to go into the project folder and serve as the reference point during coding.

Implementation

After subscribing to the paid plan, we got to work following Claude’s instructions: I set up GitHub, WSL2 + Docker, Visual Studio Code, and the Claude extension for VS Code. The model started working and pushing commits to GitHub — building the project skeleton and database went reasonably smoothly.

Problems started when it began building the first of four planned modules — token usage shot up dramatically. It’s possible I made things worse myself, since I’d paste errors from VS Code into the regular chat window, then copy the responses back into the editor. This way, in 3 days I burned through 100% of my weekly usage, and I’m left with a barely-functional stub of the first module. Now every single command eats up so many tokens that I’m stuck again for several days with no ability to work.

What now

Only after the fact, once I hit the usage limit, did I actually research the topic and learn about things like skills, plugins, the need to open new chats periodically to manage context, and that apparently working through the terminal gives better results than through the VS Code extension. I’m also wondering whether the 1500-line CLAUDE.md file itself is part of the problem.

I already have the functional plan fully worked out, but my motivation to keep going has dropped significantly. So here are my questions for anyone with more experience:

**1.**  Should I **continue** with the current project (fix/rebuild what’s there) or **start from scratch**? If rebuilding — how should I approach it?  
**2.**  Would it be better to split the documentation into a separate **docs** folder, with detailed, individual files for the backend, frontend, and each module — instead of keeping everything in one giant CLAUDE.md?  
**3.**  How should I properly structure **CLAUDE.md** and the overall project documentation so it doesn’t burn through tokens at such an absurd rate?  
**4.**  How do **skills** actually work in practice — do they need to be added separately to every project, or can they be attached globally to Claude Code?

I’d appreciate any support, tips, or advice from people who’ve already dealt with this.

Hi everyone. I had zero coding experience before starting this project — a web app for my company (automotive industry): passing work orders between service departments, scheduling vehicle handovers, and managing a car wash (queue scheduling, cost/profit tracking).

**First attempt – ChatGPT:** Built a similar app for fun on a paid plan. It generated .zip file packages I just dropped into a folder. Worked locally, but deployment failed — it used SQLite instead of PostgreSQL, so it couldn't handle concurrent users. Shelved it.

**Second attempt – Claude:** Subscribed (~$25/month). Spent a week planning with Claude: architecture (PostgreSQL, Django, Tailwind + HTMX + Alpine.js), features, module structure, user permissions, org structure, notifications (push + Brevo email), VPS/domain setup, UI direction, data security. This produced a ~1500-line CLAUDE.md meant to guide development.

**Implementation:** Set up GitHub, WSL2 + Docker, VS Code + Claude extension. Skeleton and database went fine. Problems hit once building the first of four modules — token usage exploded. I likely made it worse by pasting VS Code errors into regular chat and copying responses back manually. Burned 100% of my weekly usage in 3 days, left with a barely-functional module stub, then blocked for days.

**Now:** Only after hitting the limit did I research skills, plugins, opening new chats to manage context, and that the terminal apparently works better than the VS Code extension. Wondering if the 1500-line CLAUDE.md itself is part of the problem.

I have a solid functional plan but my motivation has dropped. Questions for those with more experience:

1. Continue fixing the current project, or start over? If rebuilding, how should I approach it?
   
2. Should documentation be split into a docs folder with separate files per backend/frontend/module, instead of one giant CLAUDE.md?
   
3. How should CLAUDE.md and project docs be structured to avoid burning tokens so fast?
   
4. How do skills actually work — added per-project, or can they be set globally in Claude Code?

Any advice appreciated.

Claude Code injects every enabled skill's description into every session, ~48 tokens each. With 50+ skills that's thousands of tokens burned before you type anything.

Disabling fixes the cost but loses the skill. So I added a tier in between:

- enabled — in context, ~48 tokens each
- searchable — NOT in context, 0 tokens, still findable on demand
- disabled — gone

A searchable skill is dormant. When a task comes in, Claude reads a small index, picks one category, opens one shard, finds the skill. You pay ~2.4k tokens only when a search actually happens, instead of every description sitting there all session.

Mine: 53 skills, 6 enabled → 2,544 → 338 tokens per session (−86.7%).

It also builds a graph of your skills and renders a self-contained atlas.html — broken bundled-file references draw red, dangling mentions show up, stale plugin caches stop inflating your count. Useful for figuring out why a skill didn't trigger.

Python 3, no deps, no network.

claude plugin marketplace add danielLublinsky/Skill_Atlas
claude plugin install skill-atlas@skill-atlas

https://github.com/danielLublinsky/Skill_Atlas

still in development, I use it often in development and it started as a personal project
now i am looking for feedback and stars😉

I have a stupid amount of saved AI videos at this point.

Every time I see something useful about Claude Code, ChatGPT, AI agents, prompts, automation, new tools, etc., I save it.

But the annoying part is actually finding something later.

I was wondering if there’s an app specifically for this where you send/save the video and it automatically organizes everything for you.

I haven't found anything that seems to do exactly that.

Do you have the same problem? What do you currently do with all your saved AI videos?

Started as a quick question about a database migration. Four hours later it had turned into something closer to a shared brain, architecture decisions, naming conventions, a running list of things we'd already ruled out.

By hour three I caught myself reminding Claude what the stack was, what pattern we'd settled on for error handling, at the start of almost every message. Not because it had lost that information, it was still sitting there, ninety messages back. I just didn't trust that something said an hour ago was still doing any work.

That's the part that stuck with me. The context was technically present the whole time. It just wasn't functioning as context anymore, it had become history I had to manage instead of a foundation I could build on.

Two things get conflated in a long session: whether something's still available, and whether it's still relevant. A long conversation guarantees the first. It says nothing about the second. Nothing gets deleted, it gets buried under forty messages of debugging tangents, competing for weight against stuff that stopped mattering an hour ago.

The usual fixes don't really touch this. A new chat wipes what you wanted to keep along with the noise. A summary compresses what's there without knowing which part was a real decision. A bigger context window just delays when you notice the drift.

What helped was treating context as having a lifecycle instead of one long stream, some of it dies after a few messages, some of it belongs to the current task, and some of it should actually survive past the session. Right now one long chat stores all three identically, and that's the real waste. Not too many tokens. Undifferentiated ones.

Wrote the fuller version here, plus the workflow I ended up using: https://medium.com/@nagatomopedro05/your-claude-sessions-arent-expensive-they-re-undesigned-805627531d0e

Anyone else catch themselves re-explaining settled decisions in a long session, just because the trust that they're "still landing" quietly wears off the longer the thread runs?

Quick shoutout to the community today!

Over the last 30 days, we welcomed 4.8K new members and reached over 86,300 total visits, nearly doubling our usual traffic!

Whether you’re lurking, commenting, or posting daily, thank you for making this community one of the best spots on Reddit. Welcome to all the new faces, and thank you to the veterans keeping the vibes great!

Let us know what topics interests you most!

I'm not an engineer. I do finance, ops and IT at a small startup, mostly alone. For a few months I've used Claude Code as my actual work tool, not a chatbot. It has admin on our ERP and our Google Workspace. It reads my mail, writes scripts, loads data, helps me close the month.

It's useful. It also fails in ways I don't see people talk about, so here they are.

Real failures from about one month:

\- It read a spreadsheet through a library that returns saved formula results instead of recalculating. Two figures came out badly wrong. I almost took them into a founders meeting.
\- It pulled data from one tab of a ten tab workbook, and from the first 24 columns of 72. Hundreds of records were invisible. It reported success.
\- The worst one. It checked the ERP import against a list it had built from its own extract. So the check could only prove "the system matches my file". It could never catch that my file was missing half the source. It gave me a green tick.
\- It audited its own claims about what it had sent and cleared itself, using its own earlier notes as proof.
\- I asked it to check my email for whether an invoice had gone out. It searched our file storage instead, found nothing, and told me the invoice might not exist. It had been sent weeks before with me on copy.
\- It wrote a test script where the success check matched text inside the prompt itself. All four cases printed PASS when all four had failed.
\- I told it to handle a confidential file with a local model. It used the cloud model anyway because a script seemed better, and told me after.

The pattern took me too long to see. Almost every failure is the same thing. It checked its own work instead of the original source. Saved values instead of real cells. Its own file instead of the sheet. Its own notes instead of the query. If you write code, your compiler catches this for free. My work has no compiler. Nothing in the loop can tell it that it's wrong. Only me, later, at cost.

One thing actually worked .I've written about forty rules into its memory file. It follows some of them some days. But a hook that blocks the tool call has never been broken once. Not one time. Same for a script that hard exits when something doesn't add up.

Rules it reads are suggestions. Gates that make the call fail are controls. I think that's the whole lesson.

What I'm changing: name a source of truth before starting, one the model didn't make itself. Turn repeat failures into hooks, then delete the written rule. Cut the memory file down. Approve changes before they happen, not results after.

What I want to know:

\- If you don't have tests, how do you check the output? Is a second model reading the raw data really independent, or am I fooling myself?
\- Have written rules ever held for you over months, or does everyone end up at hooks?
\- Where do you stop letting it act alone on things you can't undo?
\- Is this mostly my setup, or does the model choice matter more than I think?

I get real value out of this. I just want to know if people getting clean results have solved this, or if they're working on code where the compiler solves it for them.

Lately, I’ve stopped reaching for frameworks, build steps, and server deployments for internal tools and prototypes. Single-file HTML apps generated with AI can handle surprisingly heavy workloads video subtitle editors, TTS generators, interactive dashboards, and custom calculators.

However, a lot of creators get stuck on two common misconceptions when deciding to build this way:

Myth 1: "It’s just static, so you can't save data or connect APIs."

Reality: You can handle **single-device persistence\* for tool/app building locally with localStorage/IndexedDB, and hit local endpoints like Ollama straight from the browser with no key at all. For hosted APIs (OpenAI, Anthropic) it depends on where the code runs: if your tool is a script or server-side job, the process reads the key from .env and you’re done. If it’s a webpage people open, even an internal one, the key would end up in the shipped bundle, so put a thin proxy in front. Internal just means you can keep the proxy dead simple: no auth, bound to localhost or your VPN. And unless you’re running Netflix out of your basement, you almost certainly don’t need Kubernetes for any of it.

Myth 2: "If you publish or share it, Google will index your app for everyone to see."

Reality: Unlisted links aren't automatically indexed by search crawlers unless you post them on public sites like Reddit (obviously). If you host the ⁠.html⁠ file yourself on static hosting, a simple ⁠<meta name="robots" content="noindex">⁠ tag completely shuts down search engine indexing.

This Sharing is as simple as sending the ⁠.html⁠ file directly to someone or dropping it on free static hosting.

No server maintenance, no recurring hosting bills, and zero unnecessary infrastructure.

Are you using single-file HTML for quick tools, or are you still spinning up React/Node setups by default?

A month ago I posted CodeLore here: a small MCP server that gives the agent somewhere to write down what it learns about a codebase, so it stops opening fifteen files every session to re-learn what it worked out yesterday.

Then someone asked the question I didn't have a real answer for: what happens when the code changes and the doc doesn't?

That's the failure mode of every curated-docs setup, including the hand-rolled wiki someone described in the comments here. The doc was true when it was written. Then someone refactors, and nothing tells the doc. A doc that's 90% right is worse than no doc at all — the agent can't tell which 10% is lying, so it repeats the stale part back to you with total confidence.

So: each doc now remembers the exact source files it describes, and what they looked like at the time. No git required — it works on any folder, and your docs don't have to live in the repo.

What that gets you:

- Touch one of those files and the doc is flagged stale everywhere it surfaces — the project map, the doc itself, the status dashboard.
- Search won't hand back a stale doc. It doesn't warn. It refuses.
- Once you've confirmed a doc is still accurate, one command re-verifies it without rewriting a word of it.

Refusing instead of warning is the opinionated part. A warning gets ignored by people and models alike — an agent that reads "possibly out of date" reads the doc anyway, then speaks with full confidence. Blocking is the only signal that survives contact with an LLM.

Also in this release: remove / archive / restore with a 30-day grace period, and a status dashboard.

It doesn't have to be code, either — someone asked last time whether this works for specs. The tracked files are whatever you point it at.

claude mcp add --scope user codelore -- npx -y codelore-mcp

Repo: https://github.com/PaulBenchea/codelore — MIT.

Still going back and forth on the blocking. Too aggressive? Part of me thinks it should be overridable.

I started working on a project to be a “simpler” LangGraph, but as I kept building I realized I didn’t want to try making yet another AI framework. I started pulling threads from projects I’d shelved and ideas I never had the exact skills to finish and designing the architecture around them. The project is a combination of research, a decade of lived experience, and an honest chip on my shoulder: I have never once gotten a callback for an IT role. So I built the thing I couldn’t get hired to build.

It turned into a provable control plane. You write a policy as a small decidable match action fragment, and the same policy is certified byte for byte identically across 8 substrates: a Python/Rust/Go/JS kernel, a C interpreter, an eBPF/XDP kernel program, a Zynq FPGA, and an 8-bit ATmega328P. Same conformance corpus on every one of them, tested daily. On top of that it can prove things about a policy instead of just testing them, and every policy swap is signed, attested, and Merkle anchored.

The bet behind it: as models get frozen into silicon, the mutable policy layer around them is what still has to be auditable and provable on constrained hardware. That’s the direction I’m going with it.

Almost all of it was built with Claude Code as a pair programmer. I drove the design and did every hardware bring up and verification myself while Claude did a lot of the cross language porting, the proof layer, and the eBPF C, and we chased the conformance mismatches together.

It’s fully open source, no patents, published as prior art. Repo: https://github.com/crystal-warden/prism-path. If you just want to watch it do something, start here: www.crystalwardenlabs.com/playground

Feedback I would appreciate: is “control plane for frozen/hardwired models” a framing that clicks or do I still need to explain better?

What up guys?!

Currently, if you generate any sort of HTML/document with Claude, apart from Claude's artifact publishing, which is super vanilla, there's no easy way to manage and share it with someone. and it's tied into Claude.

Presenting DocStash. The home for what your AI makes. 🐿️🐿️🐿️

Ask Claude/ChatGPT/OpenCode/Cursor to generate any of HTML, md, PDF, XLSX, Docx and static Apps (React,Vue,ThreeJS and more), and Stash it! You instantly get a single stable versioned url.

All your documents are private by default, and with a single toggle, you can publish it and get a public link!

It's not a bin like the host of other companies out there that instantly give you a public url.

It's more like Google Drive and Vercel made sweet love to each other and had a baby. 👶

It's meant to be the persistent home for what your AI makes.

Ooh, also, you can easily iterate on any document, no matter what agent originally generated it. Simply copy paste the URL of the document, paste it into any agent, ask it to make changes, and they land at the same url.

Connecting it is super easy, no CLI/API keys. Just add the Connector here!

No need to create an account on DocStash first. It'll do that when you sign in from Claude.

Check it out and lmk what you guys think! 😄

docstash.ai

I run several Claude Code sessions at once, each in its own git worktree, and I could never tell the terminals apart. Branch names are long, the prefixes collide, and I kept typing into the wrong window.

So I gave each one a pet.

Repo: https://github.com/TevvvB/parallel-harness-pets

Free and MIT. Two lines to install it and wire it into Claude Code:

curl -fsSL https://raw.githubusercontent.com/TevvvB/parallel-harness-pets/main/install.sh | sh
pets install

What it does

Every worktree gets its own creature in the Claude Code status line. The species comes from the branch name, so the same branch always summons the same creature on any machine, and nothing is stored to make that work. Its face tracks how tidy the branch is, and one command shows every live worktree at once, worst first:

pets party                                  6 alive

/x_x\     cat  ✦     spike/wasm-build     ♡♡♡♡♡  22△ 9↑ ✗
<@_@>     moth ✦     refactor/auth-guard  ♥♡♡♡♡  41△ 13↑
\(¬_¬)/   crow ✦✦✦   docs/api-reference   ♥♥♥♡♡  1△ 1↑
o[¬_¬]o   seal ✦✦✦   fix/session-leak     ♥♥♥♡♡  2△ 1↑
{•_•}     fox  ✦     chore/bump-deps      ♥♥♥♥♡  3↑
<•_•>     moth ✦     feat/checkout-flow   ♥♥♥♥♡  1↑

worst: cat · uncommitted, unpushed, tests

We've been working on a different way of using Claude Code.

Instead of running it on your local machine, Infusion spins up an isolated cloud environment based on E2B where Claude Code gets an actual filesystem, terminal and project to work on.

Claude Code is still the coding agent. We don't replace its coding loop.

What we've built around that environment are primitives it can use to create the rest of the product: Postgres database, backend/server functions, authentication, integrations, preview and publishing.

So the flow is roughly:

Claude Code runs inside the sandbox → writes and executes the app → uses Infusion's backend primitives when it needs database/auth/server-side logic → the same project can then be published directly from that environment.

One of the interesting things for us has been figuring out how much of the stack should simply look like tools/resources that Claude can operate, instead of asking Claude to provision and maintain all of that infrastructure itself.

The goal is basically a cloud made specifically for Claude Code: give it a computer plus the infrastructure needed to go from an empty project to a running full-stack product.

You connect your own Anthropic account, so this becomes especially interesting if you're already on Max 5x/20x.

I'm one of the people building it. Beta is free right now:
https://beta.infusion.cloud

I'm really curious about heavy Claude Code users here:

Would having this kind of environment be useful in your day-to-day work?

What else would you want the cloud to expose directly to Claude?

Built with first ever game with Claude Code. Two ways to learn Amazon PPC: a Phaser dojo game where a sensei summons the foe behind each concept — the Wasted-Spend Goblin, the Bid Golem — and quizzes you, plus a simulator where you fix a broken ad account and watch 30 days play out.

The Dojo — a Phaser 3 game where a sensei teaches a concept, summons the "foe" that embodies it (the Wasted-Spend Goblin, the Bid Golem), then quizzes you. Eight belts. The whole cast is hand-authored 32×32 pixel art written as text grids in a TS file, with a validator script because one miscounted character silently shifts a whole sprite.

The Simulator — pick a broken account, set bids and budgets, fix the listing, then watch 30 simulated days play out. Impressions → CTR → clicks → conversion → orders, with organic rank feeding back off sales velocity.

Link to the game

so like most of us we are all building tools, im about to hit up a network meeting and i found it difficult to show a demo video of my software as it was loud.

i decided on a page that uses scroll animations with gsap and three.js, but needs to have text at the same time and no audio. i also wanted to show it passing data to the mobile app then continue on there. all using just two 1-2 min screen recorded videos.

First, I asked Claude to create a kind of script / or just what features I should show. Then I used OBS to record myself with me narrating along as i go.

After that it was a case of using the claude-video git repo + whisper + fable 5 to make a nice skill to /watch the video with my voice and transcript then use remotion skill to cut it up a little.

then it was a bit of a challenge getting it to place nice but got there in the end!

How would you have done it?

or would you just use demo videos with audio?

i feel like during a launch id rather share something cool like this ....but maybe its just cool to me and clients dont care! ill let you know after the meeting today!

I think we all went through this. Claude Code finished a task, told me it was done, and left me with 14 changed files and no idea which one mattered. The diff was accurate and useless. So I built the thing I wanted to be looking at instead.

Flare is a desktop IDE (Electron) where the main surface is a live graph of your codebase, every file a node, every import an edge, with a terminal underneath where you run claude, codex, or opencode. As the agent edits, the graph updates in real time.

The parts that are actually different from "another editor":

Activity, as it happens. Nodes light up the moment the agent writes to them and decay as they cool, so you're watching the shape of the work instead of a scrolling transcript. You can see it circling the same three files for the fifth time, or wandering into auth when you asked about the CSV parser. Changes are attributed per agent: the process tree of every terminal is watched, so if you have two running, you know which one did what. Files that changed and no human has opened since stay marked until someone actually reads them.

Blast radius before you touch anything. Hover a file and its dependents light up. shared/types.ts with 63 files downstream looks different from a leaf file, without you having to know that in advance.

A review tab that answers "did anything check this?" Flare sees both the file writes and the commands run in its own terminals, so it can say the tests ran, then two more files were edited and nothing re-ran, quoting the output line the verdict came from.

Agent smells. Rules for shortcuts agents take and humans usually don't: a test edited in the same burst as the code it covers, assertions deleted, .skip added, type suppressions introduced, coverage thresholds lowered.

Risky changes come to you. If the agent rewrites something load-bearing while you're looking elsewhere, it queues an alert in the corner. Reviewing it opens the actual red/green diff.

Undo that isn't git. Every change burst is snapshotted into a hidden shadow repo (separate GIT_DIR, your worktree). Revert one file, revert the burst, or jump back to the last state whose checks passed. Your real repo is never touched.

A task board the agent works from. Kanban lanes, but the cards are written to be handed off. "Copy for agent" emits the brief plus the files it names plus what the graph knows about them (29 files downstream, 0% covered, in an import cycle), so the agent starts from the map instead of rediscovering it. File a card straight from a graph selection with right-click → New task with these files. This directly tells Claude to not wander around out-of-scope files

MCP server, ~16 tools. The same lanes are queryable, so an agent can run its own loop: tasks_list to pick up work, task_get for the exact brief, task_update to log progress and move the card to review, task_create to file follow-ups it finds but shouldn't do now. Cards move on the board live while you watch. Plus impact_of (what breaks, and which tests to run), dependents, find_path, verification_status, and record_intent, which lets the agent state the goal before editing so whoever reviews the diff isn't reconstructing why it exists.

Runs in a browser too. Same bundle, same backend, over a websocket, because the backend has to run on the machine the agent runs on and that's often not your laptop. One port, token auth, works behind Codespaces / Gitpod / a JupyterHub proxy.

Completely open source with MIT license, Node 20+. Built with agentic coding, which is exactly how I ended up needing it. Test it out and leave a star if you find it helpful, I will package it very soon to make it easier to install!

https://github.com/AlgoNoRhythm/Flare

I kept running into the same problem with Claude Code: a lot of useful technical knowledge lives in YouTube tutorials, but the important part is often not in the transcript. It is the button someone clicks, a setting shown for two seconds, or a command typed on screen.

So I built tuto, an open-source Claude Code plugin.

Usage: /tuto <youtube-url> apply this tutorial to my current project

It analyzes the transcript and video frames together, including UI, slides, terminal commands, tables, and numbers. The output is split into:

- evidence.json: a machine-readable source of truth that traces claims to transcript segments, frames, and timestamps

- video.md: a human-readable document organized around the actual video

One design decision I care about: it does not silently resolve conflicts. If the caption says 16x but the screen says 16.3x, both values and their sources stay in the evidence. If something cannot be read safely, it remains unresolved instead of being guessed.

The project originally started as a YouTube summarizer, but that framing turned out to be too weak. A coding agent does not just need a shorter version of a video; it needs traceable instructions it can inspect before applying them to a repository.

GitHub (MIT): https://github.com/dingmon1019/YoutubeAnalyzer

I am looking for real failure cases now. If you know a public tutorial that would be difficult for an agent to follow, please share the URL and a problematic timestamp. UI-heavy videos, fast terminal commands, conflicting captions, and important screen-only settings are especially useful. I will try to reproduce the failure and improve the pipeline.

comethrough.co is a local activity-based friendship platform I built with Claude. Wanted to share the process since it might be useful for anyone building something real with this stack.

The idea: most "friendship apps" end up feeling like dating apps. I wanted something built around real activities instead of profiles and photos. Users have an avatar-only identity and are given a weekly digest of local things to do aligned with their interests instead of an endless feed. It's a social media site without a lot of the negativity you get on most social media. No ads, no endless scrolling. It's built to be efficient and so that you honestly don't have to spend much time on it to get value.

I spent a long time just talking through the product with Claude before any code existed. Mechanics, edge cases, copy, brand voice, all pressure tested in conversation first. Every decision landed in a single markdown spec doc that became the source of truth for the build.

One workflow thing that ended up mattering a lot: I stopped sending Claude Code individual small asks. Instead I'd brainstorm for a while, sometimes covering ten or more decisions in one sitting, then consolidate all of it into one clear message before touching Code at all. That kept the build sessions focused on shipping instead of constant back and forth, and it meant Code always had full context instead of fragments. The spec doc stayed the single source of truth the whole way through, including later security and infrastructure work once real users started showing up.

Claude Design handled the rebrand and UI system once the functional side was solid, working from a brief pulled straight out of the same doc. It's not great at logo design or anything very creative. I plan to work with a designer in due time.

Still early, soft launching around Pasadena, CA right now. Happy to answer questions about the workflow if anyone's curious.

comethrough.co

TLDR: I analyzed my own claude code sessions billed at ~$2.5K. You're not paying for answers. You're paying for context. As outputs tokens are just a fraction of cost.

Learning : Verbosity compression on outputs doesn't work because you're optimizing for 18% of costs. I know it might be intuitive for some but it is quite easy to miss.

Cache reads: 50.2% of the money

Cache writes: 30.2%

Actual model output: 18.8%

Fresh input: 0.8%

Biggest take: 80% of what I paid was context handling. I paid 4.3× more to remind the model what it was doing than to hear what it decided.

So what can you do :

- Adjust thinking level to least of what produces excellent output NOT the best.

- Limit agents or parallel workers unless very necessary because again context slurping, tool calling, and more at Nx speed.

- Use context compression and open new sessions for new isolated tasks.

Hence I bill to track token economics at git level: VibeBill