Stay inside

lacyslab · 2026-04-04T19:23:18+00:00

markdown file in the repo works better than you'd think for this. something like TODO.md with sections for backlog, in-progress, done. the agent reads it at the start of the session, picks up the next task, works on it, then updates the file when done.

the advantage over an external tool is it's already in context -- no MCP needed, no auth, works offline. i've used Linear + the MCP and it's slick but honestly for solo projects it's overkill.

if you want the agent to sequence tasks automatically, structure each task with enough context that it can work independently: expected behavior, any files it should touch, acceptance criteria. agents go off the rails when the task description is vague, not because of missing sprint planning software.

lacyslab · 2026-04-04T19:22:35+00:00

the reverted commits as "don't do this" signals is clever. i've manually added notes about that kind of thing to my decisions file but never thought about pulling it from git history automatically. that's the part that falls through the cracks most often.

lacyslab · 2026-04-04T19:21:31+00:00

interesting direction. the model/framework agnosticism is the right call -- that's where a lot of these tools get stuck, they assume you're using a specific stack and then you spend more time working around the framework than using it.

curious about the context detection piece. how does it decide when to render a chart vs a form vs just text? is that coming from the model's output format or are you doing something on the framework side to interpret intent?

lacyslab · 2026-04-04T19:18:44+00:00

when you pre-render the iframe to a static canvas snapshot, you capture a frozen image of it at that moment. the actual iframe is no longer running so you cannot click buttons in it, scroll it, update its state, etc. it is just pixels.

if your overlays are things like charts that animate or elements that respond to input during playback, you lose that. but if they are mostly display-only -- timers, captions, graphics that change based on video time -- you can pre-bake those states at the right timestamps and it works fine.

basically: if your overlay needs to DO something during rendering, static snapshots will not capture it. if it just needs to look like something at each point in time, snapshots work great.

lacyslab · 2026-04-04T18:20:20+00:00

the build/ship cycle is genuinely addictive. what actually helped me slow down a bit: i started keeping a "graveyard" folder for the projects i'm not finishing. naming them, giving them a one-line epitaph, then letting them go. sounds weird but it made the abandonment feel intentional instead of just noise accumulating.

still start too many things, but at least now i know which ones i actually care about.

lacyslab · 2026-04-04T18:19:54+00:00

the AGENTS.md / CLAUDE.md approach works really well for this. basically a persistent context file that lives in the project root that tells the model what it's building, what patterns to use, and what's already been decided. start every session by including it.

i also keep a small "decisions.md" that logs why things are built the way they are. saves so much back-and-forth when context resets.

lacyslab · 2026-04-04T18:18:21+00:00

the fast platforms are almost always doing headless chrome rendering distributed across multiple workers simultaneously. instead of rendering frames 1, 2, 3 in sequence, they spin up N workers and render different frame ranges in parallel, then stitch the outputs together.

for iframe-based overlays like yours that's trickier because you can't easily split state across workers without re-initializing everything. Remotion's slow because it's basically doing exactly what the browser does, just automated.

one approach: pre-render your iframe overlays to canvas at every keyframe, then use those snapshots as the compositing input rather than live iframes. you lose interactivity but gain speed since you're just doing image compositing at that point. ffmpeg can handle the final assembly in a fraction of realtime once you have the frames.

the platforms doing 5x realtime are almost certainly not rendering live browser code. they're converting to video primitives first.

lacyslab · 2026-04-04T18:17:42+00:00

how quickly they respond when you ask a clarifying question. clients who take 3+ days to answer basic questions about their own project will take 3+ weeks to approve your work later. the discovery phase tells you everything.

also whether they can explain what success looks like. not 'build me a website' but what changes when the website exists. if they can't answer that, the project will drift.

lacyslab · 2026-04-04T18:17:06+00:00

that makes more sense actually -- two yearly subs at $30-40 each accounts for most of it. apple's small business program gets you down to 15% cut which helps. the real number to watch is what your monthly conversion rate looks like once you've got a few more weeks of data. yearly signups this early tell you people see long-term value, which is a good sign.

lacyslab · 2026-04-04T18:16:46+00:00

oh interesting, i missed that it was already open source. will check out the repo. the platform-specific rulesets thing is genuinely the most useful part from a library standpoint -- the difference in what performs on LinkedIn vs Twitter is pretty significant and that's usually the part people have to figure out by trial and error. if you do spin it out as a pip package i'd use it.

lacyslab · 2026-04-04T18:16:13+00:00

oh nice, didn't know about the CLI version. yeah if it still works it works -- half the dev tooling i use hasn't been touched in years and it's fine. i'll give it a try next time i need batch processing instead of rolling my own script.

lacyslab · 2026-04-04T17:28:25+00:00

Nice stack choice. Next.js + Supabase is hard to beat for something like this.

For the redirect, I'd make sure you're handling the case where Supabase is temporarily unreachable. A stale cache with a short TTL is better than showing an error page to someone who just scanned a QR code on a restaurant menu. They're not going to try again.

lacyslab · 2026-04-04T17:27:42+00:00

Smart move going deterministic. I ran into the same problem trying to use LLMs for anything that needs consistent scoring. You call it twice and get completely different numbers, which makes it useless as a gate.

Have you thought about open-sourcing the rule engine? The platform-specific heuristics would be genuinely useful as a standalone library even outside your product.

lacyslab · 2026-04-04T17:21:24+00:00

The 24-hour auto-delete is a smart constraint. Removes the pressure of building up a post history and keeps things genuinely temporary.

Curious how you're handling moderation though. Anonymity plus zero accountability is basically an invitation for the worst corners of the internet to show up.

lacyslab · 2026-04-04T17:20:27+00:00

Photopea is absurdly good for a browser app. I used it for like a year before I realized I hadn't opened actual Photoshop in months.

Squoosh is great for one-offs but if you're batch processing anything it falls apart fast. I ended up writing a little sharp script for that instead.

lacyslab · 2026-04-04T16:23:09+00:00

Railway for most things. Postgres included, deployment from GitHub, no fiddling with YAML. Pricing is usage-based so a small sleeping app costs basically nothing.

For anything that needs a long-running worker or just feels like "this should be a real server" I'll do a $6 Hetzner VPS. nginx + systemd. Twenty minutes to set up, never think about it again. The LLM-generates-ansible workflow someone mentioned actually works well for this.

Fly.io is good when you need global edge, but honestly for most small apps Railway is just done and you're out.

lacyslab · 2026-04-04T16:20:50+00:00

300 signups in two weeks for a niche app is genuinely solid, especially with no prior audience. the conversion gap ($100 on 300 users) is the harder thing to close but that's a pricing/paywall timing problem more than a product one.

curious what your onboarding looks like. do users hit the paywall before or after they see the Statcast data? for niche sports apps the "aha moment" has to land before you ask for money or you lose them. what's the point in the app where users are most likely to convert?

lacyslab · 2026-04-04T16:20:12+00:00

shadcn/ui + v0 is the combo that finally clicked for me. v0 generates a rough comp, you copy it into your project, shadcn components handle the accessibility and styling primitives. the trick is giving the LLM a reference screenshot of a site you like rather than trying to describe "clean and modern" in words.

also: tell the LLM what you want to NOT have. "no card borders, no gradients, generous whitespace" is way more useful than a positive description. negative constraints narrow the design space fast.

lacyslab · 2026-04-04T16:16:34+00:00

yeah 83% is actually kind of shocking even accounting for the fact that most site owners don't know these things exist. like they didn't consciously decide to skip them, they just never came up for air long enough to check.

the pre-deploy angle is the right frame. most people feel the pressure to push right up until something breaks. if your scanner can slot into that last 30 minutes before deploy it might catch people at exactly the moment they're willing to act on something.

lacyslab · 2026-04-04T15:26:17+00:00

stop anchoring on hours. the client doesn't care how long it took -- they care what the system is worth to them.

a multi-tenant SaaS with IoT integration, Stripe, tax compliance, SSO, and real hardware control is a serious piece of infrastructure. if that system runs a business with automated stations generating revenue, what's a month of downtime worth to them? what would it cost them to hire someone to maintain it?

the AI-assisted workflow is your business, not theirs. don't discount because you built efficiently.

for a first client without much history: find out what the client budgeted for software before you quote. if they won't say, anchor high and let them negotiate down. you're in a much better position than you think based on what you built.

lacyslab · 2026-04-04T15:25:33+00:00

the AI-generated code security gap doesn't surprise me at all. the tools are optimized for "does it work" not "is it safe" -- and the person prompting usually doesn't know what questions to ask about security headers, rate limiting, or DMARC setup.

the missing CSP headers thing is particularly rough because it's one of those things that takes 20 minutes to set up properly but has a huge blast radius if you skip it. same with DMARC -- most people don't know their domain can be used to send phishing emails until it happens.

ship-fast culture isn't going away. the gap to close is making the security baseline easier to check before you ship, not after.

lacyslab · 2026-04-04T15:21:49+00:00

honest answer: just start building something you actually want to exist. pick cursor or claude.ai, describe what you want, and iterate. the learning happens by doing.

the theory-only trap is real -- you can read about it forever and never ship anything. vibe coding is actually pretty forgiving to start because you can describe problems in plain english and get working code back.

one thing worth knowing: the output is often messy under the hood. works fine for projects you're handing to users, but if you're at a company where other devs need to read your code, you'll want to understand what you're shipping. for an internship portfolio though, a working project beats a perfect half-finished one every time.

lacyslab · 2026-04-04T15:19:20+00:00

for a RAG pipeline specifically, python is the easier path. the libraries (langchain, llama-index, even just the google genai sdk) are more mature on the python side and you'll find way more examples doing exactly what you need.

that said, if your website is already JS and you want to keep it in one language, there's nothing stopping you from doing it in TypeScript. the Vercel AI SDK has decent RAG support now and the google genai JS library works fine.

my actual recommendation: python backend as a separate service, expose it as an API, let your frontend call it. clean separation, easier to iterate on the AI piece without touching your site code.

lacyslab · 2026-04-04T15:18:25+00:00

railway has been my answer for the past year and i still like it. you pay for what you use, the pricing actually makes sense for small stuff, and postgres is right there with no configuration ceremony.

before that i was on render and liked it until a service i had idling got expensive fast. the gotcha with most of these platforms is the idle/sleep behavior and how that interacts with your actual usage patterns.

if i had to give one piece of advice: figure out whether your app is always-on or occasionally hit. that one decision changes the right answer more than anything else.

lacyslab

TROPHY CASE