What to ask a software studio before you sign

Who is actually going to do the work?

The most common gap between the pitch and the build is the people. Senior staff win the work; junior staff deliver it. This is not always wrong — plenty of good work is done by people early in their careers with real supervision — but you should know which arrangement you are buying.

Ask who will be on the project, how much of their time you get, and whether the people in this meeting will be in the next one. Ask what happens if someone leaves mid-build. A studio with an honest answer will give you one quickly; a studio that has not thought about it will give you a reassurance.

The related question is whether the people who scope the work are the people who build it. Where those are different groups, estimates tend to be optimistic in exactly the places that matter, because nobody in the room has to live with them.

Who owns what, and can you leave?

You should own the code, the repository, the deployment pipeline and the documentation. Ask explicitly, and ask when you get them — handover at the end is worth less than access throughout, because access is what lets you verify progress rather than take it on trust.

The sharper version of the question: if we ended this engagement in month three, what exactly would we have? A studio that has built for handover answers plainly. A studio whose work only runs on their own infrastructure, or whose deployment only one person can perform, will produce a more complicated answer. That complication is the warning.

Ask about third-party accounts too. A build sitting in the studio's hosting account, under their domain registrar, with their API keys, is a build you do not fully control — even when the code is yours.

What happens when the scope changes?

It will. The question is whether the process for it was agreed in advance or will be invented under pressure. Ask how change requests are priced, who approves them, and what the studio does when it discovers mid-build that something was underestimated.

A good signal is whether the proposal states its assumptions. An estimate with written assumptions can be adjusted by arithmetic when one turns out false. An estimate without them turns every surprise into a negotiation about who was supposed to know.

Ask what happens after launch, too, and be specific: who fixes a bug in month two, what the response time is, and whether that is included or billed. The week after launch is when small teams are structurally weakest, and a studio that has no answer here has not run its own software in production.

Can they show you something real?

Ask for something live that you can open, not a case study PDF or a dribbble shot. Then open it on a phone, on a slow connection, and — if your product will be bilingual — in both languages. Five minutes of that tells you more than an hour of presentation.

If a studio claims bilingual or right-to-left capability, check it rather than taking it. Look at whether numbers and Latin names sit correctly inside Arabic lines, whether icons that should not mirror have stayed put, and whether the Arabic typography was tuned or merely substituted. These are the details that separate a studio that has done the work from one that has configured a plugin.

Questions worth asking verbatim

• Who specifically will build this, and will the people in this meeting be on the project?
• Do the people who scoped it build it?
• If we stopped in month three, what would we have, and could another team continue?
• Whose accounts hold the hosting, the domain and the API keys?
• What assumptions is this estimate resting on?
• How is a change request priced and approved?
• Who fixes a bug in month two, how fast, and is it billed?
• Can I open something you built, right now, on my phone?

Common questions

Related guides

• How to scope an MVP so it actually ships
• What drives the cost of building software