How we protect your data.
Card numbers never touch our systems, everything travels encrypted, and every staff account sees only what that job needs. The details are below, along with how to tell us if you find a problem.
- Cards stay with Stripe
- No card number reaches our servers.
- Encrypted in transit
- HTTPS only, TLS 1.2 or newer.
- Encrypted at rest
- AES-256 at our hosting and database providers.
- Access by role
- Each staff role sees only the screens its job needs.
Card payments
- Online, card details go into Stripe's payment form. It loads from Stripe inside our page, and the card number goes from the browser straight to Stripe.
- In the shop, cards are tapped, inserted or swiped on Stripe Terminal readers, which send the card to Stripe directly.
- We keep only what Stripe sends back: the card brand, the last four digits and Stripe's reference for the payment. That is enough for receipts and refunds, and cannot be used to charge a card.
- Stripe is certified PCI DSS Level 1, the highest level for payment processors.
Encryption
- In transit. Every page and every API call is HTTPS only. TLS 1.0 and 1.1 are refused, plain HTTP is redirected to HTTPS, and browsers are told to always use HTTPS (HSTS). Our servers reach the database, payment, email and AI providers over encrypted connections too.
- At rest. App data is stored with Netlify, which encrypts data at rest with AES-256 or stronger. Our Postgres database runs on Neon, which encrypts customer data at rest with AES-256 and accepts only encrypted connections.
- Passwords are never stored. We keep a scrypt hash with a unique salt for each account.
- Staff PINs are sealed with a keyed hash (HMAC-SHA256), so the PIN list cannot be read back, not even by us.
Who can see what
- Every staff member has a role: owner, manager, front desk or barber. Each role sees only the screens its job needs, and managers can narrow or widen access per area. Team and Settings always need a manager.
- Front desk and barber PINs work only on registers a manager has approved.
- Repeated wrong PINs or passwords lock sign-in for a while.
- When a staff member is deactivated, their access ends on their next click.
- Known scrapers are blocked before they reach the app, and sign-in, chat and contact forms are rate limited.
Companies that process data for us
These companies run parts of the service for us. Each one gets only the data its job needs. How we use your information is in our privacy policy.
| Company | What they do for us | Data they handle |
|---|---|---|
| Netlify | Hosting, server functions and data storage | All app data: bookings, clients, sales, staff records |
| Neon | Postgres database | Marketing contact records: name, email, phone |
| Stripe | Card payments online and on the in-shop card readers, memberships | Card details (Stripe only), name, email, amounts |
| Resend | Email delivery: receipts, booking confirmations, reports | Email address and the message |
| Anthropic | AI features: website chat, message summaries, reading expense receipts | Only the text or image sent to that feature |
| VoIP.ms | Shop phone lines and text messages, where a shop uses them | Phone numbers, call and text records |
| Twilio | Text messages and click to call, where a shop uses them | Phone numbers, call and text records |
| Cloudflare | Firewall and attack protection in front of the website | Visitor IP address and request details |
| Sign in with Google, maps and website analytics | Sign-in identity, visitor analytics | |
| Meta | Ad measurement on ad landing pages, lead forms and social posting | Ad visitor events, lead form answers |
Report a security problem
Email [email protected]. Tell us what you found, the page or address involved, and the steps to see it. Screenshots help. We reply within 3 business days and keep you posted until it is fixed.
Rules for good-faith testing
- Use only accounts you own or have permission to use.
- Do not view, change or keep other people's data beyond the minimum needed to show the problem.
- Do not slow down or break the service: no load tests, no denial of service, no spam.
- Do not test in our shops, and do not trick our staff or clients by email, text or phone.
- Give us 90 days to fix it before you share it publicly.
If you follow these rules, we will treat your research as authorized, we will not take legal action against you over it, and we will credit you if you want. We do not run a paid bug bounty.
Machine-readable contact: /.well-known/security.txt
Audits
We are building toward a SOC 2 audit and do not have a report yet. Our hosting, database and payment providers are independently audited every year. For a security questionnaire or a vendor review, email [email protected].
Last updated .