Vibecode Rescue: canyoupaythat.com

Can You Pay That sends automated payment reminders for freelancers and agencies. You store a client, upload an invoice, pick a reminder schedule, and the product chases the money so you don't have to. Plans run $0, $12 and $29 a month, and a genuinely useful set of calculators and an invoice generator work with no account at all.

It scored 58.5 out of 100. At Risk.

Observed on 2026-08-05 against a snapshot of the page, the shipped bundle, response headers, DNS and every legal route I could think to try. Signup was not completed; A1 is scored on what a prospective user meets before the password field.

The engineering here is the best in this batch. That's what makes the rest of it worth writing down.

There is no privacy policy, and there are no terms

Not misplaced. Not on another domain. Not behind a login. Absent.

$ for p in privacy privacy-policy terms terms-of-service terms-and-conditions; do
    curl -o /dev/null -sw "%{http_code}  /$p\n" https://canyoupaythat.com/$p
  done
404  /privacy
404  /privacy-policy
404  /terms
404  /terms-of-service
404  /terms-and-conditions

Then I searched the served HTML for any link that might lead somewhere I hadn't guessed — privacy, terms, legal, policy, in any href on the page. Nothing. The footer carries Product, Resources and Partners; the legal column that would normally sit beside them was never built.

Now hold that against what the product does. You give it your clients' names and email addresses. It stores them, generates a portal link for each one, and sends those people email on a schedule you configure. Your clients never visited this site. They never agreed to anything. They are going to receive mail from a system that documents its data handling nowhere. How long it keeps their address, how they get it removed, and who they tell if it leaks are three questions the site leaves unanswered.

That's the part people miss when they skip the legal pages as busywork. The user can accept an unstated bargain, because they at least chose to be here. The user's clients are in the database without ever having had the option.

The product is email, and the domain is spoofable

Three commands, and this is the finding I'd put in front of the operator first.

$ dig +short canyoupaythat.com MX
10 inbound-smtp.us-east-1.amazonaws.com.

$ dig +short canyoupaythat.com TXT | grep spf
                                    # nothing

$ dig +short _dmarc.canyoupaythat.com TXT
                                    # nothing

The MX record says mail comes in through Amazon SES, so the mailbox works and contact@canyoupaythat.com — published six times across the site — reaches someone. Good. But there is no SPF record and no DMARC record, which means anyone on the internet can send mail that claims to be from @canyoupaythat.com and receivers have been given no instruction to doubt it.

Every other product in this series gets dinged for mail posture as a hygiene item. Here it isn't hygiene. The entire value proposition is we send professional, polite email to your clients so you don't have to. The whole product is outbound mail about money owed, addressed to people who are already expecting payment requests from this domain. A forged reminder pointing at a different payment link is the most natural phishing setup I've seen in this batch, and the domain publishes no record that would help a receiver reject it.

The browser talks to the database directly

The bundle carries a Supabase project URL and its anon key:

https://wvkamvlouttuutmuhbpb.supabase.co
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

That is not a leak. The anon key is designed to be public — it ships in the page on purpose, and the thing standing between it and your data is row-level security on the tables it can reach. Whether those policies exist, are enabled, and cover every table is invisible from outside. So B2 is Unknown, which scores exactly half of eleven, and no amount of squinting at the bundle moves it.

I'd normally leave it there. I can't this time: the last audit in this series marked the same dimension Unknown on the same stack, a review under coordinated disclosure went and looked, and the answer was the bad one. The Unknown is not a formality.

What it gets right

This is a well-built product, and the list is long.

• Lighthouse desktop: performance 99, accessibility 94, best practices 96, SEO 100. Total page weight 0.3 MB, largest contentful paint 0.8 s, zero total blocking time. Nothing else in this batch is close.
• The free tools are actually free. An invoice generator, a late-fee calculator with jurisdiction-aware limits, a reminder-schedule builder and a reminder-email generator, all usable with no account and no card. Most products in this series make you sign up to see anything.
• A path that doesn't exist returns a real 404. Three other products in this batch return 200 and the app shell for every URL you can type.
• HSTS is set at two years, and a robots.txt and an 18.9 KB sitemap.xml are both served correctly.
• Pricing is complete and legible before signup, with the plan limits stated as numbers — 3 clients, 50 clients, unlimited — rather than adjectives.
• The FAQ answers the awkward questions, including "do you process payments?" and "will this spam my clients?".

Nine of the eleven dimensions are fine. Two aren't, and both live in Part A.

The rest of the engineering

Five of six security headers are missing — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — with HSTS the only one set.

No og:image is declared, so every share of every page falls back to whatever the platform invents. For a product whose growth motion is a free invoice generator that people pass around, that's a hole in the loop.

The homepage claims 4,500+ professionals getting paid faster. Nothing observable from outside supports or contradicts it, and it's the kind of number an acquirer or a security reviewer will ask to see the query behind.

The score

Part B is 26.5 of 45 — mid-table for this series, and the highest B6 I've scored. Part A is where the 58.5 comes from, and almost all of the damage is one dimension: Trust and Commercial Clarity, 3 of 16, for documents that don't exist.

What I'd fix first

1. Publish a privacy policy and terms. The reason isn't the regulator. You are the data processor for your customers' clients, and nothing currently published says what you do with those people's information. A weekend of work moves A2 further than anything else on this list.
2. Add SPF and DMARC. The product sends email for a living. Start at p=none if you must, then move to quarantine once the reports come back clean.
3. Confirm row-level security on every table the browser can reach, and say so publicly. It's the single cheapest thing that converts a permanent Unknown into a Confirmed.
4. Declare an og:image. The free tools are the growth engine; right now every share of them looks like nothing.
5. Add the five missing security headers. An afternoon at the CDN, and the engineering is already good enough that they'd be the last thing on the list.

Disclosure

Findings went to the operator before this published. These audits are free and public; the paid version is a Code Health Check, and the rescue work after it is Track 03 on my services page.

One dimension scored Unknown and code access resolves it: whether row policies are enforced on the tables the browser is already querying.