Skip to main content

Create your first app

Use this guide when your workspace is empty or when you want to add a new SaaS product to Switera. It follows the same path a Builder sees in the product: workspace dashboard, apps portfolio, app creation, organization setup, Auth, email, webhooks, API keys, and audit review.

Before you start​

You need:

  • access to a Switera Builder account
  • the product name users will recognize
  • a short app slug, usually lowercase with hyphens
  • a decision about whether the first customer account should be represented as an organization
  • access to the email, Auth provider, webhook receiver, and backend environments you plan to connect later

Step 1: Start from the workspace dashboard​

Open Dashboard after signing in. The dashboard tells you whether the workspace has apps, whether any apps need action, and which app should be opened first.

Switera workspace dashboard in light mode with sample app status
Use the dashboard for cross-app status. Open the full apps portfolio when you need to create or compare apps.

Select Create App if this is the first product in the workspace. Select Open apps portfolio if you want to review existing apps first.

Step 2: Review the apps portfolio​

The apps portfolio lists every app you can operate. Each app card shows the app name, slug, current state, organization count, user count, and recommended next action.

Switera apps portfolio with sample app readiness cards
If an app already exists, open it from the portfolio before creating a duplicate.

Create a new app when you are launching a separate SaaS product, separate customer-facing experience, or separate Auth and integration boundary.

Step 3: Create the app​

Select Create App, then fill the form.

Switera create app form with sample app name and slug
Use a product name your team recognizes. Use a slug that will still make sense in URLs and integration context later.
  1. Enter the app name.
  2. Enter or confirm the slug.
  3. Review the short explanation on the right side of the form.
  4. Select Create App.

The app is created immediately. You land in the app-level workspace, where Switera starts guiding you through the setup baseline.

Step 4: Read the app overview before changing settings​

The app overview is the operating home for one app. It explains whether the app is still in setup, what needs attention, and which action should happen next.

Switera app overview with setup state and next actions
Confirm the selected app name in the app switcher before editing organizations, services, keys, or audit settings.

Use the overview to answer:

  • does this app have a customer organization yet?
  • is Auth ready for end users?
  • are external notifications configured?
  • what recent activity happened?
  • what is the next setup action?

Step 5: Create the first organization​

Most B2B SaaS products need an organization before they can invite users. Open Organizations, then select Create Organization.

Switera create organization modal with sample organization name and slug
Create a test or pilot organization first if the app is not ready for real customer data.
  1. Enter the organization name.
  2. Confirm the slug.
  3. Select Create Organization.
  4. Open the organization and invite the first operating team when ready.

Do not invite real customers until Auth and email are reviewed.

Step 6: Configure the first sign-in method​

Open Services > Authentication, then open Sign-in Methods. Start with one primary method, then add advanced methods after the basic login path works.

Switera sign-in methods configuration in light mode
For a first setup, keep the sign-in surface small. Email and password or email sign-in is usually enough for a pilot.

Recommended first setup:

  1. Enable the sign-in method your first users will actually use.
  2. Keep email verification enabled for real users.
  3. Save the Auth settings.
  4. Test login with a test user before inviting customers.

Step 7: Prepare email​

Open Services > Email. Email must be ready before invitations, verification, recovery, and account notices can feel trustworthy to end users.

Switera email overview with setup guidance
Start with sender identity and invitation templates. Then review built-in account emails before launch.

At minimum, check:

  • sender name and sender address
  • reply-to behavior
  • invitation template
  • built-in verification and recovery emails
  • route test to a monitored mailbox

Step 8: Add webhooks only when a backend needs events​

Open Services > Webhooks if your backend, automation workflow, or support tooling needs to react to Switera events.

Switera webhooks overview with first endpoint guidance
A new app can launch without webhooks, but most production apps eventually connect a receiver for account, organization, and security events.

Keep the first endpoint narrow:

  1. Add one HTTPS receiver.
  2. Subscribe only to the event types your backend handles.
  3. Store the endpoint secret safely.
  4. Send a test event.
  5. Check delivery attempts before enabling broad event traffic.

Step 9: Copy API keys from a trusted machine​

Open Admin > API Keys when your backend needs to call Switera APIs.

Switera API keys page with masked key values
Use secret keys only from trusted backend services. Never put a secret key in frontend code.

Store secret keys in your backend secret storage. Keep test and live keys separate.

Step 10: Check audit logs​

Open Admin > Audit Logs after the first setup. Confirm that app creation, Auth changes, organization changes, key rotation, or service edits show up as expected.

Switera audit logs page with filters and export actions
Use audit logs to confirm who changed what, when it happened, and whether a setup mistake needs rollback.

Success state​

Your first app is ready for pilot use when:

  • the app exists and has a clear name
  • at least one organization exists if your product has customer accounts
  • Auth has one working sign-in method
  • email invitations or account messages are configured
  • webhook endpoints are configured only if the app needs them
  • API credentials are stored only in trusted backend environments
  • audit logs show expected configuration activity

Continue with the Activation checklist.