How to hire a software development agency: a checklist for small businesses

Hiring a software agency is one of the larger purchases a small business or early-stage founder makes, and one of the hardest to judge. Proposals look similar, everyone says they are "agile", and the real differences only appear months later: who owns the code, whether the app is secure and accessible, and whether you can switch suppliers without starting again.

This guide is a practical checklist for founders and managers commissioning a website, web app or mobile app. It covers what to prepare before you talk to agencies, how to compare proposals, the contract clauses that protect you, the technical standards worth naming, and how to keep control of accounts and code during the project. It does not recommend specific agencies; it gives you the questions that separate a good fit from an expensive lesson.

Before you contact anyone: write a one-page brief

Agencies price uncertainty. A vague request gets either a high quote or a low one that grows later. One page is enough if it answers these questions:

• The problem: what users or staff cannot do today, and how you will know the project worked (for example, "customers can book and pay online without calling us").
• Users and scale: who will use it, roughly how many, on which devices, and in which languages.
• Must-haves versus nice-to-haves: a short list of each. Agencies can then propose a first release that fits your budget.
• Integrations: payment gateway, accounting software, CRM, email marketing, existing website or database.
• Data: whether you will collect personal data, payments or health information, which drives security and legal work.
• Budget range and deadline: a range is better than "as cheap as possible"; it lets agencies propose honestly.
• Who decides: the one person on your side who can approve scope and answer questions quickly.

Shortlisting: what to ask in the first call

Talk to three to five agencies. In the first call, listen for how they handle uncertainty rather than how confident they sound. Useful questions:

1. Who will actually work on my project? Ask for the roles and seniority of the team, and whether any work is subcontracted.
2. Can I see similar work and speak to a past client? A reference call is more useful than a portfolio page.
3. How do you estimate, and what happens when scope changes? A good answer describes a change-request process with written estimates before work starts.
4. How often will I see working software? Look for a demo on a staging environment every one or two weeks, not only status reports.
5. What do you hand over at the end? Source code, infrastructure access, documentation and credentials, in your own accounts.
6. What happens after launch? Bug-fix warranty, support hours, response times and the cost of ongoing maintenance.

Comparing proposals fairly

Put the proposals side by side in a table. Price differences usually come from different assumptions, so make the assumptions visible.

Compare	What a strong proposal shows	Warning sign
Scope	Features listed with what is in and out of the first release	"Full app as discussed"
Pricing model	Fixed price for a defined scope, or time and materials with a capped budget and weekly reporting	Open-ended hourly billing with no cap or reporting
Milestones	Payments tied to accepted deliverables you can test	Most of the fee paid upfront
Team	Named roles, including testing and design	No mention of testing
Technology	Mainstream, well-supported frameworks with a reason for the choice	A proprietary platform only this agency can maintain
Security and accessibility	Named standards and how they are checked	"Secure and responsive" with no detail
Handover	Code, documentation, credentials and a handover session included	Handover priced separately or not mentioned
Support	Warranty period and a maintenance option with clear rates	Nothing after launch

A fixed price suits a small, well-defined first release. Time and materials suits products where you expect to learn and change direction; protect yourself with a monthly cap and the right to stop at the end of any sprint.

Contract clauses that protect you

Use a written contract, reviewed by a lawyer who knows software work in your jurisdiction. These are the clauses small businesses most often regret leaving out:

• Intellectual property: on payment, ownership of the custom code, designs and content created for you transfers to your company in writing. The agency can keep rights to its pre-existing tools and libraries, but you need a licence to use them indefinitely.
• Open-source components: a list of third-party libraries and their licences at handover, so you know your obligations.
• Acceptance: how each milestone is tested and accepted, with a fixed number of days to report defects.
• Change control: changes are estimated and approved in writing before work starts.
• Confidentiality and data protection: if the agency will handle personal data, the contract should say how. In India, the Digital Personal Data Protection Rules, 2025 expect a Data Fiduciary's contracts with Data Processors to include "appropriate provision" for reasonable security safeguards (Rule 6(1)(f)), with the core obligations applying from May 2027.
• Termination and exit: you can end the contract with notice, pay for work done, and receive everything produced so far.
• Warranty and support: a bug-fix period after launch and the rates for maintenance afterwards.

Name the technical standards

"High quality" cannot be tested. Standards can. Naming them in the contract gives both sides a shared definition of done.

Security: OWASP ASVS

The OWASP Application Security Verification Standard (ASVS) provides "a basis for testing web application technical security controls" and "a list of requirements for secure development". The latest stable version is 5.0.0. You can ask the agency which ASVS level they will build to and how they will verify it, for example with code review, automated scanning and a test before launch. OWASP recommends citing requirements with the version, such as v5.0.0-1.2.5, because identifiers can change between versions.

Accessibility: WCAG 2.2

The Web Content Accessibility Guidelines (WCAG) 2.2 are a W3C Recommendation; the current published version is dated 12 December 2024. Asking for WCAG 2.2 level AA conformance is a common and reasonable contract requirement for public websites and apps. Ask how the agency tests it: automated checks catch only part of the problems, so expect keyboard and screen-reader testing too.

Quality and operations

• Automated tests for core flows such as sign-up, checkout and payments.
• A staging environment that mirrors production, where you accept work.
• Error monitoring and uptime alerts that go to you as well as the agency.
• Backups with a tested restore before launch.
• A short runbook: how to deploy, roll back and rotate credentials.

Keep control of accounts and code from day one

The most expensive agency disputes are about access, not code quality. Avoid them by owning the accounts yourself and inviting the agency in, rather than the other way round.

• Domain and DNS: registered in your company's name, on your account, with two-step verification.
• Hosting and cloud: your account, your billing, the agency added as users with only the permissions they need.
• Code repository: created in your organisation on GitHub, GitLab or similar, with the agency's developers added as members.
• Third-party services: payment gateway, email delivery, analytics and app-store accounts in your company's name.
• Credentials: shared through a password manager, never by email or chat, and rotated when the engagement ends.

If the agency has already created a repository under its own account, GitHub supports transferring it. GitHub's documentation explains that a transferred repository keeps its issues, pull requests, wiki, stars and watchers, and that webhooks, secrets and deploy keys "remain associated after the transfer". That last point matters: after a transfer, review and rotate any secrets and deploy keys you did not create. Note also that if you transfer a private repository to a GitHub Free account, it loses access to features such as protected branches.

During the project

1. Hold a short weekly demo of working software on staging, not slides.
2. Keep a single written backlog, owned by you, with priorities you set.
3. Accept or reject milestones in writing within the agreed window.
4. Pay against accepted milestones, not dates.
5. Ask for a written decision log for architecture and third-party services.
6. Review user access every month and remove anyone who has rolled off the project.

Handover checklist

Done	Item
☐	Source code in your repository, including infrastructure and deployment scripts
☐	Setup and deployment documentation another developer can follow
☐	List of third-party services, accounts and monthly costs
☐	Open-source licence list
☐	Admin access to every service in your company's name
☐	Agency access reduced to what the support contract needs; shared secrets rotated
☐	Security and accessibility test results against the named standards
☐	Tested backup and restore
☐	Signed IP assignment

Next steps

Write the one-page brief this week and list the accounts you need to own. Use the first-call questions to shortlist three agencies, compare their proposals in the table, and send the contract to a lawyer with the clause list above. The agency that is comfortable with all of this is usually the one you want: good partners expect clients to own their code and their accounts.