Choosing a software developer is strange, because you are buying something that does not exist yet from people you have just met. The websites all say the same things. The portfolios all look polished. The proposals all promise partnership and innovation. Somewhere in that identical crowd are teams who will quietly ship you something excellent, and teams who will burn your budget and hand you excuses.
You cannot tell them apart by their marketing. You can tell them apart by how they answer questions. Here are the ones we would ask if we were hiring, and what the answers reveal.
Ask what they would not build
Put your idea in front of them and ask what parts of it they would push back on. A good developer always has an answer, because every idea has parts that should not survive contact with reality - a feature nobody will use, a phase that should wait, an app that should be a website.
If they love everything about your idea, they are not evaluating it. They are pricing it. Enthusiasm without challenge is a sales posture, and it gets expensive later, because the questions that should have been asked in the first meeting arrive as change requests instead.
Ask who owns the code
The answer should be one word: you. Once you have paid, the code, the design and the data belong to your business, and leaving should be easy - full handover, no ransom.
You would be surprised how many agreements say otherwise. Licences instead of ownership. Code that stays on the agency's accounts. Exit fees. Hosting you cannot take elsewhere. None of this is engineering - it is lock-in, and it exists so that leaving hurts more than staying. Read the ownership clause before you sign, not after you fall out.
Ask to talk to an engineer
Not the account manager. The person who will actually build your software. In a healthy company this is easy to arrange, because the engineers talk to clients as a matter of course. In an unhealthy one there are layers between you and the people doing the work, and every layer costs you accuracy - your requirements arrive at the keyboard third-hand, like a game of telephone with a day rate.
While you are talking to them, notice whether they ask about your business or only about features. Good engineers want to know how the work actually happens today, including the messy exceptions, because that is where software succeeds or fails.
Ask what happens when it goes wrong
Every project hits something unexpected. The difference between developers is not whether problems happen but what the arrangement is when they do. Ask three specifics: what happens if the scope changes mid-build, what the warranty is after launch, and what their honest response time looks like when something breaks on a Tuesday afternoon.
Beware of anyone who answers the last one with guarantees that sound like a hotline. Small teams do not run 24/7 call centres, and the honest ones say so. A written, realistic support arrangement beats an impressive one that quietly is not true.
Ask what they run themselves
There is a difference between building software and running it. A developer who operates their own products - things with real users, real support requests and real 2am problems - has learned lessons that cannot be learned any other way. They know what happens after launch because they live there.
It is not disqualifying if an agency has no products of its own. But when they do, and those products are alive and used, it tells you their engineering survives contact with the public - which is exactly what yours will need to do.
Ask for the quote in writing, fixed, against a scope
A fixed price against a written scope protects both sides. It forces the detailed questions before money moves, and it makes changes visible - if the scope grows, the difference is re-quoted in the open rather than absorbed into a fog of billable hours.
Day rates have their place for genuinely open-ended work. But "we will bill you for time" on a defined build transfers all the risk to you, and estimates that cannot be committed to are usually estimates that were never really made.
The pattern in all of this
Every question above is really the same question: does this developer tell you things you did not want to hear? The one who says your app should be a website, that phase two should wait, that they will not promise a ranking or a 24/7 hotline - that one is spending their credibility on your outcome.
The polished proposal that agrees with everything is not a good sign. It is the sound of someone who has decided your budget is the requirement.
Written by Graeyna
The team that designs, builds and runs the software we write about. Engineers, not marketers.