How to choose a SaaS development studio in Paris

Define the service and tenant boundary first

Name the people who use, administer, support and pay for the service, without assuming they share the same permissions or organisation. Describe one critical workflow from invitation or account creation through the intended outcome. Decide whether data belongs to an individual, workspace, customer organisation or another tenant boundary, and who may export, delete or transfer it. Record regional, contractual, accessibility and retention constraints. These decisions shape identity, audit, support and data architecture before a studio can responsibly define the first release.

Do not use SaaS as shorthand for any application with a login. A service may need tenant isolation, role management, background jobs, support tools, billing states, usage limits, integrations, backups, incident response and change communication. A local studio page does not prove that every capability is currently offered or that a team is available. It also cannot promise subscriptions, adoption, reliability or revenue. Ask the candidate to identify which responsibilities are included, which remain with the client and which depend on a cloud, identity or payment provider.

Make identity, data and billing explicit

Draw the path from identity to tenant context, authorisation, business action, audit event and stored data. Decide whether isolation is enforced in the application, database, infrastructure or several layers, then test the assumptions. Define privileged administration separately from ordinary product roles. Where subscriptions apply, model product access from authoritative billing events instead of assuming a checkout response settles every later state. Stripe documents subscription lifecycles and webhook-driven events, but the product team still owns idempotency, entitlement rules, reconciliation, support and failure handling.

Inventory authentication, email, files, analytics, payment, tax, customer support, search, queues and every external integration. For each one, record data shared, credentials, environment separation, quotas, retry behavior, outage response and exit route. Decide what the service does when an event is duplicated, delayed or missing. Map deletion and export across internal stores and processors using the CNIL privacy guidance relevant to the actual data. A vendor dashboard is not a substitute for an owned architecture and tested recovery path.

Deliver one operable vertical service slice

Ask for a first slice that includes the user journey, the relevant administrative action, permissions, audit evidence, error behavior and operational telemetry. If billing is in scope, include a controlled subscription lifecycle and reconciliation rather than only a payment screen. If data migration is required, define mapping, validation and rollback before moving production records. The slice should be useful enough to test a real service decision while remaining narrow enough that assumptions can change without rewriting an entire platform.

Request named ownership for product, interaction design, frontend, backend, platform, data, quality, security and operations. A small team may cover several disciplines, but critical changes still need review and an accountable approver. Ask who designs tenancy and authorisation, who investigates provider failures, who handles support tools and who can restore service. Confirm repositories, cloud organisations, domains, identity, billing, analytics and incident channels remain under explicit organisational control with scoped access for the studio.

Test service states, not only the happy path

Acceptance should cover tenant isolation, roles, invitation and removal, invalid or duplicated events, background-job failure, accessibility, personal-data requests, auditability and recovery. Where subscriptions apply, test creation, change, failed collection, cancellation and entitlement reconciliation using provider-supported test environments without treating those tests as live revenue. Apply NIST secure-development practices and a risk-appropriate OWASP ASVS level. Restore representative data into a controlled environment and prove that an authorised operator can diagnose a critical workflow from logs and metrics.

Define acceptance as observable evidence. Examples include a tested user journey, an approved build, reproducible checks, an incident runbook and a verified handover. None of those proves retention, revenue or product-market fit. Keep delivery proof, external provider approval and business results as separate claims.

Assign support, incident and change ownership

Name owners for uptime monitoring, security alerts, support requests, failed jobs, data corrections, billing reconciliation, provider changes, backups and privacy requests. Define what can be automated, what needs human approval and what must stop when evidence is missing. Keep runbooks for the most consequential failure modes and practise them outside production. Review dependency and access inventories as the service changes. A deployed SaaS page or configured billing account proves implementation state only; it does not prove reliability, customers, subscription revenue or continuous availability.

Keep source control, domains, stores, analytics, cloud organisations and production credentials under explicit organisational ownership. Grant scoped, revocable access and rehearse handover before the final invoice. The supplier label matters less than whether another authorised person can inspect, deploy, recover and continue the product.

Decision criteria

Use the same questions for every option before choosing.