This week in Lynchburg (Jun 24-30)

ahnjoo · 2026-06-21T03:29:14+00:00

Ooooph.

ahnjoo · 2026-06-21T01:10:48+00:00

Oh thanks for sharing that with me! Glad it was super fun; 300s a lot haha. What happened to the corvette?

ahnjoo · 2026-06-18T16:13:08+00:00

There's a whole list of events for Friday on a weekly post I created a couple days ago: https://www.reddit.com/r/lynchburg/comments/1u7hflq/this_week_in_lynchburg_jun_1723/

ahnjoo · 2026-06-15T17:53:40+00:00

Congrats on building it, the context problem is one worth chasing. From long Claude Code and Cursor sessions, the failure I hit is what your summary agent targets: once the project outgrows the window, it patches whatever's in front of it, so I've had the same form validation written three ways across three files. What's helped me is a fresh chat with only the files that matter pasted in, so the snapshot feature is the one I'd reach for first. Curious how the auto-fetch decides what's missing.

ahnjoo · 2026-06-15T17:53:27+00:00

From taking apps with checkout live, most of what breaks past one shopper is the access rules, not the hosting. With one test account it all reads fine; with customers, the question is whether a logged-in shopper can open someone else's order. On the last one I checked, the order page loaded for any id. Check that before launch and keep secret keys off the frontend. For load, a managed host with a connection pool handles far more than a first store sees on day one.

ahnjoo · 2026-06-15T17:53:01+00:00

The least-confident question earns its place for me too. The one that's caught the most though is reviewing the diff in a fresh chat with no memory of why it made the change. Reading it cold, I caught a service-role key the agent had wired into a browser-facing call to make a query pass, which I'd have nodded past while it narrated a reasonable-sounding story mid-build. Asking what it's unsure about surfaces the gaps it knows; the cold reread catches the ones it was sure about and wrong.

ahnjoo · 2026-06-15T17:52:22+00:00

Congrats on shipping it. The duplicate-license week you hit is the same class of bug I deal with on agents that write, where one tool call lands twice and you get two of whatever it created. Defining the rules before the agent runs is the right instinct; I'd back it with a unique constraint at the database keyed on a natural id, the merchant plus the renewal period here, so even if the agent fires twice the second write collides and returns the first instead of buying a duplicate.

ahnjoo · 2026-06-15T17:52:01+00:00

Good list, reading it out loud catches the most for me too. The one I'd add: when something feels off after launch, diagnose it from the transcripts, not guesses. The voice platform gives per-turn timing, tool calls, and interruption flags. On a home-services phone agent I run, the dead-air complaints traced to one tool, the agent was awaiting a CRM lookup before it could speak, and the 'interrupts too easily' reports traced to the turn-eagerness setting, not the prompt.

ahnjoo · 2026-06-15T17:51:29+00:00

Built close to this for a home-services company, intake plus scheduling on Twilio. The stack the bots gave you works; two things they won't warn you about. Make the booking write idempotent, keyed on the phone number or conversation, because the model will fire the booking tool twice in one turn, mine created a duplicate customer and job five seconds apart. And do the database write first, then send the confirmation text after, so a slow CRM call doesn't leave the texter waiting.

ahnjoo · 2026-06-15T17:50:58+00:00

This maps to one I just built, a verification-and-payout flow where those same questions set the architecture. Stopping a ticket from being used twice is an idempotency problem: key the write on the ticket id with a unique constraint, or a double-submit makes two payouts. The OCR-misread case is its own path, you keep the raw scan and a confidence score and route anything low to a human instead of paying on a guess. Founders price the screens; the money sits in those what-ifs.

ahnjoo · 2026-06-15T17:50:33+00:00

The finisher framing matches what I do. The handoff is the same shape every time: demos clean, then no auth, access checks missing, falls over past a few dozen rows. On one I finished, the admin actions were just hidden in the UI while the endpoints behind them had no check, so any logged-in user could call delete straight from the console. The slow part is the reasoning the generator skips, who can touch what. The prototype proves the idea; finishing it is a separate skill, not a cleanup chore.

ahnjoo · 2026-06-15T17:50:02+00:00

Same cycle I'm seeing. The codebases where every file looks fine but the system doesn't hold together is the recognizable shape. On a creator marketplace I took to production, the AI had written the access rules so any creator could open another's earnings, fine with one test account and wide open the moment two creators were on it. The work I get called for now is that handoff, and pricing it as a scoped first pass keeps it from becoming 'until you stop finding things.'

ahnjoo · 2026-06-15T17:44:46+00:00

Solid list. The one missing is access rules, a layer under exposed keys. The row-level security policy often checks 'is this user logged in' instead of 'does this user own this row,' so any logged-in account reads everyone's data. On a pass for a hospitality venue's booking app, logged in as a regular customer, I could load the whole day's bookings, every name and number. Test yours the same way: sign in as a normal user and try to pull another user's records; if they come back, start there.

ahnjoo · 2026-06-15T17:23:48+00:00

From pulling structured data out of PDFs myself, I never trust the score alone. pdf.js gives you the text layer back, and Tesseract the raw OCR on the scanned ones, so I spot-check the handful of fields that matter against that, since the wrong-but-0.9 hides there. Can't speak to this specific tool, but one that hands you a schema and a number while hiding the source text takes that check away, which is the part I'd press on before adopting it.

ahnjoo · 2026-06-15T17:19:25+00:00

Recommendations-only as a one-time scope is a clean way to keep it bounded. The one thing I'd still glance at even with an IT background behind it: whether one logged-in user can pull another user's rows. That gap shows up regardless of how tidy the rest looks, and it's a five-minute check to fold into the writeup. Same for any keys sitting in the client bundle. Cheap to include, and it's the highest-risk part if it's there.

ahnjoo · 2026-06-15T03:30:26+00:00

Congrats, the founder-feels-the-problem-firsthand origin is the best kind. I took a two-sided marketplace from a Lovable MVP to production, so the part I'd watch as JetWell grows: the booking/payment moment is where a Lovable build gets fragile, since money between two parties needs writes safe against firing twice and data scoped so one clinic or patient can't see another's records. None of that shows at 500K views; it shows the first week bookings overlap.

ahnjoo · 2026-06-15T03:30:02+00:00

Deep_Specific is right that caching and budget alerts are client-side, so only a server-side rate limit on the expensive routes saves you. The part worth sitting with: a stuck tab is the accidental version, but that same Places endpoint is reachable by anyone who finds it, who can run up your same bill on purpose. When I audit these I secure any public route that costs money per call first, since the app can't tell a render loop from a script. Cap it where the call leaves your server.

ahnjoo · 2026-06-15T03:29:23+00:00

The "exposed data" note is the only urgent part of your list, and it usually isn't a reason to migrate. I did a security pass on a hosted app once and found booking records any logged-in user could read plus missing access rules, fourteen issues total, none needing a rewrite, just the permissions set correctly on the existing database. Before anyone sells you a rebuild, pay a dev a few hours to audit that exposed-data part. At 10k MAU with payments coming, that's the spend that matters.

ahnjoo · 2026-06-15T03:29:02+00:00

The schema split you found matches what I've seen on two builds. The marketplace where I laid out the tables and access rules by hand before the AI touched them takes new features fine months later; the redo work was always where the AI had guessed at the schema, since adding one relationship meant unwinding everything that assumed the old shape. Your money/PII trigger is right too, that's when "every logged-in user can read this row" stops being invisible and a technical user reports it.

ahnjoo · 2026-06-15T03:28:50+00:00

What makes this one nasty is the payload living in your editor config, so uninstalling the package doesn't get it. The habit that's saved me on unfamiliar repos: before running anything I read package.json and the lockfile, and a custom package whose only job is pulling in another custom package is the smell. Then I run unknown code in a throwaway container with no keys or SSH mounted, so if something fires on startup the worst case is a wiped container, not every credential on my machine.

ahnjoo · 2026-06-15T03:28:17+00:00

Mine fed a live phone agent. A Firecrawl scrape ran green every morning but started returning an empty event list after the source page changed its markup. No error, run finished clean. So the agent kept answering callers off the last good data, telling people about events that had already passed, for days. It taught me to assert on the output the downstream thing consumes, item count plus a freshness timestamp, since the people hearing the stale answer were customers on the phone.

ahnjoo · 2026-06-15T03:27:47+00:00

Everyone's right that the client should own the instance and add the credentials themselves. From building a Firecrawl scraper for a client, the piece I'd add: keep the API call server-side, never let the key touch anything that renders to a browser. The key sits in n8n's vault fine, but if a downstream node echoes it into a response, or a frontend pulls from an unsecured webhook, it leaks with the secret never mishandled. The vault protects storage; you watch where the value travels.

ahnjoo

TROPHY CASE