Retry setup without breaking anything

Every setup step can be re-run safely: it fills gaps, never clobbers what an operator or the builder has since changed.

What it is

Repair mode. On a re-run the provisioner reuses the existing account, re-upserts settings, skips work already done, and only patches fields that are still empty. One-shot side effects — the welcome email in particular — are recorded so they never fire twice.

Also called: retry provisioning · repair account setup · re-run onboarding

See it
Retry setup without breaking anything
Day rate
$400
Days figured
7
Crew size
4
Fuel & equipment
$300
Finished 2 days early — $1,800 back to the crew
The same step list after a retry, with previously-successful steps showing 'already done' notes rather than re-running. src/lib/orgProvisioning.ts. Sample data — no customer information appears here.
How it works
  1. 1The existing account is found via the signup's linked account id; a pointer to a deleted account resets to a fresh provision.
  2. 2Plan is upgraded only off 'trial', so a later operator plan change wins.
  3. 3Third-party credentials are backfilled only when missing, because the builder may have rotated them in settings.
  4. 4An existing external sub-account is detected and the step reports it rather than creating a second one.
  5. 5Subdomain registration is idempotent: already-attached is treated as the desired state.
  6. 6The welcome email checks the previous run's step results and skips if it already sent.
Why we built it

The rule is stated as a heading in the code: 'Repair mode: FILL GAPS ONLY — never clobber what an operator or the tenant changed since the first run.' The welcome-email guard is called out separately — 'One-shot: a re-run never re-spams the owner once a send succeeded' — because the obvious retry design is the one that emails a new customer four times. The single step whose failure is treated as dangerous is the account link, flagged in its own note: 'a failed link is the one thing that CAN cause duplicates, so surface it in steps.'

The problem
  • A retried setup could overwrite settings the customer had already changed.
  • Retries could send duplicate welcome emails to a brand-new customer.
  • A crashed run could produce two accounts for one purchase.
Sound familiar?
What you get
An operator can safely hit retry as many times as needed.
Customer-visible side effects fire exactly once.
Later manual changes survive a repair run.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →