Put a real job in front of each developer. Ask who will build it, how you will check it works, and who will help after launch. Here is how to compare the answers.
Choosing a developer gets easier when you put a real piece of work in front of them. Ask who will build it, how you will check it works, and who will look after it once people start using it. Then ask for evidence that fits those answers.
Imagine you run a wholesale business. This is a fictional example: staff enter orders, reserve stock, and arrange deliveries. You want those people to work from the same order record.
One supplier shows a beautiful ordering app. Another asks what happens when a customer changes an order after the stock has been reserved. Both conversations tell you something. The app shows a piece of software. The questions show which parts of your work the supplier is trying to understand.
Give shortlisted candidates the same example, including one awkward case. Ask them to explain what they would need to learn before proposing a solution. You are comparing how they approach your work, without asking them to design the whole system for free.
The UK government's purchasing guidance connects the choice of products and suppliers to core needs, available capability, contracts and ongoing supplier management. It is government guidance, but the useful buyer question travels well: can this arrangement support the work you actually need done?
A relevant project gives you a reason to ask more. Find out what the supplier built, what they inherited, and which parts they still look after. If a client can discuss the work, ask about the parts that matter to you, with their permission.
A supplier can explain a comparable workflow, their own role, and the choices they made. You can ask how that experience would apply to your job.
A finished screen does not show how the software is tested, changed or kept running. Ask for evidence about those parts separately.
Your order system might need reliable stock records and restricted access to customer details. A good-looking shop website would leave those questions open. A project in another industry could be more relevant if its daily work has similar demands.
Find out who you will actually work with after the sales conversation. Who makes technical decisions? Who builds and tests the software? Who can explain progress to your staff? If people or subcontractors change, who remains responsible for the result?
You do not need to choose a particular team size or technology to ask this. Ask candidates to walk through one small change, from your request to its release. Their answer should make it clear who does each part and where you need to make a decision.
Agree how work will be demonstrated and accepted. For the wholesale example, you might check that an approved order change releases the original stock reservation and records who approved it. Use invented records in a separate test setup so a demonstration cannot change real orders. These are proposed checks for the fictional business. Your own checks should come from your real work.
Before appointing a supplier, be able to explain who does the work, how you will check it, and who helps when it stops working.
Ask who will run the system, watch for failures, install updates and deal with a broken connection to another service. Agree how you report a problem, when help is available, what it includes and what it costs.
Google's account of transferring responsibility for running services describes readiness reviews, training, documentation and support during the transfer. A small business does not need Google's teams or process. The relevant point is that someone taking over needs enough knowledge and preparation to do the job.
Discuss handover before signing. Identify the accounts, access, data exports, documentation and source code you need, and agree what will be supplied. Check the licence and any third-party restrictions. Paying for development does not by itself tell you which rights or materials the agreement provides.
For each candidate, write down the relevant work they can show, who will be responsible, how you will see and accept progress, and what happens after launch. Beside that, record anything you still need to verify.
Ask how they will explain a change in scope, cost or timing before you approve it. Price belongs in the decision alongside the work and continuing obligations it covers. If an important answer is missing, agree a specific next step to find it rather than filling the gap with confidence in the presentation.
We build custom business software. If you are considering working with us, bring a real example of the job you need done. Scope, delivery, support and handover terms are agreed for each project.
You can assess their explanation, relevant work, named responsibilities and proposed checks with your staff. If the decision needs a technical judgement you cannot make, arrange an independent review of that specific question.
It can show a piece of work and give you questions to ask about the supplier's role. It does not establish how your proposed system will perform, be maintained or be supported. Ask for evidence that fits those needs.
Agree who runs the software, how problems are reported, support availability and charges, and what access, data, documentation and source code will be supplied. Check these against the actual agreement and licences.
Last newsletter: making more money from a subscription site or app you already own.
The one before: how to spot AI nonsense from real success stories.
Interested?
Weekly Or just let us know and we'll adjust it for you. Sounds good?
