Apache Superset vs Metabase

Choose Superset when analysts write SQL and you want Apache-2.0 terms with no paid edition. Choose Metabase when business users build their own questions and you can fund a Pro plan for SSO and row-level security.

On this page

Which self-hosted BI tool fits your team: Superset or Metabase

If your team has SQL-fluent analysts who will write and share queries, and you want Apache-2.0 terms with no paid edition, Apache Superset is the stronger fit. If your priority is self-serve questions from business users, with a lighter setup for them, Metabase is the better match, but plan for a paid Pro plan once you need single sign-on or row-level security. Four factors settle the choice: who builds dashboards, what permissions you must enforce, which identity integrations you require, and which services each tool needs to run in your environment.

Start with the builders. Superset's SQL Lab and no-code chart builder suit analysts who want full control of the query, while Metabase's question builder suits people who will never open a SQL editor. Next, list your permissions needs. Superset has no paid edition, so its role model is included in the open-source product. Metabase's Open Source edition is AGPL licensed, and its row and column level permissions, SSO, usage analytics and auditing are paid Pro or Enterprise features. Check the Metabase pricing page against your exact requirements before you assume the free tier covers them.

Then look at identity and operations. Superset supports OAuth2 providers, LDAP and group-to-role mapping through AUTH_ROLES_MAPPING, and it requires a user-specified SECRET_KEY to start. Metabase's open source and Starter plans support Google sign-in and LDAP, while SAML, JWT, OIDC and SCIM need Pro or Enterprise. Confirm the services each tool needs: Superset's alerts, async queries and thumbnails depend on Redis and Celery workers, while Metabase relies on PostgreSQL as its application database for production. Ask your team to map these requirements to a written scope before choosing.

Which tool fits which team scenario

This table maps common team situations to the tool that fits better and notes where the other tool is still workable. Read each row as a condition: the named tool wins when that condition holds, and the other tool can still work with more setup or a paid plan.

ScenarioBetter fitWhy
Analysts who write SQL and build dashboards themselvesApache SupersetSQL Lab, the SQL IDE, and the semantic layer suit analysts who think in queries. Metabase can work for them too, but its query builder and SQL editor are aimed more at mixed audiences.
Business users who ask their own questions without writing SQLMetabaseIts guided question builder and drill-through are designed for non-technical users. Superset's no-code chart builder works, but expect more onboarding for people who have never used a BI tool.
Different teams that must see different rows of the same tableSuperset, if you configure row-level security yourself; Metabase Pro or Enterprise otherwiseMetabase lists row and column level permissions as a paid Pro or Enterprise feature. Open-source Metabase does not include them, so the cost moves into the license decision.
SSO with SAML or OIDC required from day oneMetabase Pro or Enterprise, or Superset with OAuth2 or LDAPMetabase's open-source and Starter plans include Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM need Pro or Enterprise. Superset supports OAuth2 providers and LDAP, mapping groups to roles with AUTH_ROLES_MAPPING. Confirm the exact protocol your identity provider needs.
No appetite for a paid BI licenseApache SupersetSuperset is Apache-2.0 and has no paid edition. Metabase's open-source edition is usable, but SSO, row-level permissions and usage auditing sit behind paid plans if those controls are required.
A team that already runs Celery and RedisApache SupersetSuperset's alerts, reports, async queries and dashboard thumbnails use the caching layer and Celery workers, so a team with that stack can absorb them. Metabase runs with its embedded H2 database for demos and PostgreSQL for production, so it needs fewer moving parts.
Small team that wants the fewest services to runMetabaseMetabase runs as a JAR with PostgreSQL as its application database. Superset needs a metadata database, and production use adds caching and worker components. Superset is workable here if you accept the extra services.
Teams that expect frequent upgrades and want a predictable support windowMetabase, with confirmationMetabase publishes LTS versions supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Superset requires running database upgrades and checking UPDATING.md for breaking changes. Confirm the upgrade plan with both vendors.

How Superset and Metabase are built and what each needs to run

Both tools are web applications that sit in front of your databases, but they store state and scale differently. The cards below separate the services each one runs, what each service costs you to operate, and the decisions to settle before a pilot becomes production.

Superset application and metadata database

Superset is a Flask and React application that keeps dashboards, charts, datasets and users in a metadata database. The documentation tests PostgreSQL and MySQL for that role, and PostgreSQL 10 to 17 and MySQL 5.7 and 8.x are the listed versions. The SQLite default used by Quickstart and PyPI installs is not recommended for production, and the Docker Compose PostgreSQL container is also not recommended for production. Plan a managed or separately backed-up database, and confirm the version against the configuration docs before you size it.

Superset caching, Celery workers and beat

The optional caching layer and Celery worker and beat processes are the parts that turn Superset from a web app into a fuller platform. Async queries, alerts and reports, and dashboard thumbnails depend on them, and most installations use Redis and Celery for this. Each adds a service to monitor, a queue to watch and a sizing question. Decide early whether you need these features, because a web-only deployment has fewer moving parts.

Metabase JAR and application database

Metabase ships as a single JAR written in Clojure and Java, which keeps the runtime footprint simple to package. Its application database stores questions, dashboards and permissions. Metabase ships with an embedded H2 database for demos, and its documentation recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported. Treat the H2 default as a trial setting, and plan a migration with the load-from-h2 command if you start there, run by the same Metabase version that last wrote the H2 file.

Metabase upgrades and migrations

Metabase runs application database migrations automatically during an upgrade. The documentation recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading one release at a time from versions older than 40. Budget a maintenance window for each major upgrade and rehearse it in staging. Non-LTS releases usually reach end of life after about two months, so plan for regular upgrades or pick an LTS line.

Superset upgrades and secret keys

Superset upgrades are manual steps: back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md for breaking changes. Superset also requires a user-specified SECRET_KEY to start, and PREVIOUS_SECRET_KEY supports rotation. Losing or mismatching the key can break access to stored credentials, so record it in your secrets manager. Confirm the upgrade path for your target version before you schedule work.

Capability comparison from published facts

This table sets Apache Superset and Metabase side by side on license, paid features, identity integration, permissions, embedding, query tooling, database options and release support. Where the published facts do not confirm a capability for one tool, the cell tells you what to check in the vendor documentation before you decide.

CapabilityApache SupersetMetabase
LicenseApache-2.0 for the whole project, with no paid editionAGPL for the open-source edition, with code under the Metabase Commercial License in the enterprise directory and separate paid editions
Paid featuresNone to buy from the project; confirm any third-party hosted offering separatelyPro and Enterprise plans add SSO, row and column level permissions, usage analytics and auditing, and embedding without Metabase branding
SSO and group mappingOAuth2 providers such as Google and Azure, plus custom OAuth2 servers using the code flow; AUTH_ROLES_MAPPING maps OAuth or LDAP groups to rolesGoogle sign-in is in the open-source and Starter plans; JWT, OIDC, SAML and SCIM require Pro or Enterprise
LDAPSupported, with group-to-role mapping through the same configurationSupported in the open-source and Starter plans; advanced LDAP group and attribute sync requires Pro or Enterprise
Row and column permissionsRow level security is a core Superset feature; confirm column-level options in the Superset documentationRow and column level permissions require Pro or Enterprise
EmbeddingEmbedded SDK with guest tokens; confirm the current options and licensing in the Superset documentationGuest embeds are part of the product, while embedding without Metabase branding requires Pro or Enterprise
SQL editorSQL Lab is a core SQL IDE included in the projectConfirm the native SQL editing options for your edition in the Metabase documentation
No-code question builderNo-code chart builder for dashboardsSelf-serve question builder aimed at non-technical users
Application database optionsMetadata database tested with PostgreSQL and MySQL; PostgreSQL 10 to 17 and MySQL 5.7 and 8.x are listed as supported versions; SQLite is for quickstart onlyEmbedded H2 for demos; PostgreSQL recommended for production; MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 supported
Release support windowsConfirm the support window for each release line in the Apache Superset release notesLTS versions supported for 14 months; non-LTS versions usually reach end of life after 2 months
Current release lines6.1.0 released May 13, 2026; 7.0.0 release candidates in October 2026Metabase 64 LTS (September 16, 2026, end of life December 1, 2027); Metabase 65 released October 12, 2026

What each license allows and which features cost money

Apache Superset is released under the Apache License 2.0 (SPDX identifier Apache-2.0), and the project has no paid edition. The SQL IDE, the no-code chart builder, caching and the semantic layer all sit under the same license, so there is no separate commercial tier to evaluate and no feature that a vendor holds back for a plan.

  • One license to review: Your legal review covers one license text and one set of notice obligations for the Superset codebase itself.
  • No feature gating: Capabilities are not sorted into paid tiers, so your cost decisions center on the infrastructure and staff needed to run the platform.
  • Redistribution: Apache-2.0 generally allows you to modify, embed and redistribute the software, provided you keep the license and notice files and document changes. Confirm the exact obligations with counsel.
  • Trademark: The license does not grant rights to the Apache name or logo, so review branding rules before you ship a relabeled product.
  • Third-party components: Dependencies carry their own licenses, so include them in your scan of the full dependency tree.

Before approval, have counsel review the project's NOTICE file and a software bill of materials for your build, since those documents show which licenses your deployment actually inherits.

How SSO, LDAP and group mapping differ, and which need a Metabase plan

Identity is where the two tools diverge most sharply on licensing. Apache Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the authorization code flow, and LDAP. Its AUTH_ROLES_MAPPING setting in the configuration file maps groups from LDAP or OAuth claims to Superset roles, so access follows your directory without a paid tier. Because Superset has no paid edition, every identity option described in its configuration documentation is part of the same Apache-2.0 product you deploy. The work is in the configuration itself: you own the superset_config.py file, the callback URLs, the client secrets and the role names your groups map to.

Metabase splits identity features across plans. Its Open Source edition and Starter plan support Google sign-in and LDAP. JWT, OIDC, SAML (with documented setups for Auth0, Entra ID, Google, Keycloak and Okta), advanced LDAP group and attribute sync, and SCIM provisioning require Pro or Enterprise, according to Metabase's people and groups documentation and its pricing page. If your identity provider is Entra ID, Okta or Keycloak over SAML or OIDC, or you need SCIM to remove users automatically, the Metabase plan decision is made before the first login test. Ask Metabase which plan includes each protocol you need, and confirm the price for your user count in writing.

Before committing to either tool, confirm your identity provider setup and group mapping in a test environment. Check that each group claim arrives as expected, that a user removed from a directory group loses access on the next login, and that role or group changes behave the way your access review assumes. For Superset, test AUTH_ROLES_MAPPING with a sample of real group memberships. For Metabase, test the protocol you plan to use on the plan you intend to buy, not on Open Source. Record the results so the identity design can be reviewed by your security and compliance owners.

How to move a dashboard estate from one tool to the other

This sequence moves dashboards, data connections, metrics, users and permissions from one BI tool to the other without losing track of what each report depends on. The result is a verified target estate and a retired source tool with a retained backup.

  1. Inventory dashboards, metrics and users

    The BI lead works with each dashboard owner to list every dashboard, saved question or chart, the SQL behind it, its data source, scheduled reports and alerts, and every user group with its access. If the source is Metabase and its application database is the embedded H2 default, plan the move to PostgreSQL or MySQL first, using the load-from-h2 command run with the same Metabase version that last updated the H2 file. This step is done when each owner signs off their part of the inventory.

  2. Recreate database connections and copy SQL

    Database connections do not carry over as working objects, so recreate each one in the target tool using a read-only service account. SQL written for native questions or charts transfers as plain text, so paste it into SQL Lab in Superset or the native query editor in Metabase and run it against the same source. This step is done when each migrated query returns the same results as the original over a sample date range.

  3. Rebuild semantic definitions in the target

    Metrics, filters, joins and dataset definitions need to be rebuilt in the target's modeling layer, which is Superset's datasets, metrics and calculated columns or Metabase's models and metrics. Ask each vendor, for the exact version you run, what can be exported or imported and what must be recreated by hand. This step is done when the rebuilt metric list matches the inventory line by line, with any gaps recorded.

  4. Provision users and groups through identity

    Plan to provision users in the target rather than assume accounts will copy across, and drive access from groups where possible. Superset maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. In Metabase, SSO, SAML, JWT, OIDC and SCIM provisioning require a Pro or Enterprise plan, so confirm the plan before cutover. This step is done when test users from each group sign in and receive the roles the inventory expects.

  5. Validate permissions with test accounts

    Create one test account per persona, such as an analyst, a restricted viewer and any external or embedded audience, and record what each should see. In Metabase, row and column level permissions require Pro or Enterprise, so check that the plan supports every rule you need. Log in as each test account and compare visible rows, columns and export rights against the matrix. This step is done when every account matches the matrix and each discrepancy is logged and fixed.

  6. Rebuild embeds and retire the old tool

    Treat charts, permissions and embeds as rebuilt items, then re-issue embed configuration in the target and test it on the embedding application. Run both tools in parallel until users confirm their reports, then back up the source metadata database and set the old tool to read-only. Superset's upgrade guidance recommends backing up its metadata database before changes, so apply the same discipline to the retired instance. This step is done when users confirm their reports, the source is read-only, and the backup is stored.

What drives the running cost of each tool

Running either tool costs more than its licence line. Infrastructure, skilled people, paid plan features, upgrades and support each carry their own cost, and most of them recur. The cards below set out who gets paid for each component and what to ask for in a quote.

Infrastructure for each platform

Apache Superset needs a metadata database (PostgreSQL or MySQL, not the SQLite default), and most installations add Redis and Celery workers for alerts, reports, async queries and thumbnails. Metabase needs an application database (PostgreSQL recommended for production) and hosting for its JVM process. Infrastructure is mostly recurring. Ask your cloud or hosting provider, or your DeployOpen scope, to list each service, its sizing and its backup and monitoring method.

Skilled people to run and query

Superset rewards people who write SQL, since SQL Lab and the semantic layer are central to it. Metabase lets non-technical users build questions through its interface, which can shift routine work away from analysts. Both still need an administrator for upgrades, permissions and connections. This is usually the largest recurring cost and depends on salary or contract rates in your market. Ask who builds dashboards, how many admins you need, and whether that time is already budgeted.

Metabase plan fees and included users

Metabase publishes Starter at $100 per month, or $90 per month billed yearly, with the first 5 users included, and Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Extra users cost $6 per month on Starter and $12 per month on Pro. SSO, row and column level permissions, and usage analytics and auditing require Pro or Enterprise. Superset has no paid edition, so this line is the main licence-driven difference. Confirm current prices and included users on the pricing page before budgeting.

Enterprise quotes and procurement

Metabase Enterprise is priced by quote, starting at $20,000 per year according to its pricing page. Ask for a written quote that lists the user count, support level, deployment model and any embedding terms. Superset carries no equivalent licence fee, but you may still pay for a commercial support contract from a third party or DeployOpen. Clarify before signing what the quote covers and what happens to pricing as your user count grows.

Upgrade and testing effort

Superset upgrades require backing up the metadata database, running superset db upgrade and superset init, testing in staging, and checking UPDATING.md for breaking changes. Metabase runs application database migrations automatically, but its docs advise a backup first and reducing a cluster to one node for major upgrades. Non-LTS Metabase versions reach end of life after about two months, so the upgrade cadence is a recurring cost. Budget staff time for a test cycle every release, whichever tool you pick.

Support and incident response

Superset is community-supported under Apache Software Foundation governance, so response time depends on your own team or a contracted partner. Metabase support tiers are tied to its paid plans. Either way, an outage in a dashboard that executives rely on can cost more than the software. Ask any vendor or partner for the response windows, escalation path and what is excluded. DeployOpen supports self-hosted platforms through fixed-scope engagements and retainers, with terms set in writing.

Where Superset and Metabase projects usually run long

The long-running work in a Superset project is rarely the first install. It is the production baseline: a user-supplied SECRET_KEY that must be set before the application starts, a metadata database chosen deliberately, and the caching and worker layer if alerts, reports, async queries or dashboard thumbnails are on the requirements list. The architecture documentation says the SQLite default of quickstart and PyPI installs and the Docker Compose PostgreSQL container are not recommended for production, and that PostgreSQL and MySQL are the tested choices, so plan the database service and its backups before anyone builds a dashboard. If you need the worker layer, budget time to run Redis and Celery worker and beat processes and to monitor them. For Kubernetes, the 6.1.0 docs describe the official Helm chart, but the current development docs mark that chart as deprecated and point new deployments to the Apache Superset Kubernetes Operator, so confirm which path your platform team will support before writing deployment code. Upgrades follow a fixed sequence: back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md for breaking changes.

On the Metabase side, the first production task is moving off the embedded H2 application database. Metabase recommends PostgreSQL for production and documents a one-time load-from-h2 command, which must run with the same Metabase version that last wrote the H2 file, so record that version before you start. Upgrades run application database migrations automatically. Back up the application database first, and for major upgrades the docs recommend reducing a cluster to a single node because of a migration lock, which means a planned maintenance window rather than a rolling change. Identity is the step most likely to surprise budgets. SSO, JWT, OIDC, SAML and advanced LDAP group sync are not part of the open-source or Starter plans, so an SSO requirement changes the licensing decision, not only the configuration. Confirm the required plan with Metabase before you design the identity flow.

Across both platforms, three tasks consume the most calendar time regardless of tool: data modeling, permissions design and identity setup. Modeling means deciding which tables become curated datasets, how metrics are defined and who owns them. Permissions design means mapping business roles to database access, and in Superset that runs through role mapping with AUTH_ROLES_MAPPING from OAuth or LDAP groups, while in Metabase row and column level permissions sit behind a paid plan. Write the role matrix and the group names with your identity team before the first pilot, and test each role with a non-admin account. Ask your implementation partner or internal team to estimate these three workstreams separately, because they, not the software installation, determine when the BI platform is ready for business users.

Questions buyers ask before choosing Superset or Metabase

Which tool costs less to run for a small team?

Superset usually has the lower license bill because it has no paid edition, but the running cost depends on what you operate around it. Metabase's Open Source edition is also free, yet the Starter and Pro plans are published per month, with Starter at $100 per month or $90 per month billed yearly with the first 5 users included, and Pro at $575 per month or $517.50 per month billed yearly with the first 10 users included, according to the Metabase pricing page. Additional users cost $6 (Starter) or $12 (Pro) per month. Ask both vendors and your own platform team what each cost driver adds up to: hosting, the metadata database, a cache and worker tier for Superset, and the admin hours for upgrades in each case.

Does Superset need a paid edition for SSO?

No. Superset is Apache-2.0 licensed and has no paid edition, so OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP are configured in the open-source product. Group-to-role mapping uses AUTH_ROLES_MAPPING in the configuration. The effort lies in configuring the identity provider, testing sign-in in staging, and deciding how groups map to roles. Confirm the exact group claims your identity provider sends before you build role mappings, because mismatched claims are a common source of access problems.

Which Metabase features need a Pro plan?

On Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation, and usage analytics and auditing are included only in the Pro and Enterprise plans. Open Source and Starter do not include them. Within identity, JWT, OIDC, SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta, advanced LDAP group and attribute sync, and SCIM provisioning also require Pro or Enterprise, according to Metabase's people and groups documentation. Google sign-in and LDAP remain available on the open-source and Starter plans. List the access rules and audit requirements you need before you pick a plan, since those drive the upgrade.

How much SQL knowledge do analysts need?

It depends on who builds the dashboards. Metabase is aimed at non-technical users who can ask questions through a point-and-click interface, so analysts with little SQL can build many charts. Superset offers a no-code chart builder, but its SQL IDE, SQL Lab, and semantic layer reward analysts who write queries and define metrics. A mixed team usually needs at least one person who can write SQL and maintain shared definitions, whichever tool you choose. Run a pilot with your real questions and see how many of them business users can answer without help.

Can a team run either tool without outside help?

Yes, both are self-hostable, and many teams run them internally. The work that most often needs experienced help is production setup: choosing and backing up a PostgreSQL or MySQL metadata database, deciding whether to run Redis and Celery workers for alerts, reports and async queries, and building a repeatable upgrade path. Superset's architecture documentation says SQLite and the Docker Compose PostgreSQL container are not recommended for production. Metabase recommends PostgreSQL for its application database rather than its embedded H2 database. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure under a fixed-scope written agreement, and ongoing support is available as a retainer. Ask for the written scope before deciding which parts to keep in-house.

What does the work need from our own staff?

Plan for people who can operate a web application, a relational database, and for Superset, a cache and worker layer. Your staff will need to handle backups, monitoring, secret management and identity configuration, along with a test environment for upgrades. Superset requires a user-specified SECRET_KEY to start and supports rotating it with PREVIOUS_SECRET_KEY, so someone must own that process. Upgrades involve backing up the metadata database, running superset db upgrade and superset init, and checking UPDATING.md for breaking changes. Metabase runs application migrations automatically, and its docs recommend a backup first and reducing a cluster to one node for major upgrades. Confirm your team's capacity for these tasks before committing.

How long does a migration between Superset and Metabase take?

The duration depends on the size of your dashboard estate, how many saved queries and metric definitions must be rebuilt, how permissions are modeled, and how many data sources are involved. Moving dashboards is rarely a direct export, so the work is largely rebuilding logic in the new tool. Metabase's H2 application database can be moved with a one-time load-from-h2 command, but it must run with the same Metabase version that last updated the file, according to Metabase's migration documentation. Map your permission model and identity groups first, since those usually set the critical path. Ask any implementation partner for a written scope and timeline based on an inventory of your dashboards.

Does the AGPL license of Metabase affect us?

For most internal use, the AGPL does not prevent you from running Metabase, but its terms matter if you modify Metabase and make it available to others over a network, or if you embed it in a product. Metabase's LICENSE.txt states that the source outside the top-level enterprise directory is AGPL licensed while code inside it is under the Metabase Commercial License. Superset is Apache-2.0 licensed, which has different obligations. Have your legal team review how you plan to use, modify and distribute either tool, especially for customer-facing embedding. This is a licensing question for counsel, not a conclusion this page can settle.

How DeployOpen helps you choose and implement either tool

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the choice between Apache Superset and Metabase is tested against your data sources, identity model and permission rules before anything is built. The work runs as a fixed-scope engagement with deliverables agreed in writing first.

How we scope

  • Inventory the databases, identity provider and user groups the BI tool must reach before choosing a path.
  • Write down which roles build dashboards, which only view them, and which need row or column restrictions.
  • Agree in writing which edition, plugins and services fit the scope, including Metabase Pro features if needed.
  • Record the hosting target, backup expectations and upgrade cadence so the quote follows from a defined scope.

How we build

  • Deploy the chosen tool in your cloud account, data center or air-gapped network with the metadata database you approve.
  • Configure SSO, group-to-role mapping and data permissions, then test them with sample accounts for each role.
  • Set up caching, background workers or scheduled jobs only where your reports and alerts require them.
  • Run security checks on the deployment, including secret handling, network exposure and access logging.

How we hand over

  • Document the architecture, configuration keys, role mappings and the services your team must monitor.
  • Provide a tested backup and restore procedure for the application database and a staged upgrade runbook.
  • Walk your administrators through permission management, dashboard ownership and change control.
  • Deliver compliance-ready evidence of configuration and access controls for your assessors to review.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Plan each upgrade against the vendor's release notes and breaking-change list, testing in staging first.
  • Re-test permissions and embedding settings whenever identity or data source configuration changes.
  • Confirm current edition terms and license scope with the vendor before any licensing decision is finalized.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.