I fell into a trap where I tried to optimize every minor step in my daily routine. I d waste a whole afternoon building a complex setup for a task that only takes five minutes a month.
I realized that a basic manual process you understand instantly is way better than a complicated setup you constantly have to fix and maintain. Now I only automate things that waste significant time every day.
It is so easy to fall into the trap of thinking that adding more text fixes bad outputs. We used to write massive instructions packed with edge cases and the model would end up ignoring half of them anyway.
Trimming everything down to clear bullet points and simple variables made the responses way more reliable. Cutting out the fluff really does force the model to focus on the actual task.
Do you prefer keeping your system instructions short or do you like adding strict guidelines for formatting?
One thing I'm learning while building a product is that getting it built is only half the work. Finding the right people who actually need it is a completely different challenge.
I'm trying to understand how early-stage makers approach distribution without spending all their time posting everywhere or chasing vanity metrics.
I've been thinking about a few approaches, like sharing useful content, joining relevant communities, and talking directly to potential users.
I m a solo founder building Ember (Next.js + Supabase) with AI coding tools. Last week I did a security pass on my database. Here s what I found:
1. Row-level security checks which rows, not which columns. My users table let a logged-in user update their own row. That sounds fine, until you notice their own row includes the column that stores their plan. Fix: revoke table-wide UPDATE and grant it only on the columns the app really needs (streaks, achievements).
2. Policies combine with OR. An old open policy beats a new strict one. Audit all policies per table and drop the permissive ones.
3. Public pages need a narrow door. Shared roast links must be readable by logged-out visitors, but the table is owner-only. Solution: a SECURITY DEFINER function that looks up by a random share code and returns only public fields, with a fixed search_path and EXECUTE granted to anon and authenticated.
4. Test as the real roles. I run tests inside a single DO block that sets role anon or authenticated, checks results, and then raises an exception so everything rolls back. No test data left behind.
Biggest lesson: it works in the app proves nothing about what a logged-in user can do through the API.
Curious how others test their RLS policies. What s your setup?
Built a quick app using AI, and everything ran fine when i tested it alone.
The moment another person logged in, their edits started overwriting my work. Turns out the AI saved all user data into a single record because i didn't specify multi-user handling.
