How to Choose a Custom Software Development Company: 15 Questions to Ask

Choose a custom software company by testing how it thinks before you judge how confidently it sells. The strongest partner should be able to explain your problem back to you, identify uncertain assumptions, show how decisions will be validated and make delivery visible. A polished portfolio and a low headline price cannot replace those controls.

The following 15 questions are designed for founders, operations leaders, product owners and procurement teams. Use the same questions with every serious candidate and ask for evidence, not rehearsed assurances.

Before the calls: make the comparison fair

Give each supplier the same core context: business problem, users, workflows, constraints, integrations, expected first release and known unknowns. The custom software requirements checklist provides a practical structure.

Then create a weighted scorecard. Typical criteria include problem understanding, relevant experience, technical approach, delivery transparency, security, team continuity, commercial fit and post-launch support. Weighting matters because the cheapest proposal will otherwise dominate even when continuity or integration risk matters more.

1. What do you believe the real problem is?

This checks whether the supplier listened. A useful answer distinguishes the business outcome from the requested interface. It should mention affected users, current friction and the assumptions that need validation.

Be cautious if the answer simply repeats your feature list. A partner that cannot frame the problem before contracting is unlikely to challenge unnecessary scope during delivery.

2. What would you validate before committing to a detailed build plan?

Good teams make uncertainty visible. They may propose stakeholder interviews, process mapping, data sampling, integration checks, prototypes or a technical spike. The exact activities vary, but the principle is consistent: expensive assumptions should be tested early.

Ask what tangible outputs discovery produces and who owns them. Our guide to software discovery workshop deliverables describes useful artefacts and common red flags.

3. Which similar problems have you solved—and what is genuinely comparable?

Industry labels can mislead. A supplier may not have built your exact product but may have strong experience with the same hard parts: role-based access, multi-step casework, payments, document workflows, multi-tenant data or legacy integration.

Ask the candidate to separate public evidence from confidential work and to avoid invented outcome claims. Review live work where available. AUZtec’s project catalogue, for example, documents the scope and technologies behind Calm Child Therapy and the CertGuru platform without claiming unverified commercial results.

4. Who will actually work on the project?

Meet the people who will lead analysis, architecture and delivery—not only the salesperson. Ask how much of the work is performed by the named team, where specialist support comes from and how continuity is maintained if someone becomes unavailable.

Clarify:

• who owns day-to-day communication;
• who can make architecture decisions;
• who reviews code and tests releases;
• whether subcontractors are used;
• time-zone overlap and response expectations; and
• how knowledge is documented.

Team shape should fit the risk. A small integration may not need a large programme structure; a platform handling sensitive records should not depend on one undocumented developer.

5. How will we see progress?

Ask for the evidence available during delivery: prioritised backlog, acceptance criteria, prototypes, working demonstrations, test results, release notes and risk logs. Progress should be visible as usable slices, not percentages in a status report.

Also ask how frequently stakeholders must review work. Client feedback is a project dependency. If your team cannot make decisions for three weeks, no agile ceremony can remove the delay.

6. How do you control scope and change?

Software understanding improves during delivery. The question is not whether change happens but how it is evaluated. A credible process records the request, reason, effect on outcomes, delivery impact and decision owner.

For fixed scope, ask how ambiguity and acceptance are handled. For flexible delivery, ask how budget exposure and priorities are controlled. The comparison in Fixed Price vs Time and Materials helps match the contract to the uncertainty.

7. How will architecture decisions be documented?

You do not need a stack lecture. You need to know how material choices will be made and preserved. Ask for short decision records covering the context, options, trade-offs and consequences of choices such as tenant isolation, identity, hosting, data ownership and integration patterns.

Architecture should reflect expected load, team capability, recovery needs and business change—not fashion. Challenge claims that a particular framework automatically makes a system scalable or secure.

8. What is your security approach from design to release?

“We follow best practice” is not evidence. Ask how the team handles threat modelling, permissions, secrets, dependency updates, input validation, logging, code review and vulnerability response. Where APIs expose customer or operational data, the OWASP API Security Top 10 is a useful shared reference.

Confirm who is responsible for cloud configuration, backups, access reviews and incident communication after launch. No supplier can responsibly guarantee that software will never be breached; it can explain the controls, tests and response process it will implement.

9. How do you test the product?

Look for layers rather than one final test phase. The team should be able to describe automated checks, integration testing, permission testing, accessibility review, performance testing where relevant and structured user acceptance.

Ask how defects are prioritised, whether failed tests block release and what evidence accompanies a deployment. If accessibility matters—as it should for most public and staff systems—ask how the work will be assessed against WCAG 2.2.

10. How will data migration be rehearsed and verified?

If existing records are involved, request a migration plan separate from feature development. It should cover profiling, cleaning, mapping, transformation, trial runs, reconciliation, cut-over and rollback.

Ask who signs off record counts, relationships, attachments and critical fields. A successful import message is not the same as verified business data.

11. How do you approach third-party integrations?

The supplier should check API availability, authentication, rate limits, webhooks, sandbox access and commercial dependencies before treating an integration as routine. Ask how retries, idempotency, duplicate events and partial failures will be handled.

OWASP’s guidance on unsafe consumption of APIs is a useful reminder that data from a trusted partner still needs validation. For a deeper procurement checklist, read API Integration Project Checklist.

12. What will we own and receive?

Clarify intellectual-property terms with appropriate legal advice before signing. Operationally, ask whether you will receive source code, design files, infrastructure configuration, database documentation, deployment instructions, credentials, test assets and third-party account ownership.

Confirm where the repository and cloud accounts will live. Avoid arrangements in which the business cannot access its own production environment or release history.

13. What happens at launch?

Launch is a controlled transition, not a calendar event. Ask about training, support coverage, monitoring, backup verification, rollback conditions, data cut-over, change communication and the first post-launch review.

A strong answer identifies the people who can make a go/no-go decision and the evidence they will use. It should also explain what is deliberately deferred rather than quietly shipping an incomplete critical path.

14. How is support structured after the warranty period?

Ask what counts as a defect, what becomes a change request, how severity is assessed and what response commitments apply. Understand whether maintenance includes dependency updates, security patches, monitoring review and small improvements or only reactive fixes.

Support should match business criticality. A marketing tool and a case-management platform do not need identical coverage.

15. Which parts of our request would you challenge?

This is often the most revealing question. A thoughtful partner may challenge the proposed first release, an unnecessary mobile app, a risky integration sequence or an assumption that automation should remove every human decision.

Agreement is comfortable, but responsible delivery requires constructive disagreement. The supplier should explain the evidence behind the challenge and offer a route to test the alternative.

Red flags during selection

Pause when a candidate:

• gives a precise quote before understanding users, data or integrations;
• promises every outcome without stating assumptions;
• cannot introduce the delivery team;
• treats security and testing as final phases;
• will not show work until near completion;
• uses proprietary lock-in without a clear business reason;
• dismisses documentation as unnecessary;
• cannot explain production ownership or support; or
• pressures you to select technology before the problem is understood.

One red flag may have a reasonable explanation. A pattern indicates delivery risk.

A practical final scorecard

Score each supplier from one to five for problem understanding, discovery, relevant evidence, team, communication, architecture, security, quality, data/integration competence, commercial clarity and support. Add notes and evidence beside every score. Then hold a risk review separate from the enthusiasm of the presentation.

Price belongs in the comparison, but compare like with like: included scope, assumptions, client responsibilities, environments, migration, launch and support. A proposal that omits hard work is not automatically efficient.

AUZtec Innovations provides turnkey software delivery across design, engineering, integration, deployment and ongoing improvement. If you are comparing a shortlist, share the same brief with us and ask the difficult questions. A clear explanation of trade-offs is the first useful output of the relationship.