Building a Tax App with Lovable? 5 Security Checks First

A bookkeeper with nearly 25 years of experience built a tax-planning app with Lovable, an AI app builder, without writing code. Eight weeks in, SnapTax had 19 signups and 3 paying users, for $50 in monthly recurring revenue (self-reported).

That's a real start in a hard category. It's also a category where the data is as sensitive as it gets: income, expenses, bank statements and receipts.

So this post uses SnapTax as an example of the app type. Nothing here says SnapTax has any of these problems. I haven't tested it and won't. The checks below are the ones I'd run on any finance app built with an AI builder.

The one point: in a tax app, the database rules are the product's real security, so check them before launch.

Building an app like SnapTax?

Crystal Harrison owns a bookkeeping firm in Austin. In her Show IH post, she explains the gap she saw. Freelancers owe self-employment tax and quarterly payments, and many don't realize it until it's late.

Her fastest-converting users were people with a regular job plus 1099 side income. Many assumed their employer's tax withholding covered everything.

Today the pricing page shows four plans:

• Free: quarterly estimates and IRS deadline reminders
• Starter, $4.99/month: monthly income and expense tracking, TurboTax export
• Builder, $19.99/month: bank statement uploads (CSV, PDF, OFX), AI expense sorting, receipt scanning, mileage
• Optimizer, $39.99/month (beta): deductions, retirement and capital gains tracking

Paid plans come with a 30-day trial. The homepage also mentions an MCP connector so users can ask AI assistants like Claude about their own tax data.

Look at that feature list as a builder. It means financial records, uploaded documents, AI processing and an outside AI connection. Each one is a place where AI-built apps commonly slip.

5 holes this type of app often ships with

Lovable apps usually store data in Supabase, a hosted Postgres database. These are the common gaps for that setup:

1. Tables without Row Level Security (RLS). RLS is the set of database rules that decides who can read each row. Without it, anyone holding your public API key can read every user's income.
2. Public storage buckets. Receipts and bank statements end up in file storage. If the bucket is public, anyone who guesses a file path can open it.
3. Trusting a user ID sent from the browser. A backend function that reads user_id from the request can be pointed at someone else's records. This is called IDOR (insecure direct object reference).
4. Secret keys in frontend code. Supabase's service role key skips every RLS rule. It must never reach the browser.
5. AI features with too much reach. Uploaded statements can contain text that tricks an AI model. An AI connector should only see the signed-in user's data.

Why does this happen with AI builders? The builder's job is to make the screens work. When you log in and see your own data, the app looks finished. But the screen isn't the security boundary. The database is. Unless you ask for access rules, or check them yourself, a working app can still be an open one.

Before and after: locking down income data

The most common version of hole #1 looks like this.

BEFORE: the table exists, but RLS was never turned on.

create table income_entries (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users,
  amount numeric not null,
  source text
);
-- RLS is off: the public anon key can read every row

AFTER: RLS on, plus a policy that limits each user to their own rows.

alter table income_entries enable row level security;

create policy "Users manage own income"
on income_entries for all
to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

The using part controls which rows a user can read or change. The with check part stops them from writing rows that belong to someone else.

The curl test

Run this against your own project only. It asks for the table while logged out, using only the public anon key:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/income_entries?select=*" \
  -H "apikey: YOUR_ANON_KEY"

• Before the fix: you get back every row, from every user.
• After the fix: you get back [], an empty list.

If you see rows come back in your own project, don't panic. Turn on RLS, add the policy, and run the test again. Repeat it for every table that holds money, documents or personal details. For storage, open a file's public URL in a private browser window. A private bucket should refuse it.

If you vibe-code this

Your pre-launch checklist for a tax or finance app:

• RLS on for every table, with an owner-only policy. See Supabase RLS for vibe coders.
• Receipts and statements in private buckets with owner-only access. See Supabase storage bucket security.
• Backend functions take the user from the session, never from the request body. See IDOR in API routes.
• Service role key only on the server. See environment variables security.
• AI and MCP features scoped to the signed-in user and treating document text as untrusted. See MCP security tools and prompt injection.

Building a finance app with Lovable and want someone to check it before real users arrive? Email [email protected] for a security audit.

Key takeaway

Domain experts can now ship real tax tools with AI builders, and SnapTax shows people will pay. In this category, run the RLS and storage checks above before you invite users. Trust is the product.

More case studies: Vibe-coded apps making money · Security guide: Vibe coding security

Sources

• https://www.indiehackers.com/post/show-ih-50-mrr-19-signups-8-weeks-in-i-built-a-tax-planning-tool-4-freelancers-after-years-in-bookkeeping-finally-had-ai-tools-for-it-0961615bb9 (Crystal Harrison, May 8, 2026)
• https://snaptaxapp.com/ (checked Sept 28, 2026)
• https://snaptaxapp.com/pricing (checked Sept 28, 2026)