Choosing a company to build your software is hard for a simple reason: you are buying something you cannot inspect in advance. Portfolios all look good and every proposal promises quality. The differences show up months later. A set of direct questions asked before signing reveals most of them early.
Who owns what?
Ask this first and get it in writing. You should own the source code, and it should live in a repository under your account from the first day, not handed over at the end. The same goes for cloud accounts, domains, and accounts with third-party services. If these are registered to the vendor, leaving them becomes a negotiation.
Ask also whether they build on a proprietary framework or platform of their own. If so, find out whether another team could maintain the result without it.
Who will actually do the work?
The people in the sales meeting are often not the people who write the code. Ask to meet the engineers who would be assigned, how senior they are, and whether any part is subcontracted. Ask how you will communicate with them: directly, or only through an account manager. Direct access to the people building the product shortens every decision.
How do you estimate?
A firm price given after one short call, before anyone has understood the problem, is a guess with a margin added. A serious partner asks many questions first, states assumptions, and explains what would change the figure.
Ask what happens when the scope changes, because it will. Ask what happens if their estimate turns out wrong. The answers show whether the risk has been thought about or only priced in.
How do you keep quality up?
- Is every change reviewed by a second engineer?
- Are there automated tests, and do they run on every change?
- How is the software deployed, and how is a bad release rolled back?
- How are security updates handled?
Listen for specific answers. "We have a strong focus on quality" is not one.
How will I see progress?
You should see working software regularly, in an environment you can open yourself, not slides describing progress. Ask how often that happens and whether you can try each increment. Problems found in week three are cheap. Problems found in month five are not.
What happens after launch?
Ask who operates the system, who is called when it fails, and what support costs. Check whether ongoing support is optional or a required retainer. Ask what monitoring and backups are included in the build.
What if we part ways?
Ask how a handover to your own team or another company would work, and what documentation exists to make it possible. A good partner answers this without discomfort. Reluctance here is informative.
Can you show relevant work, and what went wrong?
Ask for work similar to yours and to speak with a past client. For a newer company, ask to see real code or a running system and to talk through the technical decisions. Then ask about a project that went badly and what they did. Everyone has one. People who can describe it clearly have usually learned from it.
Warning signs
- Agreement with everything you say and no challenge to your requirements.
- A fixed price without questions.
- Vague answers about ownership.
- No mention of testing, monitoring or backups unless you raise them.
- Pressure to sign quickly.
- A price far below the others, with no explanation of how.
Start small
If the answers are good, begin with a short paid piece of work: a discovery phase, a technical plan, or one small feature. Two or three weeks of real collaboration tell you more than any proposal, and they limit the cost of a wrong choice.
Summary
Settle ownership, meet the engineers, understand how the estimate was made, check the quality practices and ask how you would leave. These are the questions we expect to be asked about our own custom software development service, and we answer them in writing. Send us yours.