Your account builds itself after you buy

Submitting the intake form after payment creates the account, its branding, its invoicing defaults, its web address and its owner login — as a sequence of reported steps, not a black box.

What it is

An automatic, step-by-step provisioner. It mints the account id and slug, creates the organization row on the purchased plan, seeds the messaging infrastructure bindings, writes company and branding details into invoicing settings, seeds the customer-portal trust content, registers the subdomain, creates or reuses the owner's login with a magic-link sign-in, and sends a welcome email. Each step's result is persisted so the operator sees exactly what succeeded.

Also called: account setup · onboarding a new builder · provisioning · day one setup

See it
Your account builds itself after you buy
Won
45%
Avg cycle
22d
Pipeline
$475k
JanSep
The provisioning step list in the platform console — org, settings, portal, subdomain, owner, email — each with a green tick, an amber 'skipped' or a red note. src/components/platform/SignupsManager.tsx over src/lib/orgProvisioning.ts. Sample data — no customer information appears here.
How it works
  1. 1Fires when the buyer submits the post-payment intake form; re-runnable from the platform console.
  2. 2The slug is derived from the company name, checked against reserved labels and existing accounts, and suffixed if taken.
  3. 3The account row is created on the plan matching the purchased package, with the seat limit that plan carries.
  4. 4The signup is linked to the new account id immediately, not at the end.
  5. 5Company, legal name, tax ids, logo, brand colour, address, phone, email, website and invoicing defaults are written in one upsert.
  6. 6The subdomain is registered with the hosting provider so it gets a certificate.
  7. 7The owner login is created or reused, stamped admin/approved, and a magic-link sign-in token is issued.
  8. 8Step results are written back, and the signup only flips to 'provisioned' when every critical step succeeded.
Why we built it

The header describes it as 'AUTOMATIC + RETRYABLE' and spells out the failure it is designed around: the immediate account link exists because 'if a later step crashes or the serverless runtime kills the run, the next retry finds org_id and repairs in place instead of minting a duplicate org.' The step that most obviously reflects a real decision is the CRM one, dated Keith 08-17: 'New builders run on in-house comms; [the legacy CRM] is legacy for the accounts that already live there and a MIGRATION for a builder who arrives on it — never a silent sub-account we spin up.' It is recorded as skipped, honestly, rather than as success. And the portal seed carries a pointed omission: no phone number, because 'the funnel's phone comes from invoice_settings.company_phone and nowhere else… Seeding one here is how a stale number outlived its correction.'

The problem
  • Manual account setup is slow, inconsistent and easy to half-finish.
  • A crashed setup run used to create a duplicate account on retry.
  • A partly-successful setup that reports 'done' hides the steps that failed.
Sound familiar?
What you get
Your account arrives with your branding, invoicing defaults and web address already in place.
Every setup step is visible with its own result, so nothing is silently missing.
A failed step can be retried without creating a duplicate account.
What's inside

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 →