I kept seeing the same complaints
Spend enough time in developer communities and a pattern appears:
“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 have used all four tools, and I have felt some of that pain too. But I wanted to know whether this was just internet frustration or a real pattern.
So I spent a week reading GitHub issues, Reddit threads, Hacker News comments, and Discord discussions. I also used AI to help group and categorize repeated complaints.
This is what I found.
The short version
The complaints were different, but the underlying shape was similar:
- Supabase RLS can be hard to reason about because policies run with every query and failures are often difficult to debug.
- LangChain can add layers of abstraction that make simple LLM flows harder to inspect.
- PostHog autocapture can create a large volume of events that teams later need to filter and govern.
- Neon trades operational simplicity for serverless constraints such as cold starts and pooling behaviour.
None of these tools are bad. They solve real problems. The issue is what happens when the abstraction leaks.
Supabase RLS: the invisible query layer
Supabase makes it possible to build quickly, but Row Level Security is often where the easy path ends.
RLS policies are not just a dashboard setting. They are PostgreSQL expressions evaluated alongside queries. When something breaks, developers can end up with a generic permission error and very little information about which policy caused it.
The lesson for me was simple: if I use RLS, I need to treat policies as production code.
That means versioning them, testing them, documenting the intended access model, and understanding what query is actually being evaluated.
LangChain: abstraction can become the problem
I almost used LangChain for Kommit, my AI commit CLI.
Then I looked deeper at how developers described debugging it. A small request can move through prompts, parsers, chains, agents, tool calls, and pipe operators before it reaches the actual model request.
That flexibility is useful for complex agent workflows. But for a straightforward product feature, it can make the system harder to observe than a direct SDK call.
My takeaway is not “never use LangChain.” It is this:
Use the smallest abstraction that still solves the problem.
For simple LLM features, a direct OpenAI or Anthropic SDK call is often easier to understand, test, and control. Add orchestration only when the problem genuinely needs it.
PostHog: the cleanup tax of autocapture
PostHog autocapture is powerful because it records a lot by default.
The downside is that “a lot” can quickly become noise. Clicks, repeated interactions, accidental events, and UI behaviour all become data that someone has to interpret later.
That creates a hidden cost: event cleanup.
The approach that seems to work best is less exciting, but much cleaner:
- Disable or limit autocapture where it is not useful.
- Define an explicit event schema.
- Track events that answer real product questions.
- Review and remove events that no longer matter.
Good analytics is not collecting everything. It is collecting the signals you can actually trust.
Neon: the serverless trade-off
Neon makes it easy to get a PostgreSQL database running without managing infrastructure. That is a great deal for many projects.
But serverless databases come with behaviour developers need to plan for. A sleeping compute instance can introduce a cold-start delay. Connection pooling can also behave differently from a direct database connection, especially around session-level settings and prepared statements.
The practical setup is usually:
- Keep a direct connection string for migrations and administrative tasks.
- Use a pooled connection string for application traffic when appropriate.
- Understand whether cold starts are acceptable for the user experience.
- Avoid assuming local database behaviour will exactly match production.
The abstraction is convenient — as long as you know where its edges are.
The pattern underneath all four tools
Almost every complaint I found fell into one of three categories.
1. Leaky abstractions
A tool hides complexity until something fails. Then you suddenly need to understand the underlying system anyway.
2. Configuration fatigue
Environment variables, dashboard settings, policies, connection strings, and YAML files begin to interact in ways that are difficult to see from one place.
3. Data and schema drift
Analytics events, database state, or configuration changes grow over time without a clear source of truth.
This is not a problem unique to modern developer tools. It is what happens whenever convenience sits on top of complexity.
What I am doing with this research
I am not writing this to bash Supabase, LangChain, PostHog, or Neon. They are all useful tools built by smart teams.
I wrote it because I want to understand what engineers actually struggle with.
As someone building systems and looking for an internship, that matters to me. The interesting opportunities are often not in building another generic wrapper — they are in reducing one painful, repeated piece of work.
This research gave me ideas for what to build next.
A question for you
If you use Supabase, LangChain, PostHog, or Neon: what is the one thing that wastes the most of your time?
I am genuinely curious. There may be a project hiding inside the answer.