A polished proposal can hide weak engineering. The right questions expose how the team will behave after the contract is signed.
Choosing a software partner is difficult because the most important qualities are invisible during a sales presentation. Almost every agency can show attractive mockups, promise agile delivery, and place modern technologies in a slide deck.
What matters is how the team makes decisions when requirements change, production fails, or the first estimate proves wrong.
These five questions reveal much more than a portfolio alone.
1. Who will actually write the code?
Ask for the roles, seniority, location, and expected allocation of the people assigned to your project. Then ask whether those people are employees, long-term contractors, or a team selected after the sale.
You do not need every engineer's name on day one, but you should understand the delivery model. A senior architect in the pitch has little value if the implementation is passed to an unknown team with no product context.
A good answer includes: clear ownership, realistic availability, and direct access to technical decision-makers.
2. How will you prove progress every week?
Status reports are not proof. Ask what you will be able to see and test during delivery.
Healthy projects produce working increments: a staging environment, reviewable designs, pull requests, automated tests, release notes, and a visible backlog. You should not discover the real state of the product during a large reveal near the deadline.
A good answer includes: frequent demonstrations, access to the work, and an explicit definition of done.
3. What happens when an assumption is wrong?
Every meaningful software project contains uncertainty. The dangerous agency is not the one that identifies uncertainty; it is the one that pretends none exists.
Ask how scope, cost, and deadlines change when research reveals a harder integration or users reject an early workflow. The process should protect both parties from silent overruns and rushed compromises.
A good answer includes: documented assumptions, short discovery cycles, written change decisions, and options with clear tradeoffs.
4. How do you prevent us from becoming dependent on you?
Your company should control its product. Confirm who owns the source code, designs, infrastructure accounts, domains, data, documentation, and deployment credentials.
Ask whether another competent team could operate the system using the repository and documentation you receive. Vendor lock-in is sometimes hidden inside private accounts, undocumented deployment steps, or proprietary components that were never discussed.
A good answer includes: client-owned accounts, documented environments, transferable code, and an orderly handover plan.
5. Show us how you handle production failure
Do not ask whether bugs happen. They do. Ask for the incident process.
Who receives alerts? What is the expected response time? How are backups verified? How are security patches applied? What does the agency communicate during an outage, and what analysis follows afterward?
A good answer includes: monitoring, named responsibility, recovery procedures, tested backups, and a blameless post-incident review.
The final test
Pay attention to whether the agency welcomes detailed questions. Strong engineering teams are comfortable discussing constraints, failure modes, and tradeoffs. Weak teams repeatedly redirect the conversation toward visual polish, vague guarantees, or urgency to sign.
A $50k contract should purchase more than code. It should purchase a transparent process, accountable technical judgment, and a product your company can continue to own.
Choose the team whose answers remain convincing after the sales presentation ends.