Security at MakeInvo

1. Security overview

MakeInvo is built on established, security-audited infrastructure providers - Vercel for hosting and Supabase for our database and authentication - rather than custom, self-managed servers. We combine that with our own access controls and secure coding practices.

2. Encryption in transit

Every connection to makeinvo.com and the MakeInvo application is encrypted using HTTPS/TLS, so data travelling between your browser and our servers can't be read in transit.

3. Encryption at rest

Our database provider, Supabase (built on PostgreSQL), encrypts data at rest as part of its standard managed-infrastructure offering. We have not independently audited or certified this beyond relying on our provider's own security documentation, so we describe it here rather than claiming a specific certification we do not hold.

4. Authentication and account access

Account sign-in is handled by Supabase Auth. Your invoices, clients, and account data are only accessible after you authenticate - each request is checked against your account, so one user cannot see another user's data through the application.

5. Password handling

MakeInvo does not store your raw password. Password storage and verification are handled by our authentication provider using industry-standard hashing, not by MakeInvo's own application code.

6. Access controls

Application code enforces that every invoice, client, and account record is scoped to the signed-in user who owns it. A shared invoice link only exposes the single invoice it points to - never your client list, other invoices, or your dashboard.

7. Database and infrastructure security

We do not publish detailed internal infrastructure or architecture information, as doing so could create unnecessary risk. In general terms: our database and hosting are provided by established third-party infrastructure companies (see the Subprocessors page), and access to production systems is restricted.

8. Shared invoice link security

A shared invoice link uses a long, hard-to-guess identifier and is not indexed by search engines or listed anywhere publicly discoverable. Anyone who has the exact link can view that one invoice - do not share an invoice link anywhere it could be seen by someone other than the intended recipient.

9. Backups and recovery

Our database provider maintains its own backup and recovery processes as part of its managed hosting service. MakeInvo does not operate a separate, custom backup system of its own.

10. Monitoring and logging

Our hosting and database providers log standard request and error information as part of operating the service reliably and securely. We use this operationally; we do not currently run a dedicated third-party error-monitoring or security-information tool beyond our providers' built-in tooling.

11. Vulnerability management

We keep our application dependencies up to date and address security issues as they're identified, including issues reported through the responsible-disclosure process below.

12. Third-party service providers

MakeInvo relies on a small number of established providers (hosting, database/auth, and payments) rather than building everything in-house. See the full list on the Subprocessors page.

13. User security responsibilities

• Use a strong, unique password for your MakeInvo account
• Never share your password or reuse it across other sites
• Sign out of MakeInvo on shared or public devices
• Only share invoice links with their intended recipient
• Report anything that looks suspicious using the process below

14. Reporting a security issue

If you discover a security vulnerability, please report it to support@makeinvo.com with enough detail for us to reproduce and understand the issue.

15. Responsible disclosure

Please report issues privately and give us a reasonable opportunity to investigate and fix them before any public disclosure. When testing, only use your own MakeInvo account and test data - do not access, modify, or download another user's data, and do not run automated scans or load-testing against the production service without contacting us first. We do not currently commit to a specific response-time guarantee for security reports, but we treat them as a priority.