# What an SBD build passes before go-live

> The standards, security checks, tests and handover documents an SBD build goes through before it reaches real users, and why each one of them exists.

- Author: Pranav Mahaveer, Founder, SBD
- Published: 2026-10-29
- Updated: 2026-10-29
- Canonical: https://smallbaydigital.com/blog/what-every-build-passes-before-go-live/
- Contact: hello@smallbaydigital.com

New builds start from the same engineering foundation: a set of standards, checklists, templates and a runnable starter that carries what fourteen builds taught us. Most of it exists because something went wrong once. This is what a build has to pass before it reaches real users, and why.

> **The short answer.** Before go-live, every build passes a security checklist (credentials rotated, no secrets in code or history, row level security tested live), automated checks and tests in CI, and a handover in which the client receives a runbook, a monitoring guide that says what is not monitored, a credentials list by name, a go-live record and an ordered list of open items. Accounts, code and data are in the client's name before we leave.

## Standards with a reason behind each one

Our standards fit on a page: ten principles, each tied to a defect we shipped and then fixed. A few of them:

- **One definition per concept.** If "active customer" means two things in two places, one of them will be wrong in a report.
- **Never claim more than happened.** Logs and messages say exactly what was done, because a job that ran may still have failed to do its work.
- **Bound everything.** Every loop, retry, page size, file size and model call has a limit, so a bad input cannot become a large bill or a stuck queue.
- **Fix the class, not the instance.** When a bug appears, we look for every place the same mistake could exist and add a check that stops it returning.

## Security before anything is public

The go-live security checklist is short, and every build has to pass it:

- **Credentials rotated** at go-live, so no key used during development reaches production.
- **No secrets in code or in history.** A scan runs over the full git history as well as the latest commit, because a key deleted last month is still in the repository.
- **The right key in the right place.** Server-only keys never appear in variables that reach the browser, and a guard fails the build if one does.
- **Row level security on every table that holds client data,** checked with a live test that tries to read another tenant's rows and must fail.
- **Webhooks authenticated** by signatures in headers, never by secrets in URLs.

## Tests that check the whole build

Builds on the foundation have continuous integration that type-checks, tests and builds on each change. On top of that, where the build calls for them:

- **Audit scripts** read the source and assert its shape: every protected route checks access, every outbound email goes through the one function that honours unsubscribes. These scripts are themselves tested by deliberately breaking the code and confirming they catch it.
- **Schema smoke tests** confirm the database matches what the code expects after every migration.
- **Agent evaluations** run on a schedule for anything that uses an AI model, against a fixed set of real cases, so a model or prompt change that lowers quality is caught before users notice.
- **Visual regression tests** catch screens that changed when they should not have.

## A handover the client can run without us

We treat handover as part of the build. The client receives:

- **A runbook,** which we call the 2am document: what to do when something stops, written for the person on call rather than the person who built it.
- **A monitoring guide,** including a list of what is not monitored, so nobody assumes an alert exists that does not.
- **Credentials by name,** listing every account and key the system uses and where it lives, without the values.
- **A go-live record** with what was verified and when.
- **Open items,** ordered by how much they would hurt after go-live, so the next decision is obvious.

Ownership moves before we leave: the repository and hosting are transferred, and the database, domain, DNS and email were in the client's name from the start. The client's own team should be able to run the system from the README.

## After go-live

Requests after launch are sorted into four kinds: a defect, where it does not do what was agreed; a refinement, a small change to something that works; an enhancement, a larger addition; and something new. Naming the kind up front keeps warranty, care plans and new work separate and fair. Care plans start at $50 a month.

Read more: [AI and your data](/trust/ai/), [Security and data](/trust/security/), and [Moving off Retool](/blog/moving-off-retool/).