How to choose a SaaS development partner: 9 questions that matter

The answer should be: you, from the first commit, in your own accounts. Anything else creates leverage over you later.

Warning signs are code held in the vendor's repositories until final payment, infrastructure running in the vendor's cloud account, and proprietary frameworks you cannot maintain without them. The last is the most common and the most damaging — a product built on an in-house framework nobody else knows is expensive to move and expensive to hire for.

Ask specifically: on day one, will commits land in a repository under our organisation, and will infrastructure run in our AWS or Azure account? If either answer is no, ask why.

This is the architectural decision that is most expensive to reverse, and the one most often deferred. Shared schema with row-level isolation, separate schemas per tenant, or separate databases — each has real consequences for cost, isolation guarantees, and what you can promise an enterprise buyer.

You do not need to evaluate the answer technically. You need to hear that the decision is deliberate, made against your expected customer profile, and made before implementation. A partner who says "we'll figure that out as we go" is telling you a retrofit is coming.

The retrofit is not theoretical. Adding tenant isolation to a product that assumed one customer is one of the most disruptive pieces of work a young SaaS company can face, and it usually lands exactly when the first enterprise deal makes it urgent.

Billing logic spreads. If it is scattered through the codebase, changing your pricing becomes an engineering project — and early-stage SaaS companies change pricing repeatedly.

Ask how plans, trials, upgrades, proration, failed payments, and tax are handled, and whether billing is isolated behind a boundary so pricing changes are configuration rather than code. Most teams should use Stripe or an equivalent rather than build this; be sceptical of anyone proposing to build billing from scratch.

Sales conversations are held by senior people; delivery often is not. Ask for the names and seniority of the engineers assigned, how many other projects they are on concurrently, and whether the people in your pitch will be in your standups.

A partner comfortable with this question will introduce the actual team before you sign. Vagueness here is the most reliable predictor of disappointment in the whole list.

Scope will change — you will learn things from real users that invalidate assumptions. What matters is whether the commercial model can absorb it.

Rigid fixed-scope contracts punish learning: every improvement becomes a change request and a negotiation. Pure time-and-materials with no ceiling gives you no cost control. A workable middle is a fixed budget with flexible scope inside it, prioritised sprint by sprint, so you can swap features without renegotiating.

Ask what proportion of their code is covered by automated tests, how deploys happen, and how a bad release is rolled back. The answers reveal engineering maturity faster than any portfolio.

The concerning answer is manual deployment with manual testing. It works at small scale and stops working precisely when you have paying customers who notice outages.

Ask this before you start, not at the end. You want documentation written as part of delivery, architecture decisions recorded, runbooks for the operational tasks, and a defined transition period.

A partner planning for a clean handover is confident you will stay for good reasons rather than because leaving is painful. This question also tests the ownership answers from earlier: real handover is only possible when you already own everything.

A partner who cannot recall an example is describing an order-taking relationship. In SaaS, the most valuable thing an experienced team does is cut scope — the features you do not build are what let you reach market before your assumptions go stale.

Good answers are specific: a feature deferred, an integration argued against, an AI capability recommended against because a database query would do. Listen for whether they were right, and whether they can say so plainly.

For EU products, GDPR is an architectural constraint: data residency, retention, subject access requests, and processing records all shape the build. Ask whether they have shipped a product under GDPR, not whether they are aware of it.

US products often need SOC 2 readiness ahead of enterprise sales; Australian and South African companies should confirm the overlap hours engineers will actually be available, because "we cover all time zones" frequently means asynchronous only. Get the committed overlap window in writing.