Hacker Newsnew | past | comments | ask | show | jobs | submit | pwr1's commentslogin

Did this about a year ago, went smoother than expected tbh. the main gotcha for us was DO's managed postgres — had to dump/restore manually since there's no direct migration path to Hetzner's managed DBs. ended up just self-hosting postgres on a separate box which has been fine, maybe even better.

Just lost an hour going through this. Found a Nirvana show from 1989 at Dreamerz. The recording quality is surprisingly decent for a cassette tape. This is exactly the kind of thing the internet was supposed to be for.


So they want protection from harms caused by their own models. Classic move — lobby for the rules while you're still ahead of regulators who don't fully understand the technology yet. Would be interesting to see what happens when a state actually pushes back hard.


Presently it appears that a state attempting to push back will get stomped on by the feds: https://news.bgov.com/bloomberg-government-news/colorado-gov...


We tried something similar at a previous company — ended up with 3 different bots all answering slightly differently depending on which doc chunk they hit. The consistency problem is real.

Curious how you handle updates. Like if someone edits the source doc, does the bot just start returning different answers or is there a review step?


Solid list. I'd add git log --all --oneline --graph pretty early on — gives you a quick sense of how active different branches are and whether this is a "one person commits everything" project or actually distributed. Helped me a ton on a job where I inheritied a monolith with like 4 years of history.

The git blame tip is underrated. People treat it like a gotcha tool but its maybe the fastest way to find the PR/ticket that explains a weird decision.


Yep. If your product needs me to install an app for a one-off thing, you've probably already lost me.

The crazy part is how many teams still treat the web as the demo and the app as the “real” product. For a lot of stuff it's the opposite now.

I know there are edge cases, but most of the time “download our app” just means “please care way more about our product than you currently do.”


>> The crazy part is how many teams still treat the web as the demo and the app as the “real” product.

But that's just the technical reality of what can be implemented on web vs. native because you are within an ephemeral browser tab and have all the restrictions that come with that.


Native has its place for sure — camera, sensors, offline, background tasks. But web has come a long way and for a lot of products it's genuinely enough. The issue is teams defaulting to "build an app" without asking whether the install friction is actually worth it for what they're building.


The friction is mostly learned helplessness it seems since software is easier to install than ever. But it's there nonetheless and the play store discoverability is pretty much gone, so yeah that's why I can't develop mobile only anymore. As a user, in general if the product is a website then I want a site, and if it's an application I use regularly I want an app.


I catch myself doing this more than I'd like to admit. Copy something from an LLM, it works, ship it, move on. Then a week later something breaks and I realize I have no idea what that code actually does! The speed is addicting but your slowly trading depth for velocity and at some point that bill comes due.


This resonates. I had a project sitting in my head for years and finally built it in about 6 weeks recently. The AI part wasn't even the hard part honestly, it was finally commiting to actually shipping instead of overthinking the architecture. The tools just made it possible to move fast enough that I didn't lose momentum and abandon it like every other time.


Pieter Levels is the obvious one. Not really a neat polished “blog”, more like watching someone ship in public for years.

Josh Pigford / Baremetrics had some good posts too. And the old Indie Hackers interviews were good for this before everything got a bit too content-brained.

Honestly most of the best ones aren’t big polished company blogs, they’re usually one person posting consistently while they’re still in the middle of it.


Running 26B locally is impressive but the latency math gets rough once your doing anything beyond chat. We switched from local inference to API calls for image generation specifically because cold start + generation time on consumer hardware made it impractical for any kind of automated workflow.

Local is great for experimentation but production workloads that need to run reliably at specific times still favor API imo. That said for privacy sensitive use cases where data cant leave the machine, setups like this are invaluable.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: