How to choose a software development partner, and when not to hire one

First: do you need a partner at all?

Hiring a development partner is one of several ways to get software built, and often not the best one. Before comparing agencies, check which of these routes fits.

Buy a product when the process is common and a mature product already handles it well. Invoicing, payroll, ticketing and most CRM work fall here. You’ll pay a subscription instead of a build, and someone else maintains it. We cover where the line sits in When spreadsheets stop working.

Use a no-code tool when one team needs structure quickly and the rules are simple. A shared database with forms and a few automations can carry a team a long way, and it’s cheap to throw away if you outgrow it (same article).

Hire in-house when the software is core to the business and will change every week for years. You need people who stay with it. A partner can help you start, but the long-term owners should be yours.

Use a freelancer for a small, well-defined job with a clear end, where someone on your side can review the work.

You’re not ready yet when nobody owns the problem or nobody can describe the process. Map the work first; Choosing what to automate sets out how. Any good partner will start there anyway, and you’ll have a better conversation if you’ve done it.

A development partner fits when the workflow is specific to you, several systems are involved, you need design, build and operation handled together, and you want to own and run the result afterwards.

Many teams combine these: a product for the common parts, a partner for the part that’s specific to them, and an in-house owner for what comes after.

What a good partner does before quoting

A quote is only as good as the understanding behind it. Before naming a price, a good partner should want to know how the work happens today: the workflow, the people who use it, the constraints, the systems it has to talk to, and what success would look like.

That is the first stage of how we run a project: clarify the workflow, users, constraints, existing systems and definition of success. Every engagement should establish the problem, delivery boundaries and operating responsibilities before unnecessary complexity is introduced.

A good partner should also be willing to start from the problem rather than a finished specification. Work can begin with a defined specification or with discovery of the problem itself. If you arrive with a forty-page requirements document, they should still test it against how the work is actually done. If you arrive with a vague sense that something is broken, they should help you describe it before estimating it.

The warning sign is the opposite: a firm price after one short call on a scope nobody has written down. Either the number hides a large contingency, or the disagreements start the first time the scope moves.

Questions to ask, and what a good answer sounds like

A useful question is one a weak partner would struggle to answer well. Portfolios and case studies show what a firm has done; these questions show how they’ll work with you.

1. What do you need to understand before you can quote? A good answer covers your process, users, existing systems, constraints and what “done” means, and proposes a short framing step if those aren’t clear yet. Be wary if they can give you a price before asking about any of that.
2. Who will actually build it, and will I speak to them before signing? A good answer names the people and puts them in the conversation now, not after the contract. Be wary if your only contact is a salesperson or account manager, and the team’s names arrive after signing.
3. How will I see progress? A good answer describes reviewable increments you can try yourself, and early integration with your real systems rather than a demo environment. Be wary of weekly status reports and a big reveal at the end.
4. What does “done” mean, and how do you handle changes? A good answer turns goals into acceptance criteria in business terms. “An order cannot be dispatched until its credit check is complete” can be tested; “better order handling” cannot. It should also describe agreed boundaries and a clear process for changes. Be wary if “done” means “when the features on the list exist”.
5. How do you test it, and how will we know it works in production? A good answer includes automated tests, monitoring and alerts, and failures that are visible rather than silent. For AI work, it includes an evaluation set built from your real cases (more on that in Why AI pilots stall). Be wary if testing means “we click through it before release”.
6. Who owns the code, and where does it live? A good answer is specific and goes in the contract. See the next sections. Be wary of “don’t worry about that”.
7. What will we receive at handover, and could another team take it over? A good answer sounds like the checklist below. Be wary of “we’ll host and run it for you” with no route out.
8. When would you tell us not to build this? A good answer is concrete: a product already exists, the rules are simple enough for a workflow tool, AI isn’t needed. Be wary if they’ve never advised a client against building something.

It’s also reasonable to ask for references or examples of comparable work, and to speak to someone who has worked with them. Treat the answers as one input among the others above.

If the work involves AI

AI projects need a few more questions, because a system can look convincing in a demo and still be wrong often enough to be unusable.

• How will you judge whether it works before launch? Look for an evaluation set built from your real cases, with results you can see.
• Which steps does a person approve, and what happens when the system is unsure?
• Where does our data go, and whose cloud account does the system run in?
• What will it cost to run per task, not just to build?
• How are model changes controlled, and how would we notice a drop in quality?
• Would you tell us if we don’t need AI at all?

The last one matters most. If the logic can be written down, plain code or a workflow tool usually does the job more cheaply and predictably. We’ve written more about why AI projects stall between pilot and production in Why AI pilots stall, and about what we deliver on AI work on our Applied AI page.

Red flags

Each of these is something you can observe during the sales process, before you’ve committed:

• A fixed price on an unclear scope. Nobody can price work that hasn’t been described.
• An estimate that exactly matches your stated budget. That suggests the number came from your budget, not from the work.
• No discovery or framing step. They’re ready to build before they understand the problem.
• The builders aren’t named. You meet a salesperson; the team is “to be confirmed”.
• Evasive answers to specific technical questions, such as how they test, deploy or roll back.
• No mention of documentation or handover. The plan ends at launch.
• Ownership left vague. Who owns the code and where it lives are treated as details to sort out later.

One red flag on its own isn’t always decisive. Several together usually are.

Get these in writing before you sign

Two things cause more trouble after a project than almost anything else: unclear ownership and a handover that never really happened. Both are easier to settle before the contract is signed than after.

Code and IP ownership

In the UK, the person who writes the code, or their employer, is usually the first owner of the copyright. Paying for the work doesn’t by itself transfer it to you. Under the Copyright, Designs and Patents Act 1988, section 90(3), an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the person assigning it.

So ask for the position to be written into the contract. In particular:

• whether you receive an assignment of the copyright or a licence to use it, and on what terms;
• whose name the code repositories and cloud accounts are in;
• how any reused libraries, open-source components or the partner’s own tools are treated.

This is orientation, not legal advice. Have a solicitor review the contract.

What you should receive at handover

The test is simple: could another team run and change this system using only what you’ve been given? A handover should include:

• working software deployed in your environment;
• source code with its full history, in repositories you control;
• documentation of the architecture and the decisions behind it;
• runbooks for deployment, rollback, recovery and incidents;
• monitoring and alerts that someone on your side receives;
• tests you can run yourselves;
• credentials and admin access transferred, and old ones rotated;
• a walkthrough with the people who will run it.

For AI work, add the evaluation set and its results, decision records, and the cost and quality dashboards. Our Applied AI deliverables list these.

How we answer these questions

It would be odd to publish these questions without answering them ourselves. Briefly:

• Who builds it: buying custom software means buying the people who build it. You’ll work directly with Veliora’s founder.
• How we work: every engagement follows Frame, Design, Build, Transfer. We deliver in reviewable increments, integrate early and make important behaviour visible.
• Handover: we deploy, document decisions and leave the team with a system it can operate confidently: working software, documentation, runbooks and a handover your team can run. For AI work, the system runs in your cloud account.
• Ownership: who owns the code is agreed in the contract for each engagement, so ask any partner, including us, to put it in writing.
• Saying no: part of the first conversation is checking whether AI, or custom software, is needed at all. If the logic can be written down, plain code or a workflow tool does the job more cheaply and predictably. We will say so.
• What happens next: we reply within one working day, then a 30-minute call. If it’s a fit, you get a short written proposal setting out a first step, its scope and its cost.

Our engineering notes show how we reason: small, reproducible experiments, each with its method, numbers and limitations.

Questions

Talk to us

Tell us what is not working. A few lines is enough. We can start with the problem before discussing any particular technology. And if the right answer is a product, a tool or an in-house hire, we’ll say so.

Discuss a project