If you are comparing development companies and every proposal looks reasonable, the problem is usually not the proposals. It is that you have not decided what you are testing them on. Knowing how to choose a software development company comes down to checking a short list of things that decide whether software gets delivered, works and stays yours, and ignoring most of what appears in a sales deck.
This guide is for buyers commissioning custom software from an agency or development company. It applies wherever the company is based. If you are deciding between onshore, nearshore and offshore teams, read our software development outsourcing guide first; this one assumes you have a shortlist and need to judge it.
Define the business problem first
In short: a one-page brief is the only way to compare proposals fairly.
Companies quote what they hear. If one hears “a portal” and another hears “automate our order process”, you will get two proposals you cannot compare. Write the brief before the first call.
It needs four things: the problem in plain words (“orders arrive by e-mail and are retyped into three systems”), who will use the software and roughly how many, the tools it must connect to, and the number that should move (hours saved, errors, response time). Add your budget range if you have one. Hiding it does not get you a better price; it gets you proposals sized for someone else.
Then run the selection as a short, fixed process rather than an open-ended conversation:
A two-to-three-week selection process
- Write the one-page briefProblem, users, systems, the number that should move, budget range
- Shortlist three companiesRelevant live work, not just a matching technology list
- Same brief, same questionsUse the checklist at the end of this guide for every call
- Written proposalsScope, assumptions, exclusions, timeline, price and support terms
- Reference callsSpeak to at least one past client per finalist
- Start smallA paid discovery or first release before committing to the whole build
Evaluate technical expertise
In short: inspect evidence, and talk to the people who would write your code.
A technology list on a website tells you very little. Every custom software development company lists React and AWS. What you want to know is whether they have built something with a similar shape to yours: the same kind of workflow, the same integrations, a similar number of users.
Ask for two or three live products you can click through, and ask what the company was responsible for in each. Then ask to speak to the engineer or technical lead who would lead your project. Give them your brief and ask how they would approach it, and what they would build first. A strong answer starts with questions about your process, names the risky parts (usually data migration and integrations) and proposes a small first release. A weak answer is a feature list.
If you have a technical person available, ask to see a sample of real code or a recent pull request with the review comments on it. Readable code with tests and genuine review comments is a better signal than any certificate.
Ask about their development process
In short: you should see working software regularly, not status reports.
Ask the company to walk you through a typical project week by week. You are listening for three things: when you will first see something working, how often you will see progress after that, and how decisions and changes are recorded.
Good answers sound like: a short discovery, a clickable prototype your team tests before code is written, then working increments demonstrated every week or fortnight on a test environment you can log into. Weak answers describe months of specification followed by a single delivery. For what a sound process looks like stage by stage, see our guide to the custom software development process.
Also ask what “done” means. If a feature is “done” when the developer says so, rather than when it is tested, reviewed and accepted by you, expect surprises.
What to ask about QA
In short: ask who tests, how, and what you get to see.
Quality assurance is where development companies differ most and where buyers ask least. These questions separate them quickly:
- Is every change reviewed by a second engineer before it is merged? It should be.
- Which parts are covered by automated tests, and do they run on every change? Business rules, calculations and integrations should be.
- Is there a separate test (staging) environment? You should be able to test there before anything reaches your live system.
- Who does user acceptance testing, and against what? Ideally your team, against written acceptance criteria agreed before the work starts.
- How are bugs classified and fixed? Ask for their severity levels and the target fix time for each.
Be wary of anyone who promises bug-free software. All software has defects; the question is how quickly they are caught and how they are handled.
Security and data protection
In short: your accounts, minimal access to real data, and a proper data processing contract.
Ask where the code, the cloud hosting and the data will live. The safest answer is accounts in your company’s name, with the developer given access you can revoke. Ask whether engineers need access to live personal data at all; often they can work with anonymised or test data.
If the software will handle personal data of UK customers or staff, the development company is likely to be acting as your processor. The ICO’s guidance on data security says you must choose a processor that gives sufficient guarantees about its security measures, and put security requirements in the contract. Ask how they control access, whether multi-factor authentication is enforced on their accounts, and how they handle API keys and passwords.
Security deserves more than a paragraph. Our guide to what makes custom business software secure covers the full list of questions to ask.
Code ownership and IP
In short: get a written assignment of all IP to you, whichever country you are in.
Many buyers assume that paying for software means owning it. Legally, that is not automatic.
UK. Under the Copyright, Designs and Patents Act 1988, the author of a work is the first owner of the copyright, and an employer owns work its employees create in the course of employment. So the development company, not you, owns what its staff write. For ownership to pass to you, the company must assign it, and section 90(3) says an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the assignor.
US. The U.S. Copyright Office’s Circular 30 explains that a work is “made for hire” in two situations: when an employee creates it as part of their job, or when a commissioned work falls within one of nine listed categories (such as a contribution to a collective work, a translation or a test) and both parties sign a written agreement saying it is a work made for hire. Custom software built by an outside company or an independent contractor is generally not an employee’s work and does not fit neatly into those categories, so a “work for hire” clause on its own may not give you ownership. Use a written assignment of copyright as well.
In both countries, ask three further questions. Does the company use freelancers, and are they bound to assign their work to the company? Which pre-existing libraries or components of their own will they reuse, and on what licence? And does ownership pass on payment of each invoice, or only at the end of the project? This is general information, not legal advice; have your solicitor or attorney review the contract.
Communication and project management
In short: one named contact, visible progress, and direct access to the engineers.
Most failed projects fail on communication rather than code. Ask who your day-to-day contact is and whether they are technical enough to answer questions without relaying them. Ask whether you can message the engineers directly and join their regular check-ins.
You should be able to see the backlog of work, what is in progress and what is finished, in a tool you can log into. Ask how decisions are recorded: a change agreed on a call should appear in writing within a day. If the company is in another time zone, agree the overlap hours in writing; the outsourcing guide covers how much overlap different locations give you.
Finally, ask what happens when something goes wrong. A good development partner tells you about a slipping deadline the week it starts slipping, not the week it was due.
Support after launch
In short: price year two before you sign year one.
Launch is the start of the software’s life, not the end of the project. Before signing, ask for written answers on:
- Defect warranty: how long after launch bugs in delivered work are fixed at no charge.
- Response times: how quickly they respond to an outage compared with a minor issue, and in which hours.
- Maintenance: security updates, dependency upgrades and small changes. A typical budget is 15–25% of the build cost per year.
- Hosting: for a typical business application, often around £15–£250 ($20–$300) a month, depending on usage.
- Exit: documentation, access handover and a notice period, so another team could take over if needed.
A low build price with an expensive or vague support arrangement is not a low price.
Fixed price vs time and materials
In short: fixed price for what is clear, time and materials for what is not, with limits on both.
Suits a clearly scoped first release. The supplier carries the scope risk, so the price includes a buffer. Check the assumptions and exclusions list, and how changes are priced; that is where fixed-price projects become expensive.
Suits work where requirements will change as you learn. You pay for time used and can reprioritise weekly. Insist on a budget cap, weekly reporting of hours against delivered features, and the right to stop.
A common pattern is to fix the price of a short discovery and first release, then move to time and materials or a dedicated development team once the product is live and evolving. Whichever you choose, compare proposals on the same scope; a cheaper quote often covers less, and the difference reappears later as change requests.
Red flags
In short: walk away from vagueness about people, code and ownership.
- A fixed quote without a single question about how your business works.
- No named team, or the engineers are “allocated after signing”.
- The code lives in their repository or their cloud account, with transfer “at the end”.
- IP passes only on final payment of the whole project, or the contract is silent on it.
- The product is built on the company’s own proprietary platform that you would licence rather than own.
- No test environment, no code review and no answer to “who tests this?”.
- A proposal with no assumptions or exclusions; every gap becomes a change request later.
- Pressure to sign quickly for a discount.
Software development vendor checklist
In short: score every company on the same twelve questions.
Ask each shortlisted company these questions and score each answer: 2 for a good answer given in writing, 1 for a partial or verbal answer, 0 for a red flag or no answer. The scores make companies comparable; the comments explain the gaps.
| Question | Good answer | Red flag | Score (0–2) |
|---|---|---|---|
| Have you built something similar? | Live products you can click through, with their role explained | Screenshots only, or nothing comparable | |
| Who will build it? | Named engineers you can speak to before signing | “We allocate after signing” | |
| What will I see working, and when? | A first working release in weeks, then regular demos | Nothing to see until the end | |
| How is code reviewed and tested? | Peer review on every change, automated tests, staging environment | “Our developers test their own work” | |
| Where will the code, hosting and data live? | Repository and cloud accounts in your company’s name | Their accounts, transferred later | |
| Who owns the IP? | Written assignment of all IP to you, ideally as each invoice is paid | Silent contract, or a licence instead of ownership | |
| How do you protect our data? | Minimal access, MFA, no live personal data in testing, processor terms | Shared logins, production data on laptops | |
| How do we communicate? | Named contact, shared backlog, direct access to engineers | Everything through an account manager | |
| How are changes priced? | Written change process with estimates before work starts | “We will sort it out as we go” | |
| What happens after launch? | Warranty period, response times, maintenance cost in writing | “Support is available” with no terms | |
| How would we leave? | Documentation, access handover and a notice period | No exit terms | |
| Can we speak to a past client? | Yes, a reference you can call | No references |
As a rule of thumb, a company scoring below about 16 out of 24 needs a hard second look, and any 0 on ownership, code location or data protection should stop the process until it is fixed in writing.
How DataVolve answers these questions
In short: you own everything from the first commit, and you see working software every week.
DataVolve has delivered 75+ projects since 2021, working with clients in the UK, the US and elsewhere from teams in the United Kingdom and Pakistan. Our clients own the code, the cloud accounts and the domain from the first commit. We demo working software every week, and a focused tool can have its first working release in about 10 days. We build web software with React, Node.js, Python and AWS, and mobile apps with React Native and Flutter.
You can read more about our custom software development service for UK businesses, or our software development service for US companies. If you are deciding whether to build at all, start with custom software vs off-the-shelf software. When you are ready, send us two lines about the problem and you will get a written scoped plan within 24 hours. Use it to score us against the checklist above, alongside everyone else on your shortlist.