Business Continuity

What this covers

This describes our approach to keeping the service available and recovering it if something goes wrong. It is not a service level agreement and creates no contractual commitment, our Terms of Use govern that.

If you need a contractual availability commitment, talk to us rather than reading one into this page.

How the service is built

Magemcy runs on managed cloud infrastructure rather than servers we operate ourselves, which removes whole categories of failure, and means our resilience is bounded by our providers’.

• Application: hosted on Vercel and served from a global edge network. There is no single machine to lose, and deployments are atomic with immediate rollback.
• Database and files: Google Cloud Firestore and Cloud Storage, which replicate synchronously across multiple zones within a region. Losing a data centre does not lose data.
• Authentication: Google Firebase Authentication, operated by Google.
• Payments: Stripe. If Stripe is unavailable, existing subscriptions are unaffected; only new checkouts fail.
• Email: Resend, behind our own queue, see below.

Backups and recovery

Firestore replicates data across zones automatically and continuously, so ordinary hardware failure is invisible.

Replication is not a backup, and the two solve different problems: replication survives hardware loss, backups survive mistakes and malicious deletion. Firestore point-in-time recovery and scheduled exports address the second, and are configured at the project level.

Being straight with you: the exact backup schedule and point-in-time recovery window in force are deployment configuration rather than product behaviour. If your assessment depends on the specific numbers, ask us and we will confirm what is actually enabled rather than publishing a figure we would then have to keep true.

Separately, your own data is exportable from within the product at any time, which is the fastest recovery path that does not depend on us at all.

Recovery objectives

• Zonal failure: no recovery action, no data loss. Handled by the platform.
• Application or deployment failure: rollback to the previous release, typically within minutes.
• Accidental or malicious data loss: restore from point-in-time recovery. The window depends on the configuration above.
• Provider-wide outage: outside our control. We depend on Google Cloud, Vercel and Stripe, and we do not run a hot standby on a second provider. We would rather say so than imply a resilience we have not built.

When something fails

Not every failure is total, and the product is built to degrade rather than stop:

• Email delivery is queued before it is sent. A message is recorded first, then delivered, then retried with backoff if the provider is down. An invitation or approval request is not lost because a provider had a bad ten minutes.
• AI features fail closed and independently. If Google’s Gemini API is unavailable, requests fall back to OpenAI automatically; if both are unavailable, evaluation and the assistants stop while tenders, orders and invoices carry on. There is also a switch to turn the assistants off deliberately.
• Payments failing affects new checkouts only. Existing access is unaffected.
• Deadlines: bid closing is enforced by a scheduled server-side job, not by a browser being open, so a tender still closes on time if nobody is watching.

How we communicate during an incident

For anything affecting availability or data, we will tell affected customers by email, with what we know, what we are doing, and what you should do. We would rather send an incomplete update early than a polished one late.

Where a security breach involves personal data, the notification obligations in our Privacy Notice and Data Processing Addendum apply, including notifying a supervisory authority within 72 hours where required.

We do not currently operate a public status page. If that matters for your assessment, tell us.

What you can do

• Export your data periodically, especially before a milestone that matters.
• Give more than one person owner or admin access, so a single unavailable person is not a single point of failure.
• Keep approver email addresses current, approval chains depend on them.
• For a tender with a hard external deadline, leave margin rather than relying on the final hour.

If we go away

The fair question nobody enjoys asking. Your data is exportable at any time in open formats, so it is not held hostage by our continued existence. In an orderly wind-down we would give notice and a window to export. That is a commitment about data portability, which we control; it is not a prediction about the business.

Questions: our security contact or the contact form.