Most people evaluating a development firm ask about price and portfolio. Both matter less than how the firm behaves when a project gets difficult — and these questions surface that before you find out the expensive way.
Ownership and exit
1. Who owns the code, and where does it live? You should own it, and it should sit in a repository in your organization's account from day one — not moved across at the end, which is a promise rather than a fact.
2. If we stopped working together tomorrow, what would we have? Listen for: repository access, deployment documentation, environment configuration, and credentials. If the honest answer is "you would need us," that is the risk you are buying.
3. What third-party services will this depend on, and whose accounts are they in? Hosting, email delivery, error monitoring, payment processing. These should be your accounts with your billing, not theirs.
How the work actually happens
4. Who specifically will write this? Not "our team." Names, seniority, and how much of their week you get. The gap between the people in the pitch and the people on the keyboard is a classic disappointment.
5. How often will we see working software? Every two weeks at minimum, running, not screenshots. Nothing exposes a drifting project faster, and a firm that resists this is telling you something.
6. What does your testing consist of? Automated tests for the important logic, plus a documented manual pass before release. "We test thoroughly" is not an answer; ask what is automated and what breaks the build.
7. How do you handle a change request mid-project? There should be a written process with a cost and a schedule impact. Firms that absorb every change quietly are either padding heavily or heading for a difficult conversation later.
After launch
8. What is the warranty period, and what does it cover? Thirty to ninety days is typical. Get the distinction between a defect (their cost) and an enhancement (yours) in writing, because you will be arguing about it otherwise.
9. What does ongoing support cost, and what does it include? Dependency patching, hosting management, and response times. Budget 15–20% of build cost annually; a firm that says none is needed is not being straight with you.
10. Who do we call at 2am if it is down? And is that included, or extra? For anything the business depends on, this needs an actual answer before launch, not after the first outage.
The two that reveal most
11. Tell me about a project that went badly. Everyone has one. You are listening for a specific story with an honest account of their own part in it. A firm that has never had a difficult project has either not done many or is not being candid — and neither is reassuring.
12. What about our project worries you? A good answer is immediate and specific: the data looks messy, the integration target has no API, the timeline is tight for the scope. A firm that says nothing worries them has not thought about your project or is telling you what closes the deal.
Two things to do beyond the questions
Ask for references from a project that ended more than a year ago, then ask that reference what maintenance has been like. Recent references are still in the honeymoon; older ones know how the code aged.
And start with a small paid engagement — a discovery phase, or one contained deliverable. You learn more about a firm in three weeks of real work than in three months of proposals, and if it goes badly you have lost a phase rather than a project.
What that discovery should produce, and what the whole thing should cost, is covered in our custom software pricing guide. Our own application development work is structured this way deliberately, including the handover documentation.
Comparing proposals? We are happy to look at one, even if it is not ours.