Questions to Ask Before Hiring a Development Team

The sales call is the wrong place to vet a team

Almost nobody is hired by a development team at the first meeting. That call is usually run by someone whose actual job is to qualify the enquiry and book a meeting. The person may be perfectly well informed, but they are describing a process rather than doing the work, and they are incentivised to move you to the next stage rather than to disqualify you. It is worth going to that call, but it is the wrong place to find out who will write your system.

The questions that matter come later, from the people who will size the work and then build it. The difficulty is knowing which questions to ask, and telling the difference between a rehearsed answer and a considered one. The questions below are the ones worth carrying into that second conversation. Several of them are mildly awkward to ask. That is a reasonable signal.

Questions about how they produce a number

A price is an output of assumptions. If you cannot see the assumptions, you cannot tell whether the price is competent or optimistic.

• What is in this number, and what is explicitly outside it? The strongest answers produce a written list of exclusions. Hosting, content migration, third-party licence fees, data cleansing and ongoing support are all routinely absent from a first estimate and all routinely billed later.
• What has to be true for this number to hold? If the answer is vague, the estimate is a guess. A credible answer names things like “the existing data is exportable in CSV”, “you have a decision-maker available within a day”, or “no third-party system needs to change”.
• What would make it go up? Somebody has to carry the risk in the gap between the estimate and reality. Ask who, explicitly.
• Do you price by hours, by fixed price, or by phase? All three exist and all three are legitimate. Fixed price transfers risk to the supplier, which they will price accordingly. Hourly transfers risk to you but gives you visibility. Phase-based delivery is usually the honest middle ground for work that is not yet well defined.
• What is the discovery step, and what does it produce? If the answer is “a call and a proposal”, you are buying certainty you have not earned.

Be suspicious of estimates with no range attached. A confident single figure on unfamiliar work means somebody is absorbing uncertainty silently, and that surplus gets reclaimed later through change requests.

Questions about who does the work

This is where the answers usually get vaguer, and it is the most important section of the whole conversation.

• Which named individuals will be on this, and what else are they booked on? Get names. A firm that will not name the people is either reselling other people’s capacity or has no idea who is assigned.
• Will the same people still be here in month six? Rotation is normal in a healthy organisation and corrosive in a project. If the answer is “we rotate for knowledge sharing”, ask what happens to work-in-progress knowledge when someone leaves after six weeks.
• How many developers are there per reviewer or lead? On small teams there is often no reviewer at all, and one person approves their own work. That is fine for a prototype and a serious problem for anything holding customer data.
• Where are they based, what hours do they work, and who can make decisions on our account? Overlap with your business day is a practical constraint on responsiveness, not a judgement about anyone’s competence.
• Which accounts does my code sit in, and who can access it? Some teams will hand over a repository and repository credentials on day one. Others keep the master account and deploy on your behalf. Neither is automatically wrong, but the second one needs to be written down as an exit arrangement with a date attached.

We are asked about this more than anything else, and the honest answer is that access must be held by the client from the first day. SmartEdge IT Solutions shares the process documentation we use for handover, because it is the single point where most disputes later become technical rather than commercial.

Questions about the period after launch

Projects rarely fail in the first month. They fail in month eight, when something breaks at an awkward time and the people who built it have moved on. Ask about the operational reality before you sign.

• Who responds when this breaks, and between what hours? There is a difference between a support window and a response window, and a bigger difference between a response window and a fix window.
• How do we find out about a problem before we find out about it? Error tracking, uptime monitoring, and somebody actually looking at them. See our note on monitoring and backup for what a reasonable baseline looks like.
• Do you patch the dependencies you introduced, and on what schedule? A build with a two-year-old framework version is a future incident with a scheduled date.
• What is the security position you are leaving us in? Ask about secrets storage, access logging, TLS, and how credentials are rotated. This is covered in more depth in our server hardening work, but a supplier should be able to answer it in plain language.
• Who maintains it, and how are they paid? A retained arrangement and an hourly one produce different behaviour. Retained suppliers notice slow degradation; hourly ones respond to tickets.

Questions to ask the people who will do the work

There is no reason not to speak to the technical staff directly. Most firms will arrange it, and it is the fastest way to tell whether a firm has a genuine engineering culture or a small delivery team bolted onto a large sales operation. Ask what their last project looked like, what went wrong, and what they would do differently. Then ask something concrete and current: how they handle database migrations when they cannot take the site offline, or how they test a third-party payment integration that is unreliable in a staging environment.

Pay attention to whether the answer contains a trade-off. Anyone can describe a good outcome. A developer who explains why they would not choose the most elegant solution, given the size of the team and the length of the maintenance window, is showing you how they actually think. That is the capability that matters in year two.

Questions about the paperwork

Do not let a warm conversation carry you past these. They are unremarkable and their absence is informative.

• Who owns the source code, the designs, and the database schema when it is finished?
• Which third-party licences are we paying for, and are any of them seat-based or per-environment?
• What happens to our data and our access on the day the contract ends?
• How are payments tied to milestones, and who signs off a milestone?
• What is the change-control process, and what does a change cost before it is agreed?
• Is there a liability cap, and is there insurance behind it?

A statement of work that specifies deliverables, assumptions, and a single named owner for acceptance is worth more than several pages of general terms. SmartEdge IT Solutions takes the same view on how data is handled and how we behave when a project goes sideways, which is set out in our ethics policy.

Questions about how they say no

Here is the tell. Ask what they would remove from the scope if the budget were half. A supplier who says nothing needs removing has not estimated anything. A supplier who cuts something specific, and explains the trade-off, has done the work.

Ask what feature they would build first and why. If the answer is a feature that will not be used by the people paying for it, ask them again. Then ask what they think will be the most useful thing in month six, which is a question about product thinking rather than capability.

We have watched good project scopes die in the first week because nobody said the awkward thing out loud. Saying no early is cheap. Saying no late is a change request with a fee attached.

Questions that make them slightly uncomfortable

These usually produce the most useful answers, and the most honest ones usually come with a pause first.

• What is the most common way a project like this ends badly? Listen for the answer that names a process failure rather than a technical one. “Clients change their minds” is a process failure.
• Show me a project you stopped delivering on. Every firm has one. What matters is the account of what happened and whether they changed anything afterwards.
• What is the most conservative technical choice you would make here? Boring, proven, well-documented. If the answer is an unfamiliar framework because your team has people in it, you are buying your staffing problem.
• If we did half of this, what would you do? The right answer is usually about sequencing, not cutting. Ship the part that makes the rest possible.

Turning the answers into a decision

Write the answers down while you are on the call. Two conversations separated by a week blur into a single flattering impression, and the detail that mattered is the detail you will not remember.

Then do three unglamorous things. Talk to two or three suppliers before committing to any of them, including one you have no intention of hiring, purely to calibrate. Ask for references and actually phone two of them, asking about the difficult part rather than the pleasant part. And check whether the team is structured the way you assumed, since teams set up for hired development work and teams set up for long-term product work make different commitments about documentation, testing and handover.

Talk to the people who will use the system as well as the people who will pay for it. Their answers about reports, exports, and edge cases tend to surface requirements that never appeared in the brief.

Finally, be suspicious of speed. A supplier who agrees to an aggressive start date before asking questions is optimising for the signature, and the pressure arrives later as change requests. The honest position is a slightly later date and a plan that survives contact with the work. SmartEdge IT Solutions sets out why we work this way, and it comes down to that same trade-off.

None of this requires a large budget to apply. Even a two-week pilot with a narrow, real piece of work reveals more than a dozen proposals: how fast they respond, whether they ask to see your data, whether they push back on the design, and whether they leave the codebase in a state you could hand to someone else. It is also the cheapest possible test of the thing you most want to know, which is whether the day-to-day reality of working with them suits you.