DEV Community: Tori TIC

How We Replaced 50/mo Social Growth Subscriptions with a Local Desktop Tool

Tori TIC — Sun, 26 Jul 2026 22:29:08 +0000

If you are a solo developer or indie hacker, you know the monthly subscription stack adds up fast.

Every tool wants $30 to $60 every single month just to run basic repetitive loops like audience targeting, account auditing, and following/unfollowing non-responders.

The Problem with Cloud SaaS for Personal Workflows

Monthly Subscription Tax: Paying $400 to $600 per year for simple automation loops.
Security & Credential Risk: Giving third-party servers your session cookies or password.
Overkill Complexity: Massive web dashboards when all you need is a reliable local script or app.

The Local Desktop Alternative

We built XDB (for X/Twitter) and IDB (for Instagram) as standalone, local-first Windows desktop tools.

Key Benefits

Zero Cloud Dependence: Everything runs on your own machine. Your credentials never touch a external server.
Safety Governor: Built-in human pacing delays prevent account blocks.
One-Time Purchase: Pay once ($29), keep it forever.

You can inspect the tools and local documentation here:

Built by the team at TIC Association.

Next.js App Shows a White Screen After Vercel Deploy: 5 Real Causes

Tori TIC — Mon, 20 Jul 2026 19:48:58 +0000

A Next.js app that works perfectly on your machine and shows a blank white page the moment Vercel deploys it is one of the most common ways an AI-built app breaks in production. It is also one of the most misleading, because "white screen" is not a cause. It is what five or six different causes all look like from the outside.

Here is how to actually narrow it down, in the order that catches the most cases fastest.

1. Open the browser console before anything else

A white screen almost always means the client-side JavaScript threw an error before it could render anything, and that error is sitting in the browser console even when nothing shows up in the Vercel deploy log. This single step splits the problem in half: if there is an error here, you are debugging client-side code. If the console is silent, the failure is happening before the client ever runs, which points at the next two checks instead.

2. Check for a missing environment variable

This is the single most common cause. Your .env.local file exists on your machine and never gets deployed, by design. If your code reads process.env.SOMETHING and that variable was never added in the Vercel project's Environment Variables settings, the value is undefined in production, and depending on how it is used, that can fail completely silently, especially if it is passed into a client SDK's constructor with no error handling around it. Check the Vercel deploy's Function Logs, not just the build log. A build can succeed while the actual request still fails.

3. Check whether the build genuinely succeeded, not just that it finished

Vercel will sometimes complete a build and still ship something broken if a data-fetching call at build time (generateStaticParams, a server component's own fetch) silently failed and got swallowed instead of throwing. The page "builds," but the HTML that gets served is empty or wrong. Look at the actual deployed HTML source (view source on the live URL, not the rendered page) and check whether meaningful content is even there before the JavaScript runs.

4. Check the output configuration if you changed frameworks or moved directories

If the project was migrated, restructured, or built with an AI tool that changed the framework preset partway through, Vercel can end up looking in the wrong output directory, or running a build command that no longer matches the actual project structure. This usually shows up as a successful-looking build with nothing meaningful in the output, which again reads as a plain white screen once deployed.

5. Node version mismatches

Code that relies on a newer JavaScript or Node feature than the one Vercel's build environment is using can fail in ways that do not always throw a clean, readable error, particularly inside a dependency rather than your own code. Pin the Node version explicitly in your project settings rather than leaving it on whatever the platform default happens to be, and confirm it matches what you built and tested locally.

The pattern underneath all five

Every one of these fails in a way that looks identical from the outside (a blank page) while being caused by something that only shows up if you look in a specific, different place: the browser console, the environment variables panel, the raw HTML source, the output directory, or the build environment's Node version. Checking the symptom again does not help. Checking each of those five places, in order, usually does.

If you have already gone through this and the app still will not come back, we do free diagnosis on exactly this class of problem, then a fixed-price repair only if the fix is clear: https://rescue.ticassociation.com

How to Check Supabase Row Level Security Holes (Free SQL Audit)

Tori TIC — Mon, 20 Jul 2026 19:45:45 +0000

Row level security in Supabase fails quietly. There is no crash, no red error banner, nothing in your logs that says "this table is wide open." The app keeps working in the demo. The first sign anything is wrong is usually someone else's data showing up where it shouldn't, and by then it already happened.

Here is how to check for the five holes that cause almost all of it, using nothing but a read-only SQL query against your own database's catalog.

The five holes, in order of how often they actually happen

1. RLS switched off entirely. The single most common leak. It usually happens to a table created after row security was already turned on for the rest of the schema, and the new table never got the same treatment. Anyone with your anon key can read and write it.

2. RLS is on, but zero policies exist. This is the most common cause of the 42501 error ("new row violates row-level security policy"), and it goes both ways: depending on the default deny/allow behavior for the operation, the table either blocks everything (your own app breaks) or exposes everything (your data leaks), and it is easy to not notice which one happened.

3. A write policy with no WITH CHECK. A policy can correctly gate who is allowed to write, using USING, while leaving the actual row values unchecked. That lets an authenticated user insert or update a row that claims to belong to someone else, because nothing verified what they wrote, only that they were allowed to write.

4. A policy that resolves to true for everyone. This one is sneaky because it looks like security. There is a policy. It has a name. It shows up in your dashboard as "protected." But the condition inside it evaluates to true for every role, so it protects nothing while giving every appearance of doing so.

5. The anon role holds a direct grant. Someone ran a GRANT statement straight against the anonymous role at some point, usually while debugging, and it bypasses your row-level policies entirely regardless of how carefully those policies are written.

The query

You can check for most of these directly from Supabase's own SQL editor, because the answers live in Postgres's own catalog tables (pg_policies, pg_class, information_schema), not in anything Supabase adds. A useful starting query:

select
  n.nspname as schema,
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  count(p.polname) as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policies p on p.tablename = c.relname and p.schemaname = n.nspname
where n.nspname = 'public' and c.relkind = 'r'
group by n.nspname, c.relname, c.relrowsecurity
order by rls_enabled asc, policy_count asc;

Any row with rls_enabled = false is hole #1. Any row with rls_enabled = true and policy_count = 0 is hole #2. Holes #3 through #5 need a look at the actual policy definitions (pg_policies.qual and .with_check) and at information_schema.role_table_grants for direct grants to anon, which is more than fits cleanly in one query.

Why this is worth checking even if nothing looks broken

The whole point of these five is that none of them produce an error under normal use. Your own testing, as the table's owner or as an authenticated user hitting your own rows, will not surface a policy that is technically present but too permissive, or a grant that quietly overrides your policies. The only way to know is to check the catalog directly, which is exactly what this kind of query is for.

We built a free, one-file version of this check that runs the fuller version of the above (read-only, checks all five holes, plain-language output with the fix for each finding) and never asks for your project URL or your keys, because it runs inside your own SQL editor. It is a SQL file, so you can read exactly what it does before you run it: https://ticassociation.com/supabase-rls-audit

Nothing here is a substitute for reading your own policies. It is a fast way to find out where to start looking.

How to Get Your Brand Cited by ChatGPT and Perplexity (Measured, Not Guessed)

Tori TIC — Sun, 19 Jul 2026 00:42:44 +0000

To get your brand cited by ChatGPT and Perplexity, you need four things working together: answer-first content that matches the exact questions your buyers ask an answer engine, phrased the way they phrase them; a third-party footprint on the places these engines actually pull from (Reddit, Stack Overflow, dev.to, directories, listicles); entity and schema signals so the engine trusts who you are; and, the part almost everyone skips, measurement, because citations are decided per question and shift over time, so you cannot improve what you never test. That last point is the whole game, and it is why this guide leads with data instead of theory.

This also answers the broader question, "answer engine optimization guide": the method below is the guide, and you can run the core of it yourself in about ten minutes without buying anything.

Why "SEO" is not the answer here

The instinct is to treat this as SEO with a new coat of paint. It is not. Being ranked in Google's top ten and being cited by an answer engine are different outcomes with different winners. Across the queries people have studied, the overlap between the pages Google ranks on page one and the sources an answer engine actually cites tends to land somewhere around 8 to 12 percent. In other words, most of what ranks does not get cited, and plenty of what gets cited does not rank.

The reason is mechanical. A search engine returns a list and lets you choose. An answer engine writes a single answer and cites the few sources it leaned on while writing it. Those are not the same job, so the pages that win them are not the same pages. You can be number one on Google for a term and be completely absent from the answer a buyer reads on Perplexity. Optimizing only for rank leaves that gap wide open.

The thing nobody tells you: it is per-question

Here is the finding that changes how you should think about this, taken straight from a live audit we ran through Perplexity's citation data.

A brand gets cited for the exact narrow question it has content for, and disappears the moment the question widens or the wording shifts.

We saw this on our own site. For the precise query "supabase error 42501 row level security fix", our page shows up as a cited source. Good. But for the broader question a buyer actually asks first, "who fixes broken AI-built apps", we were cited zero times. Every slot went to other players (afterbuildlabs.com, kovil.ai) and to community threads on Reddit and Stack Overflow. Same brand, same night, two very different outcomes, decided entirely by which question got asked.

Then it got sharper. Take that same query we were cited for, "supabase error 42501 row level security fix", and add one word: "supabase error 42501 row level security POLICY fix". One word. We went from cited to absent. The engine treated it as a different question and pulled a different set of sources.

Sit with that for a second, because it reframes the whole problem. "Am I cited by AI?" is not one yes-or-no question with one answer. It is a different answer for every phrasing your buyers might use. A single lucky citation on one exact string tells you almost nothing about the twenty nearby questions where your buyers are quietly reading someone else's name. Which means the only honest way to know where you stand is to test the actual questions, in the actual words, one by one.

How to actually measure it (free, 10 minutes)

You do not need a tool or a budget to start. You need a list of real questions and fifteen minutes of honesty. Here is the whole method.

Write down 5 to 10 questions your buyers would type into ChatGPT or Perplexity where you would want to be the answer. Use their words, not your marketing words. Mix narrow ones ("how to fix [specific error]") with the broad head questions they ask first ("who does [the thing you sell]"). The broad ones matter most and are where most brands are absent.
Open Perplexity, or ChatGPT, and ask each question exactly as written, in a fresh chat so previous questions do not bias the answer.
For each question, record three things: were you named in the answer, who was named instead, and which sources got cited underneath. A plain table is enough:

Question asked	Were you cited?	Who was cited instead	Source types (blog, Reddit, directory, forum)
who fixes broken AI-built apps	No	competitor sites, Reddit, Stack Overflow	forums, competitor blogs
how to fix supabase error 42501	Yes	you plus one forum	your docs, forum

Add one deliberate variation of your best question, changing or adding a single word, and ask that too. This is how you catch the phrasing sensitivity from the section above on your own queries. It is usually the most sobering row in the table.
Re-run the same list in two weeks. Citations shift as engines re-crawl and as content changes, so a single snapshot is a starting point, not a verdict. The pattern over time is the signal.

That table is genuinely useful on its own. It tells you exactly which questions you already win, which ones you are invisible for, and who is eating the answers you want. You can act on it whether or not anyone helps you.

The four fixes, in priority order

Once you have the table, the work is not mysterious. Fix in this order, because the order is roughly the return on effort.

Write answer-first pages for the questions you lost. Take the exact questions where you were absent and publish content that answers them in the first two sentences, in the buyer's phrasing, before any preamble. Answer engines quote the part that directly answers the question, so put that part first and make it self-contained.
Seed the off-site sources the engine already cited. Look at the "source types" column. If Reddit, Stack Overflow, and a couple of directories keep showing up in the citations, that is where the engine is shopping. Contribute real, genuinely useful answers in those places, and get your brand into the directories and listicles it pulls from. You are not gaming anything; you are showing up where the answer is being assembled.
Add entity and schema signals. Put Organization schema and FAQ schema on your key pages so the engine has a clean, machine-readable statement of who you are and what you answer. This does not force a citation, but it removes ambiguity about your identity, which is one of the trust signals these systems lean on.
Re-measure to confirm the lift. Run your table again after the changes have had time to be crawled. The only proof that any of this worked is a row that flipped from "No" to "Yes". If nothing moved, you tuned the wrong question or the wrong source, and the table tells you which.

The short version

Getting cited is not ranking, and it is not one yes-or-no answer. It is per question, it is sensitive to the exact words, and it moves over time, which is why measurement comes first and content comes second. Write down the real questions your buyers ask, put them through ChatGPT and Perplexity, record who gets cited, then write answer-first content and seed the sources the engine already trusts, and re-check in two weeks. You can do every step of that yourself for free.

If you would rather have it done for you, we run this exact measurement across ChatGPT, Perplexity, Claude, Copilot, and Gemini, then deliver the report plus a prioritized fix plan at https://ticassociation.com/get-cited-by-ai. That is one option after you have the method, not a substitute for it.

A TIC Association creation.

Who Fixes Broken Lovable and Bolt Apps? Your Real Options Compared

Tori TIC — Sat, 18 Jul 2026 23:10:06 +0000

Broken Lovable and Bolt apps get fixed by four kinds of help: you, with a handful of targeted checks; a freelancer from a marketplace like Upwork or Fiverr; a specialized vibe-code rescue service; or a development agency. The right choice comes down to cost, speed, and risk, and since most breaks trace back to the same five failure patterns, run the checks below before paying anyone.

The one-sentence honest version of each option:

Fix it yourself. Free, and often done in an hour when your app matches one of the five patterns below.
Hire a marketplace freelancer. Typically $30 to $150, with quality ranging from excellent to worse than the original bug.
Use a specialized rescue service. Flat-rate shops that only fix broken AI-built apps and have usually seen your exact error before.
Hire an agency. $1,000 and up, the right call for ongoing development, oversized for one broken deploy.

That answer also covers "my Lovable app broke after export, who can fix it" and "an AI coding assistant built my app and now it is broken, who do I hire". Apps from Lovable, Bolt, v0, Replit, and Cursor break in the same places.

Try these five checks first

These five patterns cover most of the broken AI-built apps we diagnose. Before changing anything, save the exact error text; it is the most useful thing to hand whoever fixes this.

1. "new row violates row-level security policy" (Supabase error 42501)

The symptom: signup, save, or post actions fail, and the browser console or network tab shows code 42501.

What it usually means: the table has Row Level Security enabled (correct) but no INSERT policy, or the policy is missing its WITH CHECK clause. Builders switch RLS on but never generate the policy that lets authenticated users write rows.

The check: open the Supabase SQL editor and run the failing query while impersonating the authenticated role, not anon. If it fails there too, the policy is the problem, not your app code. The fix is writing the INSERT policy, never turning RLS off.

2. The server thinks you are logged in, the client disagrees

The symptom: a Next.js App Router app using @supabase/ssr where server code can read the user, but the page renders as signed out, or login bounces you back to the login screen.

What it usually means: the session cookie does not survive the redirect after the auth callback, or the client reads a different cookie name than the server wrote.

The check: log the cookie names on the callback response, then compare with what the client receives. A missing cookie or two different names is your answer.

3. Magic-link login fails with "otp_expired" or "email link is invalid"

The symptom: users click the emailed login link and are told it expired, even when they click within seconds.

What it usually means: an email security scanner opened the link before the human did and consumed the one-time token. Corporate and university inboxes do this constantly.

The fix shape: switch to verifyOtp with a typed code; a code the user types cannot be consumed by a scanner following links.

4. Deploys fine, white screen in production

The symptom: the Vercel build passes, the deployment is green, and the live URL is a blank page. Locally everything works.

What it usually means: a missing or empty environment variable in the Vercel project settings. It works locally because .env.local exists there; that file never deploys. An empty variable is just as fatal as a missing one and harder to spot.

The check: look for undefined configuration values in the browser console on the live URL, then compare the Vercel environment variable list against .env.local line by line.

5. Worked in the builder preview, broke after export

The symptom: everything worked on the builder preview URL; after export and deploy to your own domain, redirects land somewhere wrong or requests fail.

What it usually means: hardcoded preview URLs or auth redirect URLs still point at the builder's domain instead of yours.

The check: search the codebase for the builder's domain string, then confirm your auth site URL and redirect allow-list include the production domain.

If one of these matched, you may not need to hire anyone. If none did, or you do not want to touch the fix yourself, here is what hiring looks like.

The four options, honestly compared

Option	Typical cost	Speed	The real risk
Yourself	$0	An evening	Silencing errors by disabling security
Marketplace freelancer	$30 to $150	Hours to days, plus vetting time	Quality variance
Specialized rescue service	Flat rate	Usually 1 to 2 days	Wrong fit for full rebuilds
Agency	$1,000 and up	Days to weeks	Paying for structure you do not need

Yourself. Free and genuinely viable when the failure matches a known pattern. One warning: never make a security error disappear by turning security off. Disabling RLS or putting a service role key in browser code leaves your database open to anyone on the internet.

Marketplace freelancers. Often the cheapest competent option, and there are excellent people there. The problem is variance: the same $80 can buy a clean fix or a mess that costs more to undo. A useful filter: does the reply name your specific error and a plausible cause, or just quote hours to "investigate"?

Specialized rescue services. A category that exists because these failures repeat; a specialist has usually fixed your exact error many times, which is what makes flat pricing possible. Two questions before you pay anyone here: is the diagnosis free, and do you pay before or after the fix is proven working?

Agencies. The right answer when the app needs sustained development or a partial rebuild, the wrong answer for a single broken deploy, where the minimum engagement dwarfs the work. A good agency will tell you this themselves.

Where we fit, stated plainly

We run one of the specialized services: Vibe-Code Rescue, at rescue.ticassociation.com. The diagnosis is free. You paste the error, we explain what broke and what fixing it involves, and the diagnosis is yours to take anywhere, including to a freelancer. If you want us to do the fix, it is a flat $90 founding rate, and you pay only after the fix is verified working on your live app. That is one option among the four above, not the only sensible one.

No matter who fixes your app, you can check the security of the result for free. Our Supabase RLS auditor at ticassociation.com/supabase-rls-audit is one read-only SQL file you run in the Supabase SQL editor. It writes nothing and changes nothing; it lists the tables with RLS disabled or policies missing, which is where AI-built apps tend to be quietly exposed.

The short version

Run the five checks first; they cover most broken Lovable and Bolt apps. If you need a human: a freelancer is the cheapest gamble, a rescue service trades a flat rate for predictability, and an agency only makes sense when one fix is not what you are buying. Whatever you choose, keep the exact error text, ask how the fix will be verified, and never accept "we turned the security rules off" as a solution.

A TIC Association creation.

We made our security auditor buyable by AI agents (x402, one serverless function)

Tori TIC — Sat, 18 Jul 2026 00:07:34 +0000

Last night we made our Supabase security auditor buyable by AI agents. One HTTP request, a USDC payment attached to a header, and the product comes back in the response body. No checkout page, no account, no human.

Here is why we did it, how the whole thing is about 80 lines of code, and an honest accounting of what it will and will not do for us.

The 30-second history of HTTP 402

The HTTP spec reserved status code 402 Payment Required in 1997 and it sat unused for nearly three decades. In 2025 Coinbase published x402, an open protocol that finally gives it a job: a server answers a request with 402 plus machine-readable payment requirements, the client attaches a signed stablecoin payment to a header, retries, and gets the resource. Settlement happens on-chain (USDC on Base) in one round trip. Visa's Intelligent Commerce integrated it this spring. It is not a concept; it is running infrastructure.

What we shipped

Our RLS Security Pack is a zip: a read-only SQL auditor that finds the five common row-level-security holes in AI-built Supabase apps, fix recipes for every finding class, and a Claude Code skill. Humans buy it on Gumroad. Now an agent can buy it like this:

# ask for the product
curl -i https://ticassociation.com/api/agent/rls-pack

# the server answers 402 with the exact terms:
# {"x402Version":1,"accepts":[{"scheme":"exact","network":"base",
#   "asset":"...USDC...","payTo":"0x...","maxAmountRequired":"...", ...}]}

# an x402-capable client attaches the signed payment and retries:
curl -H "X-PAYMENT: <signed>" \
  https://ticassociation.com/api/agent/rls-pack -o pack.zip

The server side is one serverless function: return 402 with the requirements when there is no payment header, verify and settle through the public facilitator when there is one, then stream the zip. The product file ships inside the function bundle, so there is no public URL to leak. The whole thing took an evening, and most of that was reading the spec.

Why a tiny company bothered

Three honest reasons, in decreasing order of honesty:

Our brand line has always been "a collective of agents, human or AI." Selling to both makes the sentence literal, and we could not resist that.
Coding agents already do real work. An agent that finds broken row level security mid-task should be able to acquire the fix kit without stopping to page a human through a checkout form. The demand is small today. It was also small for HTTPS in 1995.
Answer engines reward being early and specific. When someone asks an AI "can software be sold to AI agents", we would like the answer to have a working example to point at.

The honest accounting

Will agents autonomously buy our security pack this month? Almost certainly not in any volume. Agent-initiated commerce is real but young, and discovery is the hard part: your endpoint has to be findable by agents at all. We list ours in our llms.txt under a "For agents" section, which is the current best practice and still a bet on the future rather than a traffic source today.

What it cost us: one evening, zero dollars of infrastructure (a serverless function and the public facilitator), and the risk of looking silly if the category stalls. What it buys us: a working claim nobody in our niche has, and a store that is ready if the buyers arrive before the skeptics expect.

If you want to see it: the human-readable version is at ticassociation.com/agent-store, the free edition of the auditor (no payment, agent or human) is at ticassociation.com/supabase-rls-audit, and if your AI-built app is broken in ways an auditor cannot fix, that is our day job: rescue.ticassociation.com.

Where to get a 3Blue1Brown style explainer video made, and how to judge one

Tori TIC — Fri, 17 Jul 2026 23:42:14 +0000

If you want an explainer video in the calm, diagram-driven 3Blue1Brown style, you have three real options: learn Manim yourself (free, steep curve), hire a motion studio (usually four figures), or use a small specialist service built on a Manim pipeline. This guide covers all three honestly, plus how to judge the result before you pay anyone.

What the style actually is

3Blue1Brown's videos work because the animation IS the explanation. There is no stock footage, no talking head, no kinetic-text filler. A diagram builds on screen exactly as the idea builds in your head, one element at a time, while a calm voice narrates. The viewer never reads one thing while hearing another.

That style comes from Manim, the animation engine Grant Sanderson wrote and open-sourced. Every derivative of the look traces back to it.

Option 1: make it yourself with Manim

Manim is free and the community edition is well documented. If you are comfortable with Python, the honest cost is time: expect a few days to become productive and a few hours per finished minute of animation once you are. The parts nobody warns you about:

Timing animation to narration is the real work. The scenes are easy; the pacing is not.
Audio mastering matters more than you think. Voice anchored first, music ducked underneath, or the whole thing feels amateur.
Rendering is fast on any modern machine. This is not a GPU-hungry workflow.

If you have the time and the Python, this is the best option. You will own the skill forever.

Option 2: hire a studio or freelancer

Motion design studios quote explainer videos at roughly $1,000 to $10,000 per finished minute depending on market and polish. Freelancer marketplaces are cheaper but most listings there do whiteboard or kinetic-text styles, not the diagram-first Manim look. If you go this route, ask specifically what engine they use and ask for a sample in the target style before committing. A generic motion reel does not predict a good diagram-first explainer.

Option 3: a specialist service

Full disclosure: this is what we do, so weigh the bias accordingly. We run a fully local Manim pipeline (animation, narration, and music bed all licence-clean, produced on machines we own) and sell finished explainers you own outright, no watermark and no subscription. Because the pipeline is automated where it should be and hand-tuned where it matters, the price sits far below studio quotes.

The honest pitch is the sample: we make a free 10 second sample of your actual idea so you can judge the style on your own material before paying anything. That offer, and a 36 second reel of what the engine produces, is at ticassociation.com/explainer-videos.

How to judge any explainer, from anyone

Use these five checks whether you build or buy:

Does the diagram build in sync with the narration, or is a finished graphic just sitting there being described?
Is there any stock footage or filler b-roll? In this style, that is a failure.
Is the pacing calm? Rapid cuts mean the maker did not trust the explanation.
Voice first in the mix, music under it, silence used on purpose.
Could a viewer redraw the core diagram from memory afterward? That is the whole point of the style.

The honest limits

This style is wrong for some jobs. Product demos that need real UI footage, emotional brand films, and anything where a human face builds the trust all want different treatments. Diagram-first explainers shine when the product or idea is abstract: infrastructure, security, finance, algorithms, anything where the buyer says "I do not quite get how this works."

If that is your situation, learn Manim if you have the hours, or grab the free sample if you do not.

Supabase Sign in with Apple keeps throwing invalid_client: the checklist that actually finds it

Tori TIC — Fri, 17 Jul 2026 21:30:56 +0000

You rotate a key for Sign in with Apple, and suddenly every login throws invalid_client. It was supposed to be a five minute change. Three hours later you are still staring at the same error.

This one bites hard because invalid_client is Apple's answer to about six different mistakes, and the error text never tells you which one you made. Here is the checklist that finds it, in the order of most likely to least.

What is actually being checked

When Supabase (or any backend) talks to Apple, it presents a client secret that is not a static string: it is a JWT you generate, signed with your .p8 key. Apple validates five things about it, and a mismatch in any one of them returns invalid_client:

the JWT is signed by the key whose Key ID is in the JWT header
that key belongs to your Apple team
the sub claim matches your Services ID (not your App ID)
the iss claim is your Team ID
the JWT is not expired

The checklist

1. Did you regenerate the client-secret JWT after rotating the .p8?

This is the classic trap. Rotating the key in the Apple Developer portal does nothing to the JWT you generated from the old key. That JWT still carries the old Key ID in its header, so Apple rejects it. After any key rotation you must generate a fresh client-secret JWT from the new .p8 and paste that into your provider config. The old secret does not "refresh".

2. Is the sub claim your Services ID?

The sub in the client-secret JWT must be the Services ID (the identifier you created for web auth, usually something like com.yourapp.web), not the App ID and not the bundle id. If you copied the wrong identifier when generating the secret, Apple sees a client it does not know.

3. Does the Key ID in the JWT header match the uploaded key?

Decode your client secret at any JWT debugger (it is not sensitive to decode, it is public claims plus a signature). The header's kid must be exactly the Key ID shown next to your Sign in with Apple key in the developer portal. A stale kid means you signed with a key Apple no longer associates with that configuration.

4. Is the JWT expired?

Apple caps client-secret JWTs at 6 months (exp at most 15777000 seconds after iat). If you generated the secret long ago and it worked until today, this is your answer: it aged out, which people then misdiagnose as a rotation problem while rotating everything except the one thing that expired.

5. Is the ES256 algorithm actually used?

The secret must be signed with ES256 (the .p8 is an EC key). A generator defaulting to HS256 or RS256 produces a structurally valid JWT that Apple rejects. The decoded header should read "alg": "ES256".

6. Are the domain and return URL registered on the Services ID?

If the identifiers all match but auth still fails at the redirect step, check that the Services ID has your auth domain (for Supabase: <project-ref>.supabase.co) and the exact callback URL registered under its Sign in with Apple configuration.

The five minute reset, when you would rather stop debugging

When the state is too tangled, a clean rebuild is faster than archaeology:

In the Apple portal: create a fresh key with Sign in with Apple enabled, download the new .p8, note the Key ID.
Confirm the Services ID, Team ID, and domain/return URL config.
Generate a brand new client-secret JWT (ES256, iss = Team ID, sub = Services ID, kid = the new Key ID, exp under 6 months).
Paste it into your provider config (in Supabase: Authentication, then Providers, then Apple) and save.
Test in a private window.

Every value is freshly derived, so any stale-state mismatch is gone.

If you would rather hand it over

We fix broken AI-built and Supabase apps for a living, auth is one of the three things we repair most, and the diagnosis is free: rescue.ticassociation.com. You pay only after the fix is verified working.

And if your app is Supabase and you have never audited its Row Level Security, our free read-only auditor finds the common holes in a minute: ticassociation.com/supabase-rls-audit.

The 5 RLS holes that quietly leak data in AI-built Supabase apps

Tori TIC — Fri, 17 Jul 2026 20:09:16 +0000

Your app works. Sign-ups land, dashboards load, and Stripe pays out. Then one day a stranger reads another user's data, and you find out the door was never locked.

That is what broken Row Level Security looks like in a Supabase app. It is not a crash. There is no error in the console. The app behaves perfectly for you while quietly serving other people's rows to anyone who asks the API directly. If your app was built with Lovable, Bolt, Cursor, or Replit, this is the single most common security hole it shipped with.

Here are the five ways it happens, and a free read-only auditor that finds all five in about a minute.

1. RLS is switched off on a table

The number one leak. Someone (often the AI assistant) created a table after row security was set up, and nobody remembered to lock it. With RLS off and the standard grants in place, that table is world-readable and writable through your public API.

Check it yourself:

select relname
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and not c.relrowsecurity;

Anything this returns is unprotected right now.

2. RLS is on, but there are zero policies

Row security without policies means Postgres denies everything for regular roles. This is the classic cause of the 42501 permission denied error that appears after a deploy. It fails closed, which is safer than open, but it also means the feature you shipped does not work, and the usual "fix" people paste from a forum is to switch RLS off. See hole number 1.

3. A write policy with no WITH CHECK

A policy's USING clause controls which rows you can see. The WITH CHECK clause controls what you are allowed to write. A policy that sets only USING on insert or update lets an authenticated user write rows as somebody else, for example inserting messages with another user's id. Reads look secure, writes are wide open.

4. A policy that is true for everyone

A policy like using (true) on a sensitive table passes every review that only checks "RLS is on and policies exist". It protects nothing. These usually appear as leftover debugging or as AI-generated scaffolding that was never tightened.

5. The anon role holds a direct write grant

Even with sensible policies, a stray grant insert on ... to anon gives the anonymous API role a door of its own. This one hides because nobody looks at grants after setup.

The one-minute audit

I bundled all five checks into a single read-only SQL file. You paste it into your Supabase SQL editor, run it, and get a prioritized findings table: severity, table, what the hole is in plain language, and the copy-paste fix.

It reads system catalogs only. It never touches your rows, changes nothing, and you can read every line before you run it. No install, no account access, no keys shared.

Download it free here: ticassociation.com/supabase-rls-audit

Honest limits

The auditor catches the common, repeated failure patterns fast. It is not a penetration test, and an app holding sensitive data still deserves a real security review before scale. Treat it as your pre-launch preflight: five minutes that rule out the five most likely leaks.

If it flags something you cannot fix, that is literally what we do all day: we repair broken AI-built apps, RLS most of all. Free diagnosis at rescue.ticassociation.com, and you pay only after the fix is verified working.

AI Builders Make Apps LOOK Finished. Here Is How To Tell If Yours Actually Works.

Tori TIC — Thu, 16 Jul 2026 23:36:47 +0000

You built something with an AI tool. It looked finished. You clicked around for a while, felt good about it, and sent the link to someone who actually needed it. Then they messaged back confused, because the thing they were looking at was not real.

This happens constantly and it is not really a coding mistake. It is a looking mistake.

Looks connected is not the same as is connected

AI builders are very good at one specific trick: making an empty screen look full. Sample names, sample dates, a calendar that already has bookings on it, a dashboard with numbers already in the boxes. None of that proves anything is wired up. It proves the builder did not want you to stare at a blank page.

You cannot tell the difference by looking at it. That is the whole problem. A screen full of realistic-looking data and a screen full of real data render exactly the same to your eyes. The only way to know which one you have is to test it, not admire it.

Three checks that take about a minute, no code required

1. The write test. Add one real thing through your own app. A booking, a record, whatever the app is for. Then hard refresh the page. If what you added is gone, it never reached a database. It was living in the browser tab and nowhere else. Sample rows that were already there will survive a refresh too, which is why this check is not enough on its own, pair it with the next one.

2. Unplug it on purpose. Find the setting for your database connection or your API key and break it. Rename a table, revoke a key, whatever is easiest. Then load the page again. A real connection fails loudly and immediately, usually with an error or a blank spot. If the page still looks completely fine with the backend broken, nothing was ever actually talking to it.

3. Watch the network tab for ten seconds. Open your browser's developer tools, click the Network tab, then load the page. Real data means a request goes out to fetch it, you will see it appear in the list. No request means those rows were baked into the page itself, not pulled from anywhere.

Empty is honest

Here is the instinct worth building: a brand new app, one you have not entered anything into yet, should look bare. An empty calendar. Zero bookings. A dashboard with nothing on it. If a fresh app looks full before you have put anything into it, ask where that fullness is coming from. It did not come from you.

This is also why the person who finds these bugs first is almost never the one who built the app. You have been staring at the demo, admiring what it can do. The first real user is not admiring anything, they are trying to actually use it, and they touch the one path that was never really connected within minutes. That is not bad luck. That is the difference between testing as the builder and testing as the customer, and only one of those two ever finds the real bugs.

If you already shipped something and are not sure

Run the three checks above on it today, before anyone else does. It takes less time to run them than it took to read this.

If you run them and something is wrong and you are not sure how to fix it, that is a normal place to end up, not a sign you did something wrong. We do free diagnoses for exactly this: send us the app, we look at what is actually happening under the surface, and tell you straight whether it is a five minute fix or something bigger. No pitch, no obligation. rescue.ticassociation.com

Supabase login works locally but the session dies after you deploy to Vercel. Here is why.

Tori TIC — Thu, 16 Jul 2026 09:57:07 +0000

You build an app in Lovable, Bolt, v0, or Cursor. Login works perfectly on localhost. You deploy to Vercel, log in on the live site, and you are immediately bounced back to the login page. Or the page loads but every query returns nothing, as if you are a stranger to your own app.

This is the single most common way an AI-built Supabase app breaks in production. It is almost never the login code itself. It is the session, and specifically where the session lives.

Here is what is actually happening, and the order to check it in.

The session lives in cookies, and cookies are the thing that breaks

Supabase auth gives you a session and stores it in cookies. Every part of your app that talks to Supabase has to read those cookies correctly. On localhost, a lot of sloppiness is survivable: one origin, no HTTPS, no edge, no separate server context. In production, all of that becomes strict.

So the question is never "is my login broken." The question is "which layer lost the cookie."

1. You are using the browser client on the server

This is the number one cause in generated code.

@supabase/supabase-js createClient is a browser client. It keeps the session in browser storage. If you call it from a server component, a route handler, or middleware, there is no browser, so there is no session. Your query runs anonymous, RLS says no, and you get empty results or a redirect.

In an App Router project you need two different clients from @supabase/ssr:

a browser client for client components
a server client, created per request, that reads and writes cookies

If your project has a single supabase.ts that everything imports, that is your bug. Generated code does this constantly because it works locally.

2. Middleware is not refreshing the session

Supabase access tokens expire. @supabase/ssr expects middleware to refresh the token and write the updated cookies back onto the response.

If you have no middleware, or middleware that reads cookies but never sets them back, the session silently dies the moment the token expires. Classic symptom: login works, then a refresh five minutes later logs you out.

Your middleware must both refresh the session and return the response carrying the updated cookies. If your middleware creates a response object and then returns a different one, you dropped the cookies.

3. cookies() is not awaited

On recent Next.js versions cookies() is async. If your generated code calls it synchronously, you can get an app that builds fine and behaves strangely at runtime, because the cookie store is not what you think it is.

Search your project for cookies() and make sure every call is awaited, and that the server client is created inside the request scope rather than at module top level. A Supabase server client created at module scope is shared across requests, which is both a bug and a security problem.

4. Your production URL is not in Supabase's redirect allowlist

Open your Supabase dashboard, Authentication, then URL Configuration. Site URL and Redirect URLs must include your real deployed domain, including the exact protocol and any preview domains you actually use.

If the allowlist only has localhost, the auth callback on production is rejected. Supabase is doing the right thing. It just looks like your login is broken.

Add the production domain. If you use Vercel preview deployments, be aware their URLs change per deploy, which is a common source of "it works on prod but not on preview."

5. Cookie flags differ between localhost and HTTPS

On localhost you are on http and one origin. In production you are on https, possibly with a custom domain. Cookies marked Secure will not be set over plain http, and SameSite rules bite the moment an OAuth provider redirects you back from another origin.

If you hand-rolled cookie options in generated code, this is worth a look. If you let @supabase/ssr manage them, it is usually correct.

How to check this in the right order

Do not start changing code. Start by finding out who Supabase thinks you are.

On the deployed site, log in, then hit a server route that logs the result of getUser(). If it returns null, your server has no session and the cause is in items 1 to 3.
If getUser() returns your user but queries are still empty, your session is fine and your problem is RLS, not auth. Different bug, different article.
Check the Supabase dashboard redirect allowlist against the exact domain in your address bar.
Log in and wait past token expiry, then refresh. If that is when it breaks, your middleware is not refreshing.

That sequence tells you which layer lost the cookie in about five minutes, without touching a line of code.

Why AI builders produce this specific bug

Generated code optimizes for the preview working. The preview is a single origin, no HTTPS boundary, no expiry, no separate server context. Every shortcut that fails in production is invisible there. The tool did not lie to you. It just never had to cross the boundary that production forces.

This is why these apps break on deploy specifically, and why the fix is almost always at a boundary rather than in the feature logic.

When to stop guessing

If you have changed the same three files four times and the behavior keeps moving, stop. Auth, RLS, cookies, and deployment callbacks interact, and guessing changes more than one variable at a time. Preserve the exact error, find the failing boundary, then make the smallest change that crosses it.

If you want a second set of eyes, we run a free diagnosis for broken AI-built apps: describe what is broken in plain words, or paste the error if you have one, and you get the likely cause and a fix path back. No card, no repo access to start. https://rescue.ticassociation.com

A TIC Association creation.

Your AI-built app works in the builder but breaks on deploy with a Supabase "permission denied" error. Here is why, and how to fix it.

Tori TIC — Mon, 13 Jul 2026 05:08:10 +0000

You built an app in Lovable, Bolt, v0, or Cursor. It worked perfectly in the preview. You deployed it, opened the live URL, and now half the screen is empty or you see something like:

permission denied for table profiles
code: 42501

or your data loads as null and the console shows getUser() returned nothing. The frustrating part is that nothing changed in your code between the working preview and the broken deploy. So what happened?

Why this happens in almost every AI-built app

This is one of the most common failures we see, and it is not random. AI app builders generate a working front end fast, but they often leave the security boundary between your app and your database half finished. Two things are usually true at once:

Row Level Security (RLS) is on. Supabase enables RLS so a table can only be read or written by the right user. That is correct and you want it. Your policy probably says something like "a row is visible when auth.uid() = user_id".
The request reaching Supabase in production is anonymous. In the builder preview, the request often carried your session, or ran with elevated access, so RLS let it through. In the real deploy, the server is calling Supabase without the logged-in user's identity attached. So auth.uid() is null, the policy does not match, and Supabase correctly refuses with 42501 permission denied.

In plain terms: your security rules are working, but your app is knocking on the door without showing its ID.

How to confirm this is your problem

Before changing anything, keep the exact error text. Then check, in order:

Is RLS enabled on the failing table? In Supabase, open the table and look at its policies. If RLS is on and there is no policy that matches your query, every read or write fails.
Is the request authenticated on the server? Add a log on the server route that runs the query and print whether it has a user. If it prints null or anonymous, that is the cause.
Do your environment variables point at the same Supabase project that failed? A deploy pointed at the wrong project, or missing SUPABASE_URL and the anon key, produces the same symptom.
Do your auth redirect URLs include the live domain? In Supabase Auth settings, the site URL and redirect allow-list must include your production domain, not just localhost.

The fix

The real fix is to make the request carry the user's identity, so auth.uid() is populated when RLS checks it. In a Next.js and Supabase app that usually means:

Use a request-scoped server client that reads the auth cookie, instead of a plain anonymous client, on any server route or action that touches a protected table.
Refresh the session in middleware so the cookie stays valid across navigation and after a hard refresh on the production domain.
Confirm the RLS policy matches your real access pattern. If users should see their own rows, the policy compares auth.uid() to the row's user column. Do not "fix" this by turning RLS off.
Add the production domain to Supabase Auth redirect URLs, then retest the full path: log in, load the page, and hard refresh, all on the live URL.

Then rerun the exact user action that failed and confirm it works against the same Supabase project and domain that broke.

A word of caution

The tempting shortcut is to disable RLS or to use the service role key in the browser so the error disappears. Please do not. Disabling RLS makes every row in that table readable and writable by anyone on the internet, and putting the service role key in client code hands a stranger full control of your database. The error is annoying, but it is protecting you.

If you are stuck, or you are not the technical one

If you are non-technical and this already reads like another language, that is normal. This is exactly the kind of thing an AI builder cannot finish for you, because it lives in the boundary between auth, the database, and the deploy.

We run a service for this called Vibe-Code Rescue. You paste the error and get a free, plain-language diagnosis of what is wrong and what it takes to fix. If you want it fixed, it is a flat rate, you pay only after the fix is verified working, and you keep clean code you own. No subscription, no retainer.

Free diagnosis here: https://rescue.ticassociation.com

A TIC Association creation.