So a bit of backstory. I've always worked corporate, writing code for other people's stuff. At some point I just wanted to build something that was mine, start to finish, even if small.

The idea came from something dumb honestly. Every single night on the couch, me and my girlfriend, same story, 20 minutes scrolling Netflix trying to agree on something and just giving up. Tried a bunch of apps that were supposed to fix this and they either recommended garbage or just weren't really made for two people deciding together. So I ended up building Dunno. Basic idea is you swipe on movies like Tinder, and when you both like the same one it matches, done, that's your movie. Behind it there's an algorithm trying to actually learn what each person likes instead of just throwing popular stuff at you. Also threw in private lists at some point because a few people kept asking for a way to save stuff for later.

It's out now, both stores, and I wanted to share how things have gone since launch because it's not been a straight line at all.

Marketing has been the hardest part by far. No budget really. What actually worked wasn't ads or posting everywhere myself, it was messaging a couple of movie/cinema content creators and they liked the idea enough to show it to their audience. That's when I started seeing actual users show up, not before.

I also killed the monetization pretty fast. Launched with a Pro tier and ads you could remove with Pro, and it just wasn't worth it, barely made anything and it got in the way more than it helped. So I ripped it out and made everything free. At least for now. And honestly free with no ads is a decent selling point on its own these days anyway.

Nobody warns you about the store setup side of things either. Getting everything configured, the Pro integration, analytics, all of it, is genuinely a nightmare when it's just you. And the second you're selling anything you're signing paperwork you didn't know existed and going through review processes that seem designed for teams with a legal department, not one guy in his room. Android's 14 day closed testing requirement before you can even go live nearly broke me, just waiting around doing nothing useful while the clock ticks.

Then there's the TMDB thing, the movie database I use. If you start making money off an app that uses their data they want you on a commercial license and it's genuinely expensive per month. Between that and ads not really paying off, going free was kind of the obvious move, didn't want a fixed cost like that hanging over me before I even had real users.

And yeah I'll just say it, I used AI to help build part of this. I know that's usually an automatic downvote around here but I reviewed every line, every decision on what the app should actually do was mine, and honestly most of the polish came from just bugging my friends constantly for feedback and going back and forth on tiny details (my girlfriend is genuinely about to leave me over how much time I've dumped into this thing). Not trying to hide that I used it, just being honest about what actually building solo looks like. I get why people are sick of low effort AI slop apps but if you actually know what you're doing with it, it's just another tool. Used lazy it shows immediately. Used with care nobody can tell.

Ask me anything, stack decisions, how I got the creators... whatever.

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 full app persistence locally using ⁠localStorage⁠ / ⁠IndexedDB⁠, and connect directly to OpenAI, Anthropic, or local endpoints like Ollama right from the browser.

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?

This happened twice in one week and I was completely convinced Claude Code had something running behind my back. Hidden shells, subagents spawning subagents, something.

So I went and actually checked. Every transcript since July. Sidechain count: zero. One claude process, four idle MCP servers. Nothing was hiding.

I had sessions I just never closed. One of them had been open 57 hours. Another one 80. They grow until they hit the context ceiling and then sit there at ~1M tokens. Which is fine while you keep typing, because the prompt cache is doing all the work.

Then I go make coffee. Or sleep. Come back, type one message.

Cache is expired, so the whole million-token context gets written again, at 1.25x.

One message after a break: 971,316 cache write tokens. That's it, that's the whole budget. Not a loop, not an agent, just "hey can you check this" typed into a stale session.

On my worst one, 45% of all the cache writes landed on turns that came right after a gap longer than 10 minutes.

The fix, after a fairly humbling look in the mirror:

1. Fresh session every working day. I stopped using \--resume`` on the old monsters completely.

2. ``/checkpoint`` and a memory file to carry state over, instead of carrying the whole transcript.

3. Restart somewhere around 300K instead of riding it all the way to 1M.

Costs me about thirty seconds of context loading in the morning and gives me my whole day back.

If you want to measure your own: the usage entries in \~/.claude/projects/**/*.jsonl`get written three times each, so dedupe by`requestId`` or your totals come out 3x too high. Ask me how I know.

The expensive part was never what Claude was doing. It was how long I'd left the session sitting there.

Meet Elody my new improved local LLM agent

My knowledge agent has indexed 1,200 files of my own debugging history. When Claude's API went down, she was the only thing still answering questions about my own projects.

Here is what she actually is.

A few people picked up on the "local knowledge agent" I mentioned in my outage post earlier. Elody started as a terminal app in March. She indexes everything across my projects: debug sessions, architecture decisions, lessons learned, patterns I have seen before.

I ask her things like:

"when did I fix that deploy issue?"
"have I seen this error before?"
"what patterns have I found in the last month?"

She searches a knowledge graph of roughly 1,200 markdown files pulled from 11 sources, linked together with wikilinks. She finds the relevant nodes and answers from my own history. Not the internet's history. Mine.

The update since I last wrote about her: she is not just a terminal app anymore. She exposes 25 MCP tools, which means Claude Code can query her mid-session. I no longer have to remember to go ask. Claude reaches into eight months of my own decisions on its own.

That changed what she is for. I built her for outages. I use her most now on ordinary days, for cross-project pattern matching that no single session would ever catch.

One thing I want to be straight about, because it would be easy to oversell this.

Elody is not cloud-free. Gemini runs her day to day, because it is fast and the free tier covers me. Calling that "fully local" would not be true but it has a fallback mechanism.

The fallback is real. When the API returns a 503, she drops to a 7B model on my machine and keeps answering. Slower, less sharp, still useful. Degraded, not dead.

That is a lower bar than "runs entirely offline." It is also the bar that has actually held up when I needed it.

She has company. Woolly is a pixel sheep who lives on my screen, reads the same knowledge graph, and writes a briefing file into whatever project folder I am working in, so my next session starts warm. He deserves his own post. Next week.

Neither replaces Claude Code. I still build with it every day. They fill the gap around it: knowledge that survives the session, and context I do not have to re-explain every morning.

Eight months in, the difference is that my tools stopped meeting me fresh every time.

Elody in action

Nobody on my ops team requested a dashboard. What they had was a group chat, a shared spreadsheet with three conflicting versions, and a leadership call every Wednesday that started with "wait, where are we on the Riverside campaign."

I built the dashboard on a weekend (started literally on a notepad editor) because I was the one fielding the "where are we" questions, not because anyone asked for a tool.

Now 6 months later, this original notepad editor script evolved to a zero backend, zero build step, it reads the same data everyone already had, just renders it as something you can actually scan and understand in an instant without manipulating it a thousand ways to get a readable result.

**What it shows, nothing more:**

- Active campaigns (862 right now)

- Anything pending removal, the ones about to expire and nobody's flagged it yet

- Shipment delays, the thing that used to surface as a surprise phone call

- What actually posted this week, so "did it go up" stops being a Slack message

Six weeks later, my team looks forward to me briefing them on our call now on major issues because they actually matter now and are not just some numbers. Not because it's pretty, it isn't, particularly, but because it answers the question before someone has to ask it out loud.

The patterns that repeats itself: The tools people actually use aren't the ones with a feature list. They're the ones that kill one specific recurring interruption. Nobody wants a "campaign management platform." They want to stop getting surprised on a Friday.

I've talked before about the knowledge graph I keep across projects. What I hadn't noticed until this week: the main file backing it had grown to 331KB, and every single session, no matter the task, loaded the whole thing cold before doing anything else.

Ask it to fix a typo, it reads 331KB first. Ask it what's pending across 12 projects, same 331KB. There was no difference between "quick fix" and "deep dive" in what got loaded, just one file, read in full, every time.

That's not a documentation problem. It's a **token problem** every session was paying the full read cost regardless of whether the task needed 2% of that knowledge or 90% of it.

The fix wasn't deleting anything. It was tiering it:

>**Tier 1 - always loaded, 6KB.** Distilled rules and a trigger table. This is the only thing read cold at session start now.

>**Tier 2 - read on trigger, not by default.** Project deep-dives, data/persistence patterns, full lesson history. The trigger table in Tier 1 says exactly when to open these — "touching project X" or "verifying something" so they only load when the task actually calls for them.

The 325KB that used to load every time? Still there. Still complete. Just not read until something names it.

First session after splitting it: same knowledge available, a fraction of what actually got loaded. The mistake wasn't having 331KB of hard-won context — it was treating "always available" and "always read" as the same thing.

I used to route everything to whatever model was newest, because newest felt safest. Fable 5 came out and I did it again, first three tasks of the day, all through it, no thinking involved.

Then I actually looked at what those three tasks were:

- A typo fix across 3 files

- Renaming a variable repo-wide

- Writing 12 unit tests for code that already existed

None of that needed the expensive model. Sonnet does all three of those instantly, for free, at the same quality. The only two tasks that night that actually justified Fable 5 were a 4-service auth migration and a "does this schema still hold up" question that needed real judgment across files it hadn't seen yet.

**So I started keeping a /ledger.**

Every task gets tagged Sonnet or Fable 5 before I run it, not after. At the end of the session I can see the split. First night: 3 of 5 tasks didn't need to be routed where they went.

The rule I'm using now, plan and judgment calls go to the expensive model, mechanical execution doesn't:

**Sonnet handles:**

- Anything with one obviously correct answer

- Repetitive changes across files

- Test writing, formatting, renames

**Fable 5 gets called in for:**

- Architecture decisions with tradeoffs

- "Is this still right" questions across a codebase it hasn't fully seen

- Anything where being wrong is expensive to unwind

The quota resets, but it doesn't reset for free. Tracking where it actually went is the only thing that made me stop wasting it on typo fixes.

Foundations & Control

Execution & Optimization

While reading through the many amazing posts here, I found that there is a massive amount of collective knowledge already buried in the feed.

As we all push past the basic "vibe coding" phase, I figured we could build better and stronger together.

So, I compiled some of the best threads about workflows, tools, and best practices I've seen so far into a quick visual guide that way you don't have to do the heavy lifting and search for a needle in a haystack.

Enjoy and let me know if I'm missing anything. 🎉

1. Claude meets Government Oversight 🫡🇺🇸

https://www.reddit.com/r/BuildWithClaude/s/XFZShXq7Pn

2. Built with Claude Code: paste a YouTube link, get a shareable infographic in under a minute

https://www.reddit.com/r/BuildWithClaude/s/aslbjiQjt1

3. I used the rest of my Fable 5 quota to build Engram, a Claude Code plugin for learning anything (and actually keeping it)

https://www.reddit.com/r/BuildWithClaude/s/pACEnb3u1w

Greatest designs award:

Fable 5 one-shot ability is crazy

https://www.reddit.com/r/BuildWithClaude/s/cOCH7f4AWU

Thanks fable it was nice knowing you❤️

https://www.reddit.com/r/BuildWithClaude/s/kyXFvM17ht

Working with Claude Code—or any high-velocity AI-driven dev workflow—demands a unique kind of vigilance. We are constantly sharing repo links, complex configuration paths, and experimental tool chains. In an environment built on speed and "zero-dependency" architecture, the speed of trust is our greatest asset—and our biggest vulnerability.

The Security Reality

When you're pushing code or sharing a project link, the line between a legitimate, resilient tool and a suspicious artifact is often paper-thin. Fraudsters are now experts at mimicking developer patterns, using legitimate-looking URLs that lead to compromised environments.

• Trust, but Audit: Never assume a link is safe just because it’s shared in a collaborative channel. If you aren't sure where that path leads, perform a manual audit of the repository before executing any commands or pulling down dependencies.
• The "Urgency" Trap: If a prompt or a collaborator is pushing you to execute a "quick fix" link that bypasses your standard security review, hit the brakes. Real engineering innovation doesn't require compromising your local security posture.

The Reputational Hazard: The "Spam" Fallacy

Here is the uncomfortable truth: In the developer community, skepticism can quickly curdle into malice.

When you share an innovative tool—especially one that breaks convention or challenges the status quo—it’s easy for someone to misinterpret your work as "spam" or "malicious" simply because they don't understand the implementation.

We see it all the time: an envious actor sees a project they didn't build or can't comprehend, and their reaction isn't curiosity—it's a targeted accusation. They take a screenshot, label it "phishing," and broadcast it to damage your credibility.

Before you flag, and before you jump to conclusions:

• Acknowledge the "Why": Is this link actually malicious, or are you just skeptical of a method you haven't seen before? There is a massive, life-altering difference between a genuine security threat and a difference in coding philosophy.
• The Cost of "Public Justice": Making a false accusation based on a "gut feeling" about a link can destroy a developer’s reputation overnight. The digital world is permanent; a false claim of "scam" attached to someone’s name rarely goes away, even when the truth comes out.
• Engage Before You Accuse: If a project looks "weird," ask for the context. Challenge the code, not the character. If it’s actually a scam, you’ll find out through objective verification, not through an emotional outburst.

The Bottom Line

Security requires surgical precision, not reactionary outbursts. We protect our tools by being diligent in our vetting, and we protect our community by refusing to weaponize "scam" labels against innovation we don't yet understand.

Stay sharp, verify your links, and hold your peers to a standard of evidence rather than suspicion. True expertise is knowing the difference.

When you are reviewing a new tool or link shared within your dev circle, what is your go-to "sanity check" to distinguish between a genuinely experimental project and a red-flag security risk?

Here's the distinction that keeps getting lost in the "AI slop" debate.

Writing code is mechanical. Given clear constraints, an AI executes it fine. It doesn't need to understand why, it needs to know what, in enough detail to produce the right output.

Software development is different. It involves decisions about what to build in the first place, how systems should relate to each other, what to prioritize, what to cut. That requires creativity, context, and judgment. And if you automate that part, if you take your hands completely off the wheel, you get slop. Not because the AI is broken. Because you removed the human doing the actual work.

Every AI agent, no matter how capable, needs a human steering. Not micromanaging every line. Making the calls that require experience.

The domain fluency problem

AI can execute precise instructions. It cannot read your mind. The people who extract a force multiplier are the ones who can name what they want in domain terms, schema constraints, edge cases, system boundaries. The ones who say "make it work" get whatever the model defaults to.

"Prompt engineering" was always just domain fluency expressed precisely. Which means AI widens the expert-novice gap rather than flattening it, at least short term. The engineer's instincts, the architect's constraints — that's compressed expertise wearing the costume of a prompting trick. The model pays out to whoever already has it.

So "AI democratizes development" is half right. It democratizes execution and rewards specification. Specification is exactly where the experience lives.

>Someone described it honestly: their prompts became completely non-technical, about observed behavior, because they'd stopped understanding the codebase. Couldn't guide the AI toward the right areas. Couldn't meaningfully read the diffs. That's not an AI problem. That's what happens when you hand over the wheel entirely.

Would you call this AI Slop?

The tool is only as good as the person holding it. That was always true.
What type of tools or workflows have you built to keep your Claude Code Agent in check?

I've seen this pattern enough times to name it: The worst software calls in an org rarely come from the people who'll use the tool. They come two or three levels up, from someone who heard a name in a meeting, heard that competitors use it all the time and now are eager to put their crew through hell and overthrow an entire operational workflow established over several years just to rebuild the entire structure from scratch with patches that look more like something MacGyver put together with bubble gum and paper clips just because that tool was hyped up to be the answer to all their preyers.

It tends to go like this:

1. Someone senior hears a product name -- > A webinar, a vendor pitch, a peer at another company. It *sounds* right. They read the homepage tagline, not the docs.

2. The name travels down as a decision, not a suggestion. By the time it reaches the team, it's "we're using X for this now" — not "would X even work?"

3. Nobody checks the category. This is the one that actually hurts. Software lives in categories, analytics, field and ops service, CRM, project management and they do NOT cross over. A marketing-analytics tool will never send a work order. A dashboard will never dispatch a crew. But the name *sounded* operational, so in it goes.

It can get absurd, tools picked that are literally one letter off from the product someone actually meant. Different company, different category, different everything, chosen purely because the names look alike. Weeks get burned forcing the square peg before someone finally says "Wait this doesn't even *have* that feature we actually need?" Because people who actually have to use it daily are not being consulted or not involved in the process.

The pattern underneath: Leadership optimizes for *making a decision*, the team optimizes for *the work getting done*.

Those aren't the same goal. A choice made off the homepage feels like progress. It's just deferred pain — handed to whoever has to use it.

>Here's where I've landed, and it's the part that's shifted for me this past year:

**When the off-the-shelf tool is a mismatch, you're not stuck picking the closest wrong thing anymore. You can build the exact right thing or at least develop the MVP to understand what the requirements are.**

I heavily use Claude Code for this, not because it's magic, but because it collapses the gap between "the tool we were told to use" and "the tool the work actually needs":

1. It builds to your workflow, not the vendor's.** The work order form has the fields your team actually fills out — not 40 generic ones with the 3 you need buried somewhere.

2. No per-seat licensing, no category lock-in.** The mismatched enterprise tool is often $5k–$20k/yr. A focused internal tool you own is just the time it takes to build it.

3. You ship a working v1 in a day, not a procurement cycle.** Describe the real job — "field crew gets a work order with site, date, materials, status" — and you've got something running before the vendor returns your demo request.

4. It explains every decision as it builds**, so the person who owns the tool actually understands it instead of inheriting a black box nobody can change.

TL;DR So if your team's about to adopt something because the name sounds right — pull up the actual feature list first and ask one question: *does this tool do the literal thing we need, or does it just sound like it?* Half the time the honest answer sends you back to building it yourself.

And the irony is: The tools leadership grabs to "save time" usually cost more time than building the right thing would have. The category was always the problem. The name was never the answer.

Anyone else had a front-row seat to a tool getting picked by name and category-confusion? Curious whether this is as universal as it feels.

Nobody calls it slop when you use a game engine someone else built, so what's the difference?

The art, the music, the story, the world, that's the work. The engine is just what holds it together. If you made everything that matters, the code being AI-generated doesn't make the project slop.

Code is the glue. What's being held together is the project. Judge that.

This reframe matters because the "AI slop" conversation almost always focuses on the wrong thing, the mechanism of production instead of the quality of what gets produced. If the output does the job, handles the edge cases, and holds up over time, the question of who typed it is less interesting than people pretend.

Someone in Greece built a site in 2 hours and forced a government ministry to delete a page in 72.

>Vibe coding gets clowned on constantly. "It's just slop." "No real engineer does this."

Meanwhile that builder said it best:

>"Usually, setting up a site for this kind of civic stuff takes days of messing with boilerplate, layout tweaks, and deployment config. By the time you're done, the momentum is gone. Vibe coding meant I could just launch it instantly while the topic was still hot and catch them completely off guard."

The code quality didn't matter. The timing did. That's a different category of win than enterprise software and dismissing it misses what actually happened.

The slop phase is part of the progression

Honestly the vibe coding phase is necessary. You learn what the tool is actually capable of by shipping things that don't matter yet. When it breaks you learn how to fix it. And somewhere along the way you start caring about code quality, not because someone told you to, but because you want the thing to last.

That's not a flaw in how people are using AI. That's just how you learn any tool. The mistake is treating the early messy phase as evidence that the ceiling is low, rather than as the floor everyone starts from.

Nobody ships masterpiece architecture on day one. With any tool.

Build in 6 moths and counting -- didn't break yet.

What is your experience with these tools?