In this article
Choose the company that can name who will lead your project, show you work like yours with real results, explain how they price it and how you can stop, and tell you plainly what they won’t do. Portfolios and hourly rates tell you far less than how a team answers a few direct questions.
Below are the twelve questions we’d ask if we were in your seat, what a good answer sounds like, and the answers that should end the conversation. We’re a software studio, so read this knowing we have a stake. We’ve tried to write the questions we’d want a client to ask us, including the ones that would rule us out.
Who will actually do the work
1. Who leads my project, and how experienced is everyone working on it?
A good answer: A name and a role for the lead, and the experience of every engineer on the team. You should meet your lead before you sign.
Walk away if: You get “a dedicated team”, nobody can say who is responsible for the result, or the senior people from the sales call disappear once you sign.
2. Will I talk to the people building it?
A good answer: Yes, directly, with a working demo on a regular schedule, ideally every week.
Walk away if: Everything goes through an account manager who has never seen the code.
3. How many of my working hours will we share?
A good answer: A specific number of hours, written into the contract.
Walk away if: “We’re flexible.” Flexible usually means your questions wait until tomorrow.
Whether they've done it before
4. Can you show me something similar, with a result?
A good answer: A case study that names the problem, the constraint and a number that changed.
Walk away if: Screenshots and logos with no outcome attached.
5. What went wrong on that project, and what did you do about it?
A good answer: A specific, slightly uncomfortable story and what they changed afterwards.
Walk away if: “Nothing went wrong.” Something always goes wrong.
6. What kind of project would you turn down?
A good answer: A clear answer. A firm that knows its limits will tell you early when you’re outside them.
Walk away if: They’ve never said no to anything, which means they’ll learn your project’s hard parts on your budget.
How they price and plan
7. How do you price it, and what happens when the scope changes?
A good answer: A fixed price per milestone, or time and materials with a cap, plus a written process for changes.
Walk away if: One big fixed price after a single call, or open-ended hourly billing with no cap.
8. Can I stop after a milestone and keep what’s been built?
A good answer: Yes, with a clear exit point after each milestone.
Walk away if: You’re locked in until the end, or the code only becomes yours on final payment.
9. What do I get before I commit to the full build?
A good answer: A short, paid discovery phase that ends with a plan, milestones and costs you keep either way.
Walk away if: Nothing. You’re asked to commit to the whole build on a sales call.
What you'll own, and how it will run
10. Who owns the code, and from when?
A good answer: You do, once each milestone is paid, in a repository you control.
Walk away if: The code lives in their account and ownership is vague in the contract.
11. How will it be tested, released and monitored?
A good answer: Specifics: automated tests, a staging environment, a rollback plan and monitoring in production.
Walk away if: “We test everything manually before launch.”
12. What happens after launch?
A good answer: A handover of code, docs and access, plus optional ongoing support on clear terms.
Walk away if: Only they know how it works, so leaving them means starting over.
Red flags that should end the conversation
- A full fixed price after one call, before anyone understands the problem.
- Nobody can tell you who leads the work.
- Every answer is “yes, we can do that”.
- They push a full rewrite of your existing system before reading the code.
- The cheapest bid by a wide margin. The difference is usually paid back later, in rework.
How to use these questions
Send all twelve, in writing, to two or three firms on your shortlist. Written answers are easier to compare, and they show you how each firm communicates, which is most of what you’re buying. Then take the best one or two onto a call and ask follow-ups on whatever they were vague about.
If you’re not technical, that’s fine. None of these questions need technical knowledge to ask, and a good firm will answer every one of them in plain language.
How we’d answer them
Briefly, since it would be odd to write this and dodge it:
- Every engineer on your project is senior, with at least 4 years of shipping production software. A lead engineer is named before work starts and is your contact throughout.
- At least 50% of your working day overlaps with ours, agreed before work starts.
- Most projects start with a one-week discovery sprint. Builds are priced as a fixed price per milestone, with an exit point after each one.
- You own the code, designs and docs for each milestone once it’s paid.
- We turn down requests to rent developers with no one owning the result, and work where the cheapest option matters more than getting it right.
Our case studies each list the problem, what we built and what changed, so you can check the second group of questions yourself.