Technical due diligence when hiring a software agency

Direct answer

Check how an agency works, not how it pitches. Proposals, case-study pages and confident calls all describe intent. Working practice shows up in artefacts: a repository, a test run, a deployment description, a document written for a stranger. The most reliable due diligence is to ask to see or walk through those artefacts, on a project the agency is free to share, and to score what you find against criteria you wrote before the meeting. This page gives you those criteria. For the broader selection process see how to choose a software development agency; for the consulting-side equivalent see questions to ask an automation consultant.

One note on scope: this page is about what you can check as a buyer. It is not an offer of any audit service from LATYNEX, and it does not replace independent technical advice if the project is large or the stakes are high.

1. A sample repository walkthrough

Ask the agency to share its screen and walk you through a repository from a past project, or a sanitised sample if client work is confidential. You are not reviewing the code line by line. You are watching how easily they navigate it and how they talk about it.

• Can they explain the folder layout in plain words, and does it look organised or accumulated?
• Is the history readable: changes grouped into understandable steps with messages that say why, rather than a single lump or vague labels?
• Is there a readme that tells a newcomer how to run the project?
• Do they point out weaknesses unprompted? An agency that can name what it would do differently is usually more trustworthy than one that shows only polish

2. Architecture questions

You do not need to judge the design. You need to hear whether a design exists and whether the reasons are business reasons. Ask them to describe, for a past project, the main parts of the system and why they were separated that way.

• What are the main components, and what does each one own?
• Where does the data live and who can reach it?
• What did they choose not to build, and why?
• Which decisions would be expensive to change later, and how did they flag that to the client at the time?
• How would the design cope if usage grew or a new user type appeared?

3. Testing and continuous integration

Ask what is tested and how the tests run. A useful answer names the kinds of checks that exist, when they run and what happens when one fails. Ask to see a recent run, or at least a description of it. Be cautious of answers that reduce to 'the developers test as they go' with nothing recorded, and equally of claims that everything is covered, which is rarely true of any project.

• Do checks run automatically when code changes, or only when someone remembers?
• Who is blocked when a check fails, and is the change held back?
• How do they test the parts that are hard to automate, such as screens and integrations with other systems?
• How is a bug that reached users turned into a check so it does not return?

4. Deployment and rollback

Ask them to describe what happens between an approved change and a live change. You are listening for a repeatable routine, a separate place to try changes before customers see them, and a stated way back if a release goes wrong. Related material: staging vs production environments and safe software release and rollback process.

• Is deployment a scripted, repeatable routine, or a person doing manual steps from memory?
• Is there a staging environment, and is it kept separate from live data?
• What is the rollback route, and has it ever been used?
• Who decides when to release, and who is told?

5. Secrets and access hygiene

Passwords, keys and tokens are where careless practice hurts most. Ask where they are kept, who can see them and how they are handled when someone leaves the project. The right answers involve a dedicated place for secrets, separate credentials per environment, named accounts instead of shared logins, and access that is removed at the end. Ask, too, whose accounts the hosting and code repositories will sit in. If the honest answer is the agency's, ask how ownership moves to you; see who owns the code and accounts after a custom build.

6. A documentation sample

Ask for one piece of real documentation written for a client: a handover note, a runbook or a system overview. Read it as a stranger would. Could a competent person unfamiliar with the project understand how to run it and where things are? Documentation that exists only as a promise in a proposal is a warning sign. So is documentation that is impressive but describes a system that no longer matches the code.

7. Who actually does the work

Many proposals are presented by one group and built by another. That is not automatically a problem, but you should know. Ask who will write the code, who will review it, who will be your day-to-day contact and what happens if one of them is unavailable. Ask whether subcontractors are used, in which parts and under whose responsibility. Ask to speak to the person who would lead the technical work, not only the person selling it.

• Named people for each role, not just a team name
• A description of how work is reviewed before it is accepted
• A clear answer on subcontracting and where work is done
• What the agency does when a person leaves mid-project

8. Scoring what you found

Write the scoring before the meetings, so the most polished presenter does not set the standard. Use the same short scale for every agency and record the evidence beside each score. Weight the rows by what matters to your project: a system holding sensitive data may weigh access hygiene most, a system that will change often may weigh testing and deployment.

• Evidence shown: you saw the artefact yourself
• Described only: they explained it but showed nothing
• Evasive or absent: no answer, or an answer that changed when you probed
• Keep a note of anything you could not judge and would want independent technical advice on

How LATYNEX approaches this

We think you should ask these questions of us as well, and we would rather answer them in a scoping conversation than have you guess. LATYNEX is a remote, English-language vendor, and we agree one scope and one price in writing before work starts. The scoring above is yours to use on any supplier; we do not offer certifications or audits of other suppliers' work. See Web Application Development for how we deliver.