Questions to Ask a Software Development Company
For anyone about to hire an agency or development shop to build software: a founder, a business owner, or a manager with budget and no in-house engineering team. These questions cover who does the work, how change is priced, what you own at the end, and how the relationship ends.
The questions
Open any question for the note
Who exactly will write the code, and are they employees or subcontractors?
Why ask it
Sales meetings are often run by senior people who will not touch the project, and work is sometimes passed to a subcontractor or another country without being mentioned. Ask for names, roles and time zones, then ask to meet the lead developer.
Can you show me something you built that is closest to what I need?
Why ask it
A portfolio of unrelated marketing sites tells you nothing about whether they can build a payments flow or a scheduling engine. Ask what part of the example they actually built, since agencies sometimes show work they only maintained.
Can I speak to a client whose project went badly?
Why ask it
Every reference list is curated, and the response to this request is more informative than the reference itself. Firms that can describe a project that went wrong and what they changed afterwards are usually the more honest ones.
How do you price this, and what happens when the scope changes?
Why ask it
Fixed price, time and materials and retainer create completely different incentives once the work starts, and change requests are where budgets actually break. Ask for the hourly rate that governs changes even under a fixed price.
What is your estimate based on, and what assumptions would make it wrong?
Why ask it
An estimate with named assumptions can be checked, while a single number cannot. Asking for the assumptions also reveals whether anyone technical has looked at the requirements yet.
What do you need from me each week for this to stay on schedule?
Why ask it
Most delays are caused by the client not the developer: unanswered questions, late content, decisions nobody will make. Getting the expectation stated up front tells you the real internal cost of the project.
Who owns the code, the designs and the accounts when we're finished?
Why ask it
Ownership should transfer on payment, but some contracts license the software instead, and hosting or app store accounts are often held in the agency's name. Ask specifically who controls the domain, the repository and the cloud billing account.
Will the code be in a repository I control from day one?
Why ask it
If you cannot see the code as it is written, you cannot get a second opinion or recover if the relationship ends. Read access to your own repository from the first commit is a reasonable and revealing request.
What will you hand over, and what would another team need to pick this up?
Why ask it
Handover quality is what determines whether you are free to leave, and it means documentation, environment setup instructions and credentials rather than a zip file. Ask whether handover is included or billed separately.
How will I see progress, and how often?
Why ask it
A working demo every two weeks is a very different arrangement from a status email, and only one of them lets you catch a misunderstanding early. Ask to see the environment where you can click through what exists so far.
What testing do you do, and is it included in the price?
Why ask it
Automated tests, manual QA and browser or device coverage are frequently trimmed to hit a quoted number. Ask who is responsible for finding bugs, and what happens when you find one yourself.
What counts as a bug you fix for free, and for how long after launch?
Why ask it
The boundary between a defect and a new requirement is the most common post-launch dispute, and the warranty period varies from thirty days to a year. Get the definition and the window written into the contract.
How do you handle security, and has anything gone wrong before?
Why ask it
Ask about concrete practices such as dependency updates, secrets handling, access control and code review rather than a general assurance. If your project touches health, payment or children's data, ask what compliance work they have done specifically.
Where will the software run, and who pays for that?
Why ask it
Hosting, third-party services and API usage are often excluded from the quote and land on you as a recurring bill. Ask for an estimate of monthly running costs at your expected volume.
What does support cost after launch, and what response time does it buy?
Why ask it
Software needs maintenance whether or not you plan for it, and a retainer quoted after you are committed is expensive. Ask what happens at two in the morning when the system is down.
What technologies would you use here, and why those?
Why ask it
A reasoned answer references your requirements, your budget and how easy it will be to hire for later, while a weak one just lists what the team already knows. Be wary of an unusual framework that makes you dependent on this firm.
How many other projects will this team be running at the same time?
Why ask it
Shared developers across three clients is normal, but it directly determines your velocity and how quickly issues get attention. Ask what percentage of each named person's week is allocated to you.
What is the smallest useful version we could launch first?
Why ask it
A firm that pushes back on scope and proposes a phase one is thinking about your risk rather than the invoice. An eagerness to build everything you described is a warning sign, not enthusiasm.
How do we end this early if it isn't working?
Why ask it
Notice periods, payment for work in progress and what gets handed over on termination are all negotiable before signing and almost impossible afterwards. Asking is normal commercial practice, not distrust.
What is most likely to go wrong on this project?
Why ask it
Experienced teams will name something specific, such as an integration with an unreliable third party or a decision you have not yet made. An answer that nothing much could go wrong means they have not thought about it or are not telling you.
Choosing a Development Partner
Practical guidance for the conversation itself
Before You Start Talking to Firms
Write Down the Problem, Not the Solution
A one page description of what has to change for your business lets each firm propose an approach you can compare. Handing over a feature list built from guesswork invites everyone to quote the same thing badly.
Decide Your Budget Range Before the First Call
Firms will scope to your number, so refusing to share one wastes both sides' time and produces a quote you cannot use. A range with a hard ceiling is enough.
Get Three Quotes and Compare What Is Excluded
Wide gaps between quotes are usually about what has been left out: testing, project management, hosting, handover. Compare the exclusions line by line rather than comparing totals.
Have Someone Technical Read the Proposal
An hour of an independent engineer's time is the cheapest insurance available on a six figure build. If you have nobody, ask a firm you are not hiring to review the scope.
Get These In Writing
- Ownership of code, designs and accounts transferring to you on payment
- The hourly or daily rate that applies to change requests
- Named individuals on the team and their allocation
- The definition of a defect and the length of the warranty period
- What the handover package contains
- Who holds the domain, repository, cloud billing and app store accounts
- Notice period and what happens to work in progress on termination
- Payment tied to demonstrable milestones rather than dates
Common Pitfalls
Choosing on Price Alone
The cheapest quote usually excludes testing, project management and handover, and those reappear as change requests. Compare total cost of getting to a working, supportable system.
Paying by Calendar Rather Than by Milestone
Monthly invoices detached from deliverables remove your only real leverage. Tie payments to something you can log in and see.
Approving Designs and Never Seeing Software
Sign-off on mockups is not evidence that anything works, and gaps only appear once you click through it. Ask for a running build early even if it is ugly.
Letting the Agency Own Your Infrastructure
If the domain, hosting and repository sit in their accounts, leaving becomes a negotiation. Set up those accounts yourself and grant access.
Skipping the Post-Launch Conversation
Projects treated as finished at launch fall over within months and then cost emergency rates. Agree maintenance terms before the final invoice.