Business Continuity Plan
This document addresses how the business — not just the software — keeps functioning through major failures: a critical vendor outage, a serious security incident, or loss of a key operational dependency. It complements the Disaster Recovery / Backup doc, which focuses on the technical data-recovery mechanics.
1. Critical External Dependencies
Yareta’s ability to operate depends on several third parties it does not control. Losing any of these degrades a specific, identifiable slice of the product rather than the whole platform (with one exception, noted below):
| Dependency | What breaks without it | Single point of failure? |
|---|---|---|
| Cloudflare (Pages, Workers, D1, KV, R2) | Everything — this is the one true single point of failure in the current architecture | Yes — no multi-cloud failover exists (see ADR-001) |
| Stripe | New subscriptions, top-ups, and plan changes; existing access continues for already-provisioned orgs | Partial — billing-affecting only |
| LLM providers (OpenAI, Anthropic, Google, Groq) | AI-generated report sections, DNA scoring, Traffic Light — but not psychometric scoring (that’s a local statistical model, not an LLM call) or existing data | Partial, and mitigated by having four providers, though automatic failover between them is not fully wired (see ADR-004) |
| Qdrant (if externally hosted) | Semantic search / RAG / chat widget — falls back to Cloudflare Vectorize automatically | No — has a built-in fallback |
| AWS SES | Transactional email (OTP sign-in codes, notifications) — this would block new sign-ins for anyone not already holding a session | Yes, for the OTP sign-in path specifically |
| CRM/integration partners (Airtable, HubSpot, Attio, Typeform, Fireflies, Recall.ai, DocuSign, Slack, Zapier) | That specific data-sync channel only | No — each is independent |
2. Continuity by Failure Type
Cloudflare platform outage (SEV-1)
Given the single-cloud architecture, there is currently no documented failover — this is an accepted architectural risk, not an oversight (see ADR-001). Continuity planning here is about communication and manual workaround, not infrastructure failover: know how to reach Cloudflare support, monitor Cloudflare’s status page, and have a plan for communicating an extended outage to customers (see the gap noted in the Incident Response Guide). If this risk becomes unacceptable as the business scales, it needs a deliberate architecture review, not an incremental fix.
LLM provider outage
Because per-service provider/model is admin-configurable without a deploy (Admin → LLM Services), the practical continuity plan today is manual failover: an admin repoints affected services to a healthy provider. This works because four providers are already integrated — the gap is that it’s not automatic. Document (or better, script) the specific admin steps to repoint a service, so this doesn’t require reading source code during an actual outage.
Stripe outage
New signups/upgrades/top-ups pause, but existing paying customers keep their access (access is gated by the organizationSubscriptions/organizationCredits state already stored locally, not a live Stripe check on every request). This is a reasonable existing continuity property — worth confirming it holds by design rather than by accident, and documenting it as intentional.
Loss of key personnel / institutional knowledge
Several subsystems in this platform carry meaningful undocumented tribal knowledge — the prompt library’s code/DB sync process, the billing/credit reconciliation logic, the migration-numbering-collision history, and the Lovable/chat-sparkle-vision integration contract chief among them. This documentation set is itself a continuity measure against that risk; keeping it current (see the Maintenance Guide §9) is part of business continuity, not just developer convenience.
Data-integrity incident (bad migration, bad bulk operation, security breach)
See the Disaster Recovery doc for the technical recovery mechanics (D1 time-travel, export-based restore). From a business-continuity angle: because backups are currently manual/unscheduled (a documented gap), the business’s actual data-loss exposure window is wider than it should be until that’s automated. This is the single highest-leverage business-continuity gap to close in the current state of the platform.
3. Communication Plan (Gap)
No customer-facing status page or incident-communication tooling was found in the codebase or docs/. For a B2B platform handling investor due-diligence data, having a plan to notify affected organizations promptly during a significant outage or incident is both an operational and a trust/reputational concern. Recommend establishing, at minimum: a status page (even a simple one), a template for customer incident communications, and a defined internal owner for triggering that communication during a SEV-1/SEV-2 incident (see the Incident Response Guide).
4. Recommendations Summary
In priority order, the actions that most improve business continuity from the current state:
- Automate D1 backups on a schedule (currently manual — see Maintenance Guide §7) and test a restore at least once, so the recovery process is proven before it’s needed under pressure.
- Document and rehearse manual LLM-provider failover — the mechanism exists (admin UI), but the runbook for using it under pressure doesn’t yet.
- Establish a customer communication plan for significant incidents.
- Set explicit RTO/RPO targets (see the Disaster Recovery doc) so continuity planning has a concrete target to plan against rather than an implicit “as fast as possible.”
- Keep this documentation set current as the single largest mitigant against institutional-knowledge loss identified in this audit.
Related documents: Disaster Recovery / Backup · Incident Response Guide · System Architecture