Vibecode Rescue: paylog.space

paylog.space is a subscription tracker. You tell it what you're paying for every month, it shows you the total and reminds you before things renew. It's a Vite + React single-page app on Vercel, with Supabase handling auth, and it wants your billing dates and subscription costs — optionally your payment method.

I scored it 29 out of 100. That's Broken, the bottom band.

Everything below was observed on 2026-08-04, against a snapshot of the page, the shipped bundle, response headers, DNS and the legal pages taken at the time of the run.

What it gets right

• Secrets hygiene is correct. I scanned the 1.89 MB bundle for nine classes of credential — Stripe secret and test keys, OpenAI-style keys, Resend, AWS access keys, GitHub tokens, Supabase service_role, bare JWTs, private keys. Zero hits on all nine. Confirmed.
• It uses the current Supabase publishable key format (sb_publishable_…) rather than the legacy anon JWT. That's present-day best practice and more than a lot of hand-built apps manage.
• HSTS is on, max-age=63072000. Two years, which is a deliberate value rather than a default.
• robots.txt is well-formed and explicitly allows Googlebot, Bingbot, Twitterbot and facebookexternalhit.
• The privacy policy's retention section is specific: 30-day deletion, 90-day backup purge, seven-year transaction records. Specificity like that is rare, and whoever generated it asked for the right thing.
• The hero headline states the job in plain words — "Track Your Recurring Payments. Stop Wasting Money."

So at least some of the fundamentals were done correctly. And it makes the product look a little further along than it is (spoiler: it's not).

You cannot get data into it

A1 Time-to-Value: 0 out of 15. Confirmed.

There's no ingestion path. Every route by which data could arrive is absent: bank connection, email receipt scan, CSV import, browser extension, integrations. The bundle contains no /import, /integrations or /connect route either. The only way a subscription enters this product is a person typing it in.

And it's sold as a feature:

"Manual tracking that works" — "Log your subscriptions once, and we'll handle the rest."

"Add subscriptions in seconds" — "Just enter the name, cost, and renewal date."

The product promises to tell you what you're paying for. To use it, you have to already know what you're paying for, and type it in. It requires as input the exact thing it sells as output.

The person who needs this product is the person who doesn't know where their money is going. That person cannot complete onboarding. The person who can complete onboarding didn't need the product.

This truly makes Paylog no better than a spreadsheet. It is a spreadsheet, with a prettier UI and a reminder email; plus a subscription fee.

There is no backend

You can't create an account at all.

Google sign-up redirects to trjarertpflvnsrgjxvq.supabase.co/auth/v1/authorize and dies on ERR_NAME_NOT_RESOLVED. Verified independently, and again today:

$ dig +short trjarertpflvnsrgjxvq.supabase.co A
                              # (empty — no records)

$ curl -m 15 -o /dev/null -w '%{http_code}\n' \
    https://trjarertpflvnsrgjxvq.supabase.co/auth/v1/health
000                           # unreachable

# control — a different product's Supabase project, same check:
# 172.64.149.246, HTTP 401. Alive.

The Supabase project the shipped bundle points at no longer exists. Free-tier projects pause on inactivity and stop resolving. Nothing behind the landing page functions. Confirmed.

Against that: one Wayback capture, 2026-05-11, and a meta description reading Join 10,000+ users. This is a cardinal sin of product launch, don't lie. The claim is unverifiable, but I'm pretty confident it was never true. The product was built, launched, and abandoned inside about three months.

Nobody can contact them

The privacy policy routes rights requests to four addresses. None of them work, and most of them aren't even on this product's domain.

support@paylog.app     ×3   ← paylog.app, not paylog.space
privacy@paylog.app     ×3   ← GDPR + CCPA requests
dpo@paylog.app         ×1   ← named Data Protection Officer
support@paylog.space   ×2   ← correct domain, but:

$ dig +short paylog.space MX      # (empty) — bounces
$ dig +short paylog.space TXT | grep spf   # (empty) — spoofable
$ dig +short _dmarc.paylog.space TXT       # (empty)

$ dig +short paylog.app MX
10 mx00.ionos.com.
10 mx01.ionos.com.

paylog.space has no MX at all, so its own footer address bounces. paylog.app is a live domain on IONOS infrastructure with working mail, unrelated to this product's Vercel stack. Confirmed that it resolves to third-party infrastructure; inferred that it isn't theirs.

Which means the addresses printed most prominently — the ones for data deletion, GDPR requests, CCPA requests, and reporting a child's data — deliver to somebody else's mailbox. Under GDPR Article 12 a controller has to help data subjects exercise their rights. A rights-request address that reaches a stranger isn't a broken link; it's a data-protection incident of its own.

No SPF and no DMARC on either domain, so anyone can send mail as @paylog.space and it will pass.

The product is inconsistent and unverified

Reviewing the site artifacts, I found multiple inconsistencies. None of this was verified before someone pressed deploy. They cost nothing to verify, which is why this is the fastest read on how something was built.

The product is advertised under a different product's name. Fourth feature card, verbatim:

"Just enter the name, cost, and renewal date. PayPing takes care of tracking and reminding you."

The demo dashboard contradicts itself on one screen. Header says 5 active · $66.96/mo and renders five rows; the summary card below says Active Subs: 12. It also reports Saved This Month $24.00, a number the product has no mechanism to compute — it can't observe cancellations nobody told it about. The mock billing dates are hardcoded to February and March 2026.

A template placeholder shipped to production. In the International Data Transfers section:

"Paylog is based in [Your Country/Region]."

That string is in the bundle, in the privacy policy's own JSX. Users can't consent to a transfer to a jurisdiction the policy never names, and it's proof the policy was generated and never read by anyone.

Ten legal routes are the same 404 component. /privacy-policy, /datenschutz, /agb, /impressum, /refund-policy, /security and four others all render an identical 14,721-character response — the SPA's not-found view, not ten legal documents.

The social card is a 32-pixel favicon at a relative path.

<meta property="og:image" content="/favicon-32x32.png?v=5" />
<meta name="twitter:image" content="/favicon-32x32.png?v=5" />
<meta name="twitter:card" content="summary_large_image" />

summary_large_image expects 1200×630 and is handed a 32×32 icon, at a relative URL, which most scrapers reject outright. Every share this product has ever received rendered blank.

Data export is gated behind the Pro tier. GDPR Article 20 portability can't be conditioned on payment. That's a violation, not a pricing decision.

Two claims I can't verify and won't assert. The policy names a Data Protection Officer and claims "regular security audits and updates." Both are unverifiable from outside. I'm not calling them false — but a product at this stage with no working inbox is an unusual place to find a DPO, and specific security representations create liability when they aren't true.

The rest of the numbers

Lighthouse 12.8.2, mobile:

performance      54        LCP           6173 ms
accessibility    85        page weight    637 KB
best practices  100        requests        13
SEO             100        3rd-party        2

Desktop performance is 87. The 33-point gap is the whole story — this was built and checked on a laptop.

At 375 px the header renders and the body is blank. A phone visitor looks at an empty page for about six seconds. That's consistent with the 6.17-second LCP and a single 1,894,510-byte JavaScript bundle with no code splitting at the entry point.

The served HTML is 1,949 bytes: <head>, then <body><div id="root"></div></body>. There is nothing for Google to index and nothing for an assistant to cite. No sitemap, no canonical, no structured data, and /privacy and /terms exist only as client-side routes, invisible to crawlers.

Response headers: HSTS is present. CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are all absent.

A request for a path that doesn't exist returns HTTP 200 with the SPA shell — a soft 404. Search engines index those as duplicates and users get no error at all.

One thing I cannot determine: whether Row Level Security is enabled on the tables holding users' financial records. The client talks to Supabase directly with a publishable key, and checking would require probing, which is out of bounds. Unknown, scored at half weight. Nobody outside this company can verify that one user can't read another's financial records — not a prospective customer, not a security reviewer, not an acquirer. That unverifiability is itself the finding.

The score

Where the points went: A1 has no ingestion path and registration is impossible. A2 is financial data behind no working contact and a live template placeholder. A3 is the wrong product name in the feature copy and a demo dashboard that disagrees with itself. A5 is a 1.9 KB shell with a favicon for a social card. On the engineering side B1 is a clean bundle with the security headers missing, B5 is a soft-404 with no error tracking shipped, and B6 is a 6.17-second LCP that renders blank on a phone.

Part B outscores Part A by more than four to one. The engineering is the healthiest thing here.

A Broken time-to-value also caps the total at 59 under the published rules; the cap doesn't bite here, since it scored 29 on its own, but it fires.

What I'd fix first

1. Find a better domain name. .space is a TLD for hobbyists and personal sites, not a fintech product.
2. Point every contact address at a domain you control, and add MX to paylog.space. Until that's done there's no support channel and users' rights requests are landing in a stranger's inbox. An hour of work.
3. Fill in [Your Country/Region], drop the DPO claim, drop "regular security audits," and ungate data export. Four edits. Removes the false claims and the Article 20 violation.
4. Confirm RLS is on for every table. If it isn't, nothing else on this list matters.
5. Ship a real 1200×630 social card at an absolute URL.
6. Find and remove "PayPing." Then read the whole page out loud, once.\
7. Disable subscription billing until the product is usable. Until there's a way to get data in, nobody can use it, and nobody should be charged for it.

After that comes the actual work: build an ingestion path. Receipt parsing, a CSV import, a bank connection, anything that isn't a blank form. Until that exists the product can't be used by the person it's for.

Why I published this without telling them first

The rule is that findings go to the operator privately before they go out. I couldn't follow it here, so here's exactly what I tried.

support@paylog.space bounces — no MX. support@paylog.app, privacy@paylog.app and dpo@paylog.app are on a domain that resolves to IONOS infrastructure that doesn't appear to belong to this product, so mailing them would send a stranger a security writeup about somebody else's app. There's no security.txt. The one on-page contact link points at href="#". No legal entity is named anywhere — © 2026 Paylog. All rights reserved. isn't an entity. The site has one archive capture and nothing resembling a changelog or a status page.

There are also no users to protect. Registration is impossible because the backend no longer resolves, so nobody currently has data inside this product to be endangered by publishing.

I made a judgement call. If I'm wrong and someone owns this, the contact route runs the other way: my address works, and I'll publish a correction or take the piece down.

None of the findings above are exploitable as written. There's no unfixed vulnerability here, because there's no running backend to have one.

Disclosure

These audits are free and public. I also sell fixing this class of problem — it's Track 03 on my services page, and the package is called Vibecode Rescue, same as this series.

One dimension here scored Unknown, and code access would resolve it: whether row-level policies are enforced on the tables holding financial data. That's the first thing a paid Code Health Check looks at, and it's the question nobody outside the company can answer.

Next up I'd rather look at something still alive and still trying. An abandoned app is the easy version — nothing here can be walked back, and nobody's livelihood depends on the score. If you've built something and want it looked at properly, my inbox works.