Skip to main content

Production playbook

Use this checklist when an app moves from experiment to something people rely on every day. The building blocks are Snapshots and Deployments.

AppRole
DevelopmentThis is where you develop the app or any new changes, with fake data.
StagingThis is where you let the final users try structure changes, new pages, tasks; sample or anonymised data.
ProductionReal users and real data.

Change management​

For every non-trivial change:

  1. Implement and test on staging.
  2. Optionally snapshot staging when the version is “good”.
  3. On production, open Deployments → choose staging (live or snapshot) → pass compatibility → launch with a clear summary.
  4. Smoke-test production (login, one create, one update, one e-mail path if safe).
  5. If something is wrong, use the automatic pre-deploy snapshot of production as the recovery starting point (restore creates a new app — plan capacity).

Never “click around” structural renames only on production without a snapshot first.

Backup cadence​

WhenWhat
Before imports, redesigns, mass batch tasksManual snapshot (structure + data)
Before each production deploymentAutomatic target snapshot (by Deployments)
Periodic (e.g. weekly) on critical appsManual snapshot for disaster recovery drills

Structure-only snapshots are lighter when you only need the blueprint.

Safe schema changes with live data​

  • Prefer additive changes (new fields, new pages) over renames/deletes when users are online.
  • Migrate data with grids, batch tasks, or import — then remove obsolete fields.
  • Disable automatic fields during huge rewrites; recalculate after.
  • Changing Choice option labels can break filters and task conditions — update automations in the same release.
  • Test login rules after any change to user objects.

E-mail safety​

  • Restored / clone apps start with outgoing e-mail disabled — leave it that way on non-production copies.
  • Point staging templates at internal inboxes when you do enable mail for tests.

Go-live day short list​

  • Staging signed off
  • Deployment to production completed and reviewed in history
  • Custom domain / DNS verified (if applicable)
  • Monitoring: submit a real transaction end-to-end
  • Rollback owner identified

Partner and agency delivery​

Agencies and freelancers often build Bobuild apps for clients. These patterns keep ownership clear after handoff.

Delivery model​

PhaseWhereWho
BuildStaging app in the partner or client accountPartner collaborators
AcceptStaging with realistic sample dataClient operators
Go-liveProduction via deploymentPartner + client owner
RunProduction portalsClient operators; partner on retainer if agreed

Prefer building in the client’s Bobuild organisation when they will own billing and data long-term. If you build in your account, plan an export/handoff (snapshots + collaborator transfer) with Bobuild support if needed.

Multi-client hygiene​

  • One app (or staging+prod pair) per client — do not mix client data.
  • Clear naming: clientname-staging, clientname-prod.
  • Separate Operator accounts per client; never reuse passwords across projects.
  • Document which custom domains and mail senders belong to which client.

Branding handoff​

  • Logo, colours, footer via Customize
  • Language and timezone in Settings
  • Embed snippets for the client’s WordPress/marketing site (Embedding)
  • Leave a short “Brand notes” Rich Text page on a staff-only portal for the next designer

Handoff checklist​

  • Client user is a Builder collaborator (owner) and understands the risk of structural edits
  • Partner access reduced to what the retainer needs
  • Production deployment path demonstrated once
  • Snapshot labelled handoff taken
  • Outgoing e-mail and domain ownership confirmed under the client
  • Operators trained on the live portals
  • API tokens rotated if the partner created temporary ones
  • Written list of gated features (schedules, SPID, …) and who to contact at Bobuild