If you hang out on Reddit or Hacker News long enough, you’ll notice a pattern. Every few days someone posts:
“Supabase RLS is driving me insane”
“LangChain is death by a thousand abstractions”
“Neon cold starts are killing my API response times”
“PostHog autocapture is just noise”
I’ve used all four tools. And yeah, I’ve felt the pain. But I wanted to know: how bad is it really? Not just vibes, but actual hours lost. So I did something stupid for a student with free time.
I researched it Properly.
I read through GitHub issues, Reddit threads, Hacker News comments, and Discord rants. I even used AI to help me aggregate and categorize the complaints. (Yes, AI helped - I’m not hiding that I’m a student, not a journalistic purist.)
Here’s what I learned -
The short version:
Add it up for a team using all four? That’s 40+ hours a week of non-feature work. Basically one engineer just fighting tools.
And here’s the kicker: a lot of these problems already have solutions. People just don’t know about them.
Supabase RLS — the biggest trap
Supabase markets itself as “build in a weekend” But then you hit Row Level Security.
“I know I should learn Postgres better, but I feel misled.” — some Reddit user, speaking for thousands.
RLS policies aren't just access rules. They're PostgreSQL expressions that run inline with every query. When they fail, you get a generic “permission denied” and zero clue why.
One engineer said debugging RLS means opening nine different log tabs and manually correlating timestamps. Nine tabs For one bug.
LangChain — why I’m glad I didn’t build my AI agent with it
I almost used LangChain for Kommit (my AI commit CLI). Thank god I didn’t.
People describe debugging LangChain as “peeling an onion of abstractions until you cry” A simple API call becomes: PromptTemplate → OutputParser → Chain → AgentExecutor → LCEL pipe operators.
One team removed LangChain entirely after a year. They said: “We spent as much time understanding LangChain internals as building features”
The worst part? Hidden LLM calls. One developer reported an agent that called the wrong tool 14 times in a loop and burned $40 of API credits before returning gibberish.
My take: Use the raw OpenAI/Anthropic SDK unless you really need agent orchestration. LangGraph is better but still complex.
PostHog — the data cleanup tax
PostHog’s autocapture is both a blessing and a curse It tracks everything Clicks, rageclicks, form submissions, you name it.
But then you spend hours filtering out the noise
One GitHub issue I found: a developer was trying to stop $rageclick events from firing when users click up/down arrows on a date picker. Normal behavior Not a rageclick
PostHog has a “drop events” transformation, but that’s reactive. You’re cleaning up after the mess
What works: Disable autocapture from day one and implement explicit event tracking with a schema. Boring, but saves weekends
Neon — serverless is cool until it sleeps
Neon’s scale-to-zero saves money. But when your database wakes up, you get a 300-700ms cold start. On the free tier, it’s even worse.
And the connection pooling? It uses PgBouncer in transaction mode. That means SET search_path and prepared statements break. Your app works locally (direct connection) but fails in production (pooled connection). Fun times.
Fix: Set a minimum compute size to keep it warm or accept the cold start. Also maintain two connection strings - one pooled, one direct for migrations.
The pattern I didn’t expect
Almost every problem falls into three buckets:
Leaky abstractions - the tool hides complexity until it breaks, then you need to understand the internals anyway.
Configuration fatigue - too many env vars, YAML files, and dashboard settings that interact in weird ways.
Data/schema drift - changes made in dashboards instead of migrations, or events accumulating without governance.
None of this is new. Joel Spolsky wrote about leaky abstractions in 2002. But somehow every new tool repeats the same mistakes.
What I’m doing with this
I’m not writing this to bash the tools. They’re all well-engineered and solve real problems.
But as a student looking for an internship, I wanted to understand: what do engineers actually hate? Because if I can build something that fixes a small piece of that, maybe I can get paid to build it instead of fighting it.
I already have a few ideas. But first, I’m turning this research into a small series on Dev.to. Next post will be: “Three unsolved problems I found in the research (and what I’m building next).”
One last thing
If you’re using Supabase, LangChain, PostHog, or Neon - what’s your biggest pain point? I’m genuinely curious. I might try to build a fix for one of them.
Drop a comment or Find me on GitHub or Dev.to
– Mujib, sophomore who spends too much time in the terminal.
Top comments (0)