Choose a product studio or software agency

Start with uncertainty, not supplier category

Write down what is known, what remains uncertain and which decision would make the next investment reversible. If the user problem, smallest release and acceptance evidence are still open, the engagement needs product discovery as well as implementation. If the requirements, interfaces and governance are already stable, the main need may be reliable delivery against a defined programme. The words studio and agency do not settle that distinction.

Ask every supplier to describe the first two weeks in concrete outputs. Useful outputs can include a problem statement, non-goals, decision log, interface map, prototype, risk register and release evidence plan. Reject a proposal that turns uncertainty into a fixed promise without showing how assumptions will be tested. A smaller initial commitment often reveals more than a large feature estimate prepared before the important questions are answered.

Compare the team that will actually do the work

A product studio often concentrates product, design and engineering judgment in a small senior team. That can shorten decisions for a focused release, but it also creates finite capacity and key-person risk. An agency may offer more specialists and parallel delivery, but the sales team, project team and maintenance team may be different. Ask for names, roles, availability, review paths and the conditions under which people can change.

Match team shape to the product risk. A narrow mobile or web product may benefit from direct senior ownership and few handoffs. A programme involving identity, data migration, several interfaces, regulated review or organisational change may need specialists working in parallel. Do not pay for an organisational shape that the scope does not need. Do not under-resource a release whose security, operations or domain obligations require independent review.

Define ownership before implementation

Record who decides scope, accepts evidence, owns production accounts, supplies content, approves legal or security choices and can stop a release. The client should be able to inspect the current backlog, decisions and deployed state without depending on one supplier account. Source control, domains, stores, analytics and provider organisations should have explicit ownership and revocable access. Shared credentials and personal production accounts weaken any delivery model.

Make the handover artefacts part of acceptance rather than an optional final week. A maintainable handover includes repository access, environment inventory, deployment instructions, data boundaries, monitoring, recovery steps, known limitations and the next decision points. Documentation alone is not proof that another person can operate the product. Schedule a practical handover exercise in which the receiving owner follows the runbook and records what remains unclear.

Separate delivery evidence from business outcomes

A prototype can prove that an interaction is understandable in a test. Automated checks can prove specified behaviour in a controlled environment. A deployment can prove that an approved build reached production. None of those facts proves adoption, retention, revenue or product-market fit. Require the supplier to label each claim with the evidence that directly supports it and to keep external provider approval separate from local implementation.

Agree a small measurement plan before launch. Define the event, source, period, exclusions and decision that each metric informs. A product studio or agency should be able to show what was built and verified without inventing customer results. The commercial outcome remains shared with positioning, distribution, pricing, operations and the decisions made after observing real use. This boundary makes delivery review fairer and reduces exaggerated case-study language.

Use a bounded first engagement

When uncertainty is high, start with a paid discovery or one production slice whose result remains useful if the relationship stops. Define the question, maximum duration, outputs, acceptance method and follow-on decision. Compare how each candidate handles non-fit, missing evidence and scope reduction. Restraint is a useful signal: a supplier should be willing to recommend an internal hire, specialist review or no build when those options fit better.

Before expanding, review decision quality, technical evidence, communication, ownership and recovery, not only visual polish or feature count. Confirm who will maintain the product, how incidents are handled and how future changes are estimated. Choose the model that leaves the product more understandable and operable after the first release. The right answer may be a studio, an agency, an internal team or a hybrid with clearly divided responsibilities.

Decision criteria

Use the same questions for every option before choosing.