No More Winging It About the author →
Security

How we protect your data

You’re trusting us with the most detailed picture of your money most apps will ever see. Here’s the honest version of how that’s protected, where the realistic holes are, and what you can do to keep yourself safe.

We’re not a zero-knowledge product. The app’s job is to calculate things about your money — your net worth, your tax position, your pension projection — and that needs server-side access to your figures. The security model below is the one used by every credible finance SaaS: defence-in-depth, not magical encryption.

What protects your data today

  1. Row-Level Security in Postgres. Every table enforces a policy at the database level that scopes queries to the signed-in user’s ID. Even if a bug in our code tried to read someone else’s data via the public API, the database itself would reject the query.
  2. Service-role key never touches the browser. The privileged key that bypasses Row-Level Security only lives in our backend environment. Every server endpoint that uses it first validates your JWT and scopes the query to your user ID before doing anything.
  3. TLS in transit, AES-256 at rest. Standard cloud database posture — data is encrypted on disk by Supabase, and every connection between your browser, our API and the database uses TLS 1.3.
  4. Field-level encryption for the most sensitive items. Affiliate payout details (sort code, account number, PayPal email), Google Sheet IDs and a few other high-risk fields are additionally encrypted with AES-256-GCM before they hit the database. That means a database compromise alone doesn’t reveal them — an attacker would need a separately-held encryption key as well.
  5. No third-party data sharing. Your numbers aren’t sent to analytics SDKs, advertising networks, chat-with-your-data LLM providers that persist context, or any other downstream system. The two external services we use are Stripe (for billing — never sees your financial data) and Anthropic Claude (for AI features — calls are stateless and not retained for training).
  6. Admin access is consent-gated and audited. An admin (currently just the founder) cannot read your financial profile, transactions or AI chat history without first requesting a one-hour grant that you have to approve from your account page. Every grant and every read under that grant is logged forever — you can see exactly when someone looked at your data and why.

Where the realistic risks actually are

The honest version: any system that lets a server do useful things with your data has a window where that data is accessible. Layered defences reduce the surface, they don’t eliminate it. The four real risks, ranked by likelihood:

RiskWhat would happenWhat we do about it
Your email account is compromised Attacker requests a magic link, signs into your No More Winging It account Enable two-factor authentication on your No More Winging It account (Account → Two-factor authentication). Magic-link sign-in alone is then no longer enough — a 6-digit code from your authenticator app is also required.
Our service-role key leaks (Vercel account breach, accidental logging, supply-chain attack) Attacker can read any row in the database for as long as the key is valid 2FA on Vercel + GitHub + Supabase, restricted account access, periodic key rotation, monitoring of unusual query patterns
Supabase admin login is compromised Same as above — full DB access through the dashboard 2FA enforced on the Supabase account
Code bug bypasses Row-Level Security Cross-user data exposure via a specific endpoint Parameterised queries everywhere, code review on every PR, and a planned annual independent penetration test once we have early traction

What you can do

The two single biggest improvements to your account security are both quick:

Why no SMS 2FA

We deliberately don’t offer SMS as a second factor. SIM-swap fraud — where an attacker convinces the carrier to port your number to a new SIM — is routine in the UK, and SMS codes are the first thing the attacker captures. Authenticator apps (and on iOS, your built-in Passwords app) tie the second factor to a device you control, which closes that hole. If we offered SMS as a fallback for “low-friction” users we’d be giving them weaker protection while letting them believe they were protected.

What we deliberately don’t do

What zero-knowledge would mean (and why we’re not)

Some products — password managers, encrypted notes apps like Standard Notes — encrypt everything client-side with a key derived from your password. The server only ever sees encrypted blobs. That model is excellent for opaque storage but breaks if the server needs to do anything with the data: calculate aggregates, run projections, surface intelligence, search. You can’t compute your net worth across all your accounts if the database can’t read the numbers in those accounts.

Because No More Winging It’s value is calculation — the daily intelligence feed, the AI chat that knows your figures, the 60% tax-trap analysis, the pension projection — we run a layered defence-in-depth model instead. The same model your bank’s online banking, every budgeting app on the market, and every accountancy SaaS use.

Reporting a security issue

If you find a vulnerability, please email nick@nomorewingingit.ai with the subject “Security report”. We acknowledge within 24 hours and aim to fix anything material within 7 days. We don’t yet run a paid bug bounty programme but we will credit researchers publicly with permission, and we take responsible disclosure seriously.

Roadmap

This page is plain-English supplement to our Privacy Policy and Terms. If anything here conflicts with those, those are the binding documents.

← Back to home · About · Privacy policy