Hiring a software team is one of the most consequential purchases most small and mid-sized businesses will ever make. A good team turns a stack of workflows and spreadsheets into a system your people trust; a bad one leaves you with a half-built app, an unhappy team, and a bill you can't explain to your board. The difference usually shows up in the very first conversation. If you know the right questions to ask software developers before you sign anything, you learn more in a 45-minute call than you would from a ten-page proposal.
At Vadimages we run our own discovery calls this way. We prefer clients who arrive prepared, because prepared clients ask sharper questions and end up with better software. This guide is the exact list we hand to founders and operations leaders in Vancouver, Portland, Seattle, and across the country when they tell us they are about to interview agencies or freelancers. Fifteen questions, grouped in four buckets: fit and track record, process and delivery, people and communication, and money and risk. Ask every one of them, take notes, and compare answers side by side. The pattern will show you who to trust.
Before you begin, remember one thing. You are not looking for the smartest engineer in the room. You are looking for a team that understands your business, will tell you the truth, and can ship working software at a price you can predict. Every question below is designed to test one of those three things.
Fit and track record — do they actually understand your world?
1. Have you built something like this before, and for a similar type of business?
"Similar" does not mean identical. It means the shape of the problem is familiar: a distribution company with route sheets, a healthcare practice with intake forms, a manufacturer with a shop floor. Ask them to walk you through two or three projects that share the shape of yours. Watch for specifics — the number of users, the workflow they replaced, what the customer measured after launch. Vague answers here almost always predict vague delivery later.
2. What did that project actually change for the business?
The best developers talk about outcomes, not features. "We shipped a portal with fourteen screens" is a feature answer. "We cut order-entry time from nine minutes to ninety seconds and stopped losing four orders a week" is an outcome answer. If a team cannot describe outcomes for past work, they will not know how to design for yours.
3. Which industries do you serve most often?
You do not need an agency that only builds for your niche, but you do want one that has stood on a shop floor, sat in a doctor's office, or ridden a delivery truck. Our own industries page shows where we see the same problems every week — that pattern-matching is worth money when the project starts, because we ask better questions on day one.
4. Can I talk to two past clients — including one where things went sideways?
This is the one question most buyers forget. Everyone has happy references. What you want is the reference where scope changed mid-project, or a hard bug shipped, or the launch slipped. How the team behaved in that moment tells you exactly how they will behave with you. If a vendor cannot produce a single "hard project" reference, either they haven't done enough work or they haven't been honest about what happened. Both are red flags.
Process and delivery — will this actually ship?
5. What does the first thirty days look like?
The right answer includes: a kickoff, one or two rounds of discovery, a working prototype or clickable design, and at least one thing in code that you can look at. If the first month is nothing but meetings and documents, you are paying for planning theater. If the first month promises to be "heads down building," you are paying to skip the thinking that prevents rework. You want both — discovery that ends in something real, fast.
6. How do you break the work into pieces, and how often do I see progress?
Weekly demos are the honest floor. Every one to two weeks, a working slice of the product should be in your hands or on a link you can share with your team. Ask what happens if you disagree with what they built that sprint. A team that welcomes that conversation is a team that will end up with software you actually want. See our own how-we-work page for the cadence we run with clients — the shape is fairly standard across good shops.
7. Who owns the code, the accounts, and the data?
The answer must be "you." Your repository lives in your GitHub or GitLab organization. Your cloud accounts (AWS, GCP, Azure, Cloudflare, Vercel) are yours, billed to you, with the vendor added as a collaborator you can remove in one click. Your database, your backups, and your customer data are yours from day one. Any answer that starts with "well, we host it for you on our platform…" needs a very good follow-up, because it usually means you cannot leave without rebuilding.
8. What is your testing and code review process?
You are not looking for a lecture on unit tests. You want a short, real answer: every change is reviewed by another engineer before it merges, there is automated testing for the parts of the app that would hurt if they broke, and there is a way to catch bugs before the customer does. Ask them to show you a real pull request from a recent project (with names redacted if needed). The team's habits are visible in a two-minute scroll.
People, communication, and ownership
9. Who exactly will work on my project, and are they employees or contractors?
Get names, roles, and rough time allocation. "A senior engineer, a designer, and a project lead, part-time on your account, plus a QA person as needed" is a real answer. "We'll assign our best people" is not. Ask whether the team is in-house or outsourced. Neither is automatically better, but the answer changes how communication and quality work. If key roles are subcontracted, ask how long those subcontractors have worked with the agency, and what happens if one leaves mid-project.
10. What time zone are they in, and how do we actually talk?
This matters more than it sounds. A team seven hours ahead of you can be a superpower if the workflow is set up for asynchronous updates and a daily standup that catches both time zones. It becomes a nightmare if every question waits a day. Nail down: which channels (Slack, email, a project tool), how fast a response is expected, and whether you get a real human on video every week. For US SMBs we've found the sweet spot is a US-hours project lead with the rest of the team wherever they are best.
11. Who is the single accountable person if something goes wrong?
Every project needs one throat to choke and one hand to shake. That person answers emails within a business day, runs the weekly demo, and owns the schedule. Without a single accountable person, escalation goes in circles and nothing gets fixed on the first try. Ask for their name and their calendar. Meet them before you sign.
12. What happens when we disagree?
You will disagree. About scope, about a design decision, about whether a bug is a bug. A serious vendor has a boring, obvious answer here: we surface it early in writing, we talk about it on the next call, we make a decision, we log it, and we move on. If the answer is "we're really easy to work with, there won't be many disagreements," expect the opposite.
Money, risk, and what happens after launch
13. How do you price, and can I see a real budget on paper?
There is no perfect model. Fixed price is comforting until the scope changes. Time and materials is honest until it runs away. Most healthy engagements use a hybrid: a fixed price for a well-scoped first phase, then a monthly retainer or sprint-based rate for the work after that. What you should insist on is a written budget with real numbers, real assumptions, and a change-order process you understand. Our own approach on the pricing page starts real custom-software work at $5,000 and up, and we write the assumptions down so the client can push back on them. Any vendor should do the same.
14. What is not included, and what could push the number up?
Ask this question exactly the way it's written. Every serious estimate has assumptions — number of integrations, number of user roles, whether third-party API costs are billed through or passed to you, how many rounds of feedback are included per screen. The answer to "what would blow this budget?" tells you whether the vendor has actually thought about your project or is just quoting a round number. See our full custom software and solutions pages for the way we scope the pieces most clients forget.
15. What happens the day after launch — and the day after that?
The last question is the most important one. Ask what support looks like in month one, month three, and month twelve. Who fixes bugs, who runs updates, who keeps the dependencies current, who is on call if the site goes down at 2 a.m. Ask what it costs. Ask what happens if you decide to move the code to a different team next year — will they help transition, and what does that look like on paper. Software is not a purchase; it is an ongoing relationship with a system that runs part of your business. The vendors who take month thirteen as seriously as month one are the ones worth hiring.
How to use these questions in a real interview
Send the list ahead of the call. Serious vendors will show up prepared and their answers will be sharper. Ask every question, even the ones that feel obvious — the way a team answers "who owns the code" tells you almost as much as the answer itself. Take notes in a shared document so your team can compare vendors later. And after each interview, force yourself to write one sentence answering, "would I want this person on a call with my customer?" That single sentence is worth more than any scoring rubric.
Two more small tips. First, do not let price be the first filter. A $12,000 project done well is dramatically cheaper than a $6,000 project that has to be rebuilt in eighteen months. Second, trust your gut on communication. If it feels hard to get a straight answer in the sales cycle, it will feel impossible during a production incident.
If you would like to run these questions against us, that is exactly what our first call is for. Book a discovery conversation on the contact page — bring the list, ask us all fifteen, and take notes. If our answers do not clear the bar, at least you will have a much sharper checklist for whichever team you hire next. Either way, you win.