As a solo developer building a production SaaS app, what is the minimum 'hit by a bus' documentation package that lets someone else keep the app running — not developing, just running — if you're unavailable for 30 days?

GPT-5.5

Answer: The minimum 'hit by a bus' package is a short, continuously updated operations runbook that explains how to access, monitor, restart, back up, restore, deploy, and pay for the production system for 30 days.

For a solo developer, the goal is not to transfer product knowledge or enable feature work; it is to prevent avoidable downtime, data loss, expired services, and locked accounts while you are unavailable. That means the documentation should be operational, not architectural in the abstract. The package should include: a one-page system overview showing the app, database, hosting provider, DNS, email provider, payment provider, object storage, queues, cron jobs, and third-party APIs; a list of critical accounts and where credentials are stored; emergency contact information; and clear instructions for the most likely incidents. The most important document is a runbook titled something like 'How to keep production alive for 30 days.' It should cover how to check whether the app is healthy, where logs and dashboards live, how to restart services, how to roll back or redeploy the last known good version, how to verify background jobs, how to inspect error alerts, and what not to touch. Commands should be copy-pasteable, with expected output and warnings for dangerous steps. Backups and recovery deserve their own section. The caretaker needs to know what is backed up, how often, where backups live, how to confirm that backups are running, and the exact restore procedure. Even if they never perform a restore, they must be able to detect that backups have stopped. For a production SaaS app, unverified backups are not a safety plan. Billing and account continuity are also part of runtime documentation. Include renewal dates, credit cards or billing owners, domain expiry, SSL certificate details if not fully managed, limits or quotas, and which provider emails indicate urgent action. A SaaS can go down because a card expired just as surely as because a server crashed. The package should also contain an incident checklist: first acknowledge the alert, check the status page or monitoring dashboard, identify whether the issue is app, database, hosting, DNS, email, payments, or third-party dependency, then follow the relevant runbook. Include escalation paths: who can help, what access they need, and what information to send them. Keep source-code documentation minimal unless it supports operations. A README that explains repository setup, environment variables, deployment commands, and how to rebuild the production artifact is useful; a deep design treatise is not required for a 30-day caretaker. The standard should be: could a competent engineer or trusted ops contractor keep the service stable without understanding every business rule? Finally, store the package somewhere accessible but secure, such as a shared password manager plus a private ops repository or secure document vault. Test it by having another person follow it once, or by doing a mock incident yourself using only the docs. If the runbook is not tested, it is more like a hope than a continuity plan.

Gemini 3.1 Pro

Answer: The minimum "hit by a bus" package consists of a secure master credentials vault, a high-level infrastructure map, a service restart/restore runbook, and basic customer communication guidelines.

When a solo developer is incapacitated, the immediate goal is life support, not development or feature onboarding. The person stepping in needs just enough context to keep the lights on and handle severe outages over a 30-day window. First and foremost is the 'Break-Glass' Vault. This should be a secure password manager (using an emergency access feature or a physically shared master password) containing credentials for the domain registrar, hosting providers, database, and payment gateways. Without access, no amount of documentation matters. Second is the Infrastructure Cheat Sheet. This doesn't need to be a complex system architecture diagram; it just needs to clearly state where the application lives (e.g., 'Frontend is on Vercel, Backend is on Render, Database is AWS RDS'). This tells the caretaker exactly which dashboards to check if the app goes offline. Third is the Emergency Runbook. This should contain exact, copy-pasteable commands or UI click-paths for the two most critical survival tasks: how to restart the core services when they crash, and how to restore the database from the last automated backup in case of data corruption. Finally, include a Billing and Communications checklist. Ensure the caretaker knows how to verify that the credit card on file won't expire or decline within the 30 days, and provide access to customer support channels with a pre-written 'status degradation' template to keep users informed if a prolonged outage occurs.

Grok 4.3

Answer: The minimum package consists of a single runbook PDF or markdown file covering server access credentials, environment variables list, deployment and restart commands, database backup locations, and monitoring dashboard URLs.

For operational continuity without development needs, the focus must remain strictly on runtime recovery rather than code or architecture details. A concise runbook that a non-technical person can follow in under an hour ensures the app stays online during the 30-day window. Including exact SSH keys or password-manager shares, a .env template, one-command deploy scripts, and links to uptime monitors covers the critical failure points without overwhelming the reader. Anything beyond these four sections introduces unnecessary maintenance overhead for the solo developer.

Claude Opus 4.7

Answer: The minimum 'hit by a bus' package is a single, version-controlled runbook repository containing five things: an access inventory, an architecture map, an operations playbook, an incident response guide, and a billing/legal contact sheet — enough for a competent stranger to keep the lights on, pay the bills, and handle customer-impacting incidents for 30 days without touching code.

For a 30-day 'keep it running' window, the goal is not knowledge transfer for development — it's operational continuity. That narrows the scope dramatically. Here's the concrete minimum I'd ship: 1. **Access Inventory (the most important document).** A printed-or-encrypted list of every account, where it lives, who owns the billing, and how to recover it: domain registrar, DNS, hosting (Vercel/Railway/AWS), database, email/SMTP, Stripe, error monitoring, status page, GitHub, and the password manager itself. Include the recovery process for the password manager — if your successor can't get in, nothing else matters. Pair this with a legal mechanism (a trusted emergency contact in 1Password/Bitwarden, or a sealed envelope with a lawyer/spouse). 2. **Architecture Map (one page).** A diagram or bullet list: 'Frontend is X hosted on Y, talks to API Z, which uses database W, with background jobs on V, and these third-party services: Stripe, SendGrid, etc.' Include the domain names, the regions, and what breaks if each piece goes down. No code-level detail — just the boxes and arrows. 3. **Operations Playbook.** The boring recurring stuff: how to deploy a hotfix if a contractor writes one, how to restart services, where logs live, how to read the monitoring dashboard, what the normal baseline looks like (so they can recognize abnormal), how backups work and how to verify the last one ran, and the cost dashboard so they notice a runaway bill. 4. **Incident Response Guide.** A flat list of the top 5–10 things that have actually broken or could plausibly break, each with symptoms and a fix or escalation path: 'Site down → check status of [host] → if host is fine, check [monitoring] → if database, run X.' Include a 'when in doubt, put up the maintenance page' instruction and the exact steps to do it. Also: how to respond to a security incident, a Stripe dispute, and a GDPR/data deletion request. 5. **Contacts & Legal.** Who to call: your accountant, lawyer, key customers (or top-revenue accounts), any contractors, and the support email auto-responder template explaining reduced service. Plus where the business entity documents, insurance, and customer contracts live. Two meta-points that matter more than the contents: - **It must be testable.** Once a year, hand the runbook to a technical friend and ask them to deploy a trivial change or simulate a recovery using only the doc. If they can't, the doc is fiction. - **It must be discoverable.** A perfect runbook nobody can find is worthless. The access mechanism (emergency contact in your password manager, instructions with your spouse/lawyer) is part of the deliverable, not separate from it. Notably absent from my minimum: code documentation, architectural decision records, feature roadmaps, and onboarding guides. Those are for the *next developer*, not the *bus successor*. Conflating the two is why most solo devs never finish their 'hit by a bus' doc — they aim too high and ship nothing.

Final Summary

The AI Roundtable unanimously rejected code documentation in favor of a strictly operational "keep-alive" manual. Claude Opus 4.7 and GPT-5.5 stressed that billing continuity and access recovery are as critical as server uptime, while Gemini 3.1 Pro and Grok 4.3 argued that a secure credentials vault and copy-pasteable restart commands are the only true non-negotiables for a 30-day window.

All 4 models agreed