How to choose a product studio in Paris

Start with fit, not a Paris address

A local search can narrow the field, but proximity does not decide whether a studio understands the product or can operate it. Write down why Paris matters. The reason may be a shared working day, French contractual context, occasional in-person decisions, access to a local founder network or simply a preference for a team that communicates in French. Confirm the practical arrangement directly. A page that says Paris does not by itself promise an office visit, permanent on-site staffing or availability on a particular date.

Evaluate category fit separately. A product studio normally combines product judgment, design and engineering around a defined software problem. It is not automatically a venture investor, recruitment firm, general marketing agency or substitute for company leadership. IVRYN states that it designs, engineers and operates software from initial sketch to supervised live operation. A prospective client should still verify which roles apply to the proposed scope, who performs them and which responsibilities remain with the client.

Define a bounded first engagement

Begin with a decision that remains useful even if the relationship stops. Examples include clarifying one user workflow, testing a risky integration, producing an operable prototype or delivering one production slice with explicit acceptance checks. Name the user, current problem, existing evidence, fixed constraints, decision deadline and internal owner. France Num guidance on preparing a digital brief similarly emphasises objectives, functional needs, integrations, expected deliverables and evaluation criteria before selecting a provider.

Separate the desired business result from the work a studio can verify. A studio may demonstrate that an agreed build passed tests, reached a controlled environment or was deployed publicly. Those facts do not prove adoption, revenue, retention, financing or product-market fit. Put deliverables, exclusions, dependencies and review points in writing. A responsible first proposal can also recommend more discovery, a specialist, an internal hire or no immediate build when the evidence does not support implementation.

Inspect evidence, ownership and security

Ask for dated, inspectable evidence rather than a gallery of logos. Review public products, source artifacts where available, operating notes, test boundaries and the exact role claimed by the studio. IVRYN publishes an About page, methodology and portfolio evidence hub that distinguish public technical facts from customer or commercial outcomes. Use those pages to prepare questions, but verify the current environment and do not infer active users, revenue, customer satisfaction or uninterrupted operation from a public link.

Agree ownership before development begins. Identify who controls the repository, domain, cloud accounts, app stores, analytics, database, payment providers and recovery credentials. Use organisation-owned accounts with scoped access where practical. The CNIL developer guide recommends integrating privacy into design and treating source control, personal data and secure development as first-order concerns. Add the product-specific threat model, access rules, deletion path and incident responsibilities required by the actual data and workflow.

Compare team shape and working rhythm

Request the names and roles of the people expected to work on the engagement. A compact senior team can reduce handoffs for a focused product, while a broader agency or internal team may provide more parallel specialists. Neither shape is universally better. Compare product decision authority, engineering depth, design responsibility, quality review, security coverage, availability and continuity. Clarify whether the person who scopes the work will also design, build, review and support it.

Decide how Paris changes the operating rhythm. Record working language, response windows, meeting format, documentation standard and the moments that genuinely benefit from being together. Keep asynchronous decisions in a shared written record so proximity does not become undocumented context. For remote or hybrid delivery, test access, review and incident procedures early. For any in-person session, define the decision it must produce rather than treating physical presence as evidence of progress.

Contract handover and post-launch operation

A release needs an owner after the launch moment. Decide who monitors availability, receives alerts, answers support requests, reviews dependencies, restores backups and approves the next change. If the studio will operate part of the product, name the service boundary and escalation path. If the client will take over, require an environment inventory, deployment procedure, known limitations, recovery steps and a practical handover exercise. Documentation is useful only when another authorised person can follow it.

Make the final choice with the same scorecard for every candidate. Compare understanding of the problem, quality of questions, scope discipline, evidence standard, ownership model, security approach, operating responsibility and exit path. Do not reward a provider for accepting every request without qualification. The strongest answer may narrow the release, expose a missing decision or decline work outside its competence. Choose the arrangement that leaves the product understandable, controlled and operable after the first engagement.

Decision criteria

Use the same questions for every option before choosing.