Choosing a software development agency is hard for one specific reason: from the outside, every agency looks the same. Polished website, plausible portfolio, glowing testimonials, and a sales call where the answer to everything is yes. The differences that will actually decide your project — who writes the code, how honestly they estimate, what happens when something slips — stay invisible until you are months in, when switching is expensive and painful.
The fix is not a better gut feeling. It is asking questions that force specific, checkable answers before you sign anything. Vague answers to precise questions are themselves data: a team that cannot tell you exactly who will build your product, or what you walk away with if the engagement ends early, is showing you how the whole project will go.
Full disclosure: we are a software development agency, so we have a horse in this race. But these are the twelve questions we would ask if we were the ones buying, grouped into four areas — their work, their process, the money, and what happens after launch. For each, here is why it matters and what a good answer sounds like.
Questions about their work
1. Can I see production systems you built — not screenshots?
Portfolios are easy to inflate. A screenshot can come from a template, a project that never launched, or a system the agency contributed one small module to. What you want is URLs: live software with real users that you can open in a browser today, along with a plain statement of what the agency built versus inherited.
A good answer is specific and verifiable. When prospects ask us this, we point at live builds like ImadNext, a production e-commerce platform handling checkout across international cards and four Pakistan-local payment methods, and at the rest of our portfolio. What you should be wary of is "everything is under NDA" applied to every single project. NDAs are real, but an established team can almost always show something live.
2. Who exactly will write my code?
The people in the sales call are rarely the people in your repository. Agencies staff projects after the contract is signed, and some quietly subcontract the work out entirely. That is how you end up sold by a senior architect and delivered by whoever was available.
Ask for names, roles, and seniority of the actual team — and whether any part of the work will be subcontracted. Then ask who reviews the code before it ships. A good answer names individuals and offers you a technical conversation with the lead developer before you sign. It also helps to compare what you are told in the call against how the agency presents itself publicly; the way we describe our own team and approach is on our about page, and any agency should be able to point you somewhere similar.
3. Have you built something shaped like my project?
Not identical — shaped like it. The same domain, the same scale, or the same hard part: payments, multi-tenancy, real-time updates, offline mobile sync. An agency that is excellent at marketing sites can still struggle badly with a custom web application that has roles, workflows, and integrations, because those are different disciplines wearing the same job title.
A good answer describes a comparable project and — this is the tell — what went wrong on it and how they handled it. Teams that only have success stories either have not shipped much or are not being straight with you. Every experienced team has scars, and the honest ones will show you.
Questions about process
4. How do you handle timezones and communication?
Hiring a team in a different timezone is often the economically sensible call, but the gap is either managed deliberately or it quietly ruins the project: every question waits overnight, small misunderstandings compound for days, and momentum dies.
A good answer is structural, not reassuring. Guaranteed overlap hours with your working day, a named point of contact, a written weekly update, and decisions captured in writing rather than living only in calls. Teams that work across timezones successfully will volunteer this structure without being asked, because they know async-by-default with documented decisions is the only version of remote work that holds up.
5. How often will I see working software?
Long silent stretches are where projects die. If your first real look at the product comes at month three, every wrong assumption made in month one is now load-bearing.
A good answer is a demo of working software every one to two weeks — on a staging URL you can click through, not a slide deck. Push further: will you have access to the code repository and staging environment from day one? There is no legitimate reason to say no, and the answer tells you whether the agency sees you as a partner or an audience.
6. How do you handle changes — and bad news?
Requirements will change and at least one estimate will miss. Neither is a failure; the failure is a process that cannot absorb them. Ask how change requests are handled, who controls the priority order of the backlog (it should be you), and — the revealing one — for an example of a time they told a client a deadline was slipping.
A good answer treats bad news as a routine part of the job: raised early, quantified, with options attached. An agency that has never had a difficult conversation with a client has either not done many projects or does not have those conversations until it is too late.
You learn more from how an agency answers an uncomfortable question than a comfortable one. If "what happens if we stop halfway" gets a clear, unhesitating answer, "the release is late" will get one too.
Questions about money
7. How do you price, and what does the market actually charge?
Ask whether the engagement is fixed price, time and materials, or a hybrid — and why they recommend that model for your project specifically. Fixed price only works when scope is genuinely fixed, which requires a real specification; time and materials suits products that will evolve, but you should insist on weekly demos and a monthly cap you approve.
It helps to walk in knowing broad market rates. As general observations rather than anyone's quote: agencies in the US and Western Europe commonly bill in the range of $100–200 per hour, Central and Eastern Europe roughly $40–80, and South Asia and Latin America roughly $25–60 — with seniority and process mattering far more to the outcome than geography. Project-wise, a simple MVP typically lands in the low-to-mid five figures and a full production product in the low six figures and up. Whatever numbers you hear, insist on itemized assumptions behind them. For calibration on turnaround: when a written brief lands with us, we scope it and return a quote within two to three business days — a serious agency should not need weeks to give you a number.
8. What is not included in this quote?
The exclusions list tells you more than the headline figure. Hosting and infrastructure, third-party service fees, app store accounts, data migration, a post-launch bug-fix window, ongoing maintenance — every one of these is either in the quote, or it is a surprise invoice later.
A good answer volunteers the exclusions unprompted and puts them in writing. An agency that itemizes what you are not paying for is an agency that has been through enough projects to know where the disputes come from — and wants to prevent them rather than profit from them.
9. What happens if we stop — or you do?
Projects pause for reasons that have nothing to do with the code: funding, a pivot, a relationship that is not working. Ask about the notice period, exactly what you receive on exit — code, documentation, credentials, design files — and whether anything is withheld until a final payment clears.
The good answer makes the question almost boring: the code lives in a repository you own from week one, so stopping simply means keeping everything you have paid for. If work happens in the agency's private repositories and gets "handed over" at milestones, your leverage evaporates the day the relationship sours.
Questions about after launch
10. Who owns the IP, the code, and the accounts?
On payment, you should own everything: the code, the designs, and — the part people forget — the accounts. Domain registrar, cloud hosting, app store listings, and third-party services should all be registered under your organization, with the agency added as a collaborator. Businesses regularly discover, at the worst possible moment, that their domain or production database lives in a former vendor's personal account.
A good answer has IP assignment written into the contract and sets up every account in your name from day one. Any hesitation here — talk of licensing "their framework" back to you, or accounts that must stay under their control — should end the conversation.
11. What does support look like after launch?
Launch day is the midpoint, not the finish line. Dependencies deprecate, traffic patterns change, and security patches do not apply themselves. Ask what the warranty window for bugs is, what an ongoing arrangement costs — retainer, hourly, or SLA — and what response times look like when something breaks at 2 a.m. As a planning figure, the industry rule of thumb for maintenance is 15–25% of the build cost per year.
A good answer also covers what gets handed over operationally: monitoring, alerting, and automated deployments configured as part of the build, the way a competent cloud and DevOps setup should be — so problems surface in a dashboard, not in a customer complaint.
12. Could another team take over your code tomorrow?
This is the ultimate quality question, disguised as a continuity question. Taking over cleanly requires documentation, a README that gets a new developer running locally, sensible structure, and deployment that is scripted rather than living in one person's memory. Those are exactly the properties of well-built software.
A good agency welcomes this question, because an agency confident in its code quality has no reason to build lock-in — it expects to keep your business by being good, not by being irreplaceable. Discomfort here usually means the codebase is the moat.
What the answers add up to
No agency will be flawless on all twelve, and that is fine — you are not scoring a quiz. You are listening for specificity, for comfort with uncomfortable questions, and for answers that put things in writing without being pushed. Two or three vague answers on the money and exit questions matter far more than a weak spot on demo cadence.
If you are evaluating teams right now, feel free to put all twelve questions to us. Start the conversation with a short description of what you want to build, and we will answer every one of them in writing — before you commit to anything.