Questions to ask before hiring a software development company
A development contract is signed once, but what it says (and what it leaves out) stays with you for years. That is why the questions you ask before hiring a software development company are not a formality: they are the only part of the process where you still have all the leverage. After you sign, every answer you didn't ask for has a price.
This article collects the questions worth asking any vendor, whoever they are, grouped by the risk they cover. For each group we describe what a good answer sounds like and what an answer that should worry you sounds like. You don't need to know how to code to tell them apart: you need to listen for whether the answer is concrete or drifts off topic.
One clarification first: there is another list of questions, just as important, that isn't for the vendor but for you, about your own business. We cover it in what to ask before requesting a software quote. Here we focus on what to ask the people who are going to build it.
Ownership: who owns what you pay for
The questions. Whose account will hold the code repository, and from when? Whose name will the cloud, the domain and the services the application relies on be under? What does the contract say about the rights to the code?
Good answer: "in your account from day one, and you give us access." The key part is "from day one": not when the project ends, not when the last invoice is paid. Bad answer: "we'll hand everything over at the end of the project." Until then, your business depends on the relationship going well. We explain it in detail in who owns the code of your software.
Price and scope changes: who pays when something changes
The questions. If the price is fixed, what exactly happens when something comes up that wasn't planned? If you get the estimate wrong, who pays for those hours? Can I pause or slow down without a penalty?
Good answer: a concrete explanation of how a change is handled (it gets estimated, approved in writing and added) and who absorbs the vendor's estimation errors. Scope changes happen in every project, and a good vendor takes that for granted instead of pretending it won't happen. Bad answer: "the price is fixed, don't worry." A fixed price with no clear mechanism for changes only postpones the argument to the day the first change shows up, which will be soon.
Who works on your project
The questions. Which roles will work on it, and how experienced are they? Who will be my point of contact, and will they be in the meetings from start to finish? Is any part subcontracted to another company?
Good answer: names, roles and a technical person who stays with you for the whole project. Bad answer: an account manager who relays your decisions to a team you will never meet. That isn't necessarily bad faith, but every middleman is a place where information gets lost, and in software lost information turns into rework.
Deliveries: what you will see, and when
The questions. How often will I see something working? Will I be able to test it myself, with my own data, or only watch a demo? What exactly do I get in the first delivery?
Good answer: a fixed rhythm, for example every two weeks, with software you can actually use and a first delivery described precisely. Bad answer: "we'll show you when it's done." What you can test can't be dressed up; what only lives in progress reports can. If you want more signals like this one, we collected them in how to choose a development team without being technical.
Quality and failures: what happens when something breaks
The questions. Who tests what you deliver before it reaches me? What warranty do you give in writing, and for how long? If the system goes down on a Saturday night, who finds out and what happens next?
Good answer: testing done by someone other than the person who wrote the code, a written warranty with a specific term and a plan for incidents, even a simple one. Bad answer: "our code doesn't break," or a warranty that doesn't appear in any document. All software fails at some point; the difference is how it's handled, which is exactly what we cover in how you handle failures is the difference.
Exit: what you leave with if the relationship ends
The questions. If tomorrow I want to continue with another team, what exactly do you hand over? What documentation gets written, and when: during development or on the last day? Is there any part of the system that won't work without you?
Good answer: a concrete list (code, access, documentation, a handover session) and the idea that documentation is written while the system is built. Bad answer: hesitation, vague answers or a proprietary piece of the vendor's without which your application won't start. In part of the industry, making it more expensive to leave than to stay is the business model itself, as we explain in cheap development, expensive maintenance.
Maintenance: what is mandatory and what isn't
The questions. Is there a mandatory maintenance fee? What does it include and what doesn't it? Is there a minimum term? Can another team, or my own team, take it over if I prefer?
Good answer: optional maintenance, with what it includes in writing and no minimum term. Bad answer: a mandatory fee that can't be broken down. It may be legitimate, but you need to know you're buying it before you sign, not after.
Data: where it lives and who is responsible for it
The questions. Where will my customers' data be hosted? Is it encrypted and backed up? Do we sign a data processing agreement before we start?
Good answer: a specific location, encryption, regular backups and the data processing agreement as a first step, not as a favor. Bad answer: "we'll figure that out later." If the software handles personal data, this part isn't optional, and a serious vendor brings it up before you do.
The red flags
Beyond each individual answer, there are patterns worth recognizing. The vendor asks no questions about your business before quoting a price. The total arrives in four lines with no breakdown: that's the lesson of the locksmith's quote. They promise a total timeline before they understand the scope. They get uncomfortable with these questions or ask you to just trust them. None of these signals proves bad faith on its own, but several together say a lot about how the relationship will go once problems show up.
How we answer them
So this doesn't stay theoretical: the code, the repository and the cloud are in your name from day one. We work with a published rate and deliveries every two weeks that you can test, with the same technical person in every meeting. The warranty is six months and in writing, maintenance is optional with no minimum term, and the documentation is written as we build, so another team can take over if you ever decide to.
That's how we approach any custom software development project, and we're glad when clients ask us these same questions, and ask everyone else too. If you want to ask us in person, tell us about your project and we'll answer them in the first conversation.