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. Select Create App.

The app is created immediately and opens Run locally. Follow the SvelteKit starter guide for a downloadable workspace, or choose Connect your app for the SDK integration path. You can return to the app Overview for configuration checks at any time.

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, which required launch checks are complete, 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?
  • is account email ready enough for invitations, verification, and recovery?
  • is a backend API key available for SDK or REST calls?
  • are external notifications configured if the backend needs events?
  • what is the next setup action?

The Get started sequence covers sign-in, account email, backend API key, and first users. Organizations and Webhooks are separate, conditional steps. The score counts configuration, not successful sign-in or email delivery.

Step 5: Create an organization if your product needs one​

Use organizations for shared customer accounts, team membership, and tenant-scoped services. Individual-user sign-in does not need an organization; skip this step for that journey. For a team-based app, 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 Products > 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 Products > 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 Products > 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 Developer > 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 Developer > 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
  • API credentials are stored only in trusted backend environments
  • webhook endpoints are configured only if the app needs them
  • audit logs show expected configuration activity
  • the app overview launch checklist shows no required blockers

Continue with the Activation checklist.