Choosing an IT provider: 10 questions to ask

Development agency, software development company, freelancer, consultancy: on paper, the offers look alike. They all promise quality, and the quotes are hard to compare. Yet choosing an IT provider means entrusting them with your code, your data and part of your business, often for several years.

The most reliable way to choose between candidates? Ask them all the same questions, then compare the answers. Here are ten, with what they reveal and the answers to expect.

Before choosing an IT provider, lay the groundwork

Three precautions make the comparison fairer:

• Describe your need in a few pages: the problem to solve, the users, the tools in place, the deadline. The document doesn’t have to be perfect: our method for writing a software requirements specification helps you stick to the essentials.
• Send the same document to every provider, so that you compare answers to the same question.
• Favour a conversation over a form. A good partner takes an interest in your business before talking technology, and tells you frankly when they are not the right choice.

The framework: ownership, method and demos

1. Who will own the source code and the data?

This is the first question to ask, because everything else depends on it. Without rights to the code, you may be unable to develop it further without your provider, or to hand it over to another one. In France, for example, paying for development is not enough to own it: the assignment of copyright must be expressly provided for in the contract.

The answer to expect: the source code, the data and the documentation belong to you, and the contract says so in black and white. The only legitimate exception: third-party components and the provider’s generic tools remain under their own licence, which must allow you to keep using them. Also ask when the code will be handed over: depending on the project, this can be continuous, in a repository you have access to (on GitHub or GitLab, for example), or at milestones agreed in advance, when the work doesn’t split into deliverable pieces. What matters is that these milestones are written into the contract.

2. How will you work with us?

Agile, Scrum or the V-model: the label matters less than how things actually work.

The answer to expect: short iterations, a dedicated contact person, priorities set with you, and a clear rule for handling new requests along the way. Be wary of a provider who disappears for months and comes back with the finished software: every month without seeing anything is a month of possible misunderstandings.

3. When will we see something that works?

A demo is worth more than any number of progress reports.

The answer to expect: clickable mock-ups before development, then a demo at the end of each iteration, in a test environment where your teams try things out themselves, with their own cases. A first version should be usable early, without waiting for the end of the project: for the CRM/ERP of a Sydney law firm, a project our founder led as IT director at DIGIIT Solutions, the firm was able to use a first version in under six months.

Quality: testing, security and documentation

4. How do you test what you deliver?

Without automated tests, software quickly becomes fragile: every fix risks breaking another part of it.

The answer to expect: automated tests written at the same time as the code and run on every change, an acceptance phase in which you check and approve before each release to production, and a warranty covering defects found after delivery, for a defined period. Purely manual checks, or checks left to your teams, are not enough: acceptance testing is there to approve the work, not to find errors instead of the provider.

5. How will you protect our application and our data?

Security isn’t added at the end: it is planned from the design stage.

The answer to expect: role-based access, passwords and keys stored securely, backups whose restoration is tested, regular updates, and real data that is not copied onto developers’ computers. If the provider processes personal data on your behalf and your business falls under the GDPR, the regulation also requires a contract that governs what the provider may do with that data.

6. What documentation will you hand over?

Documentation is what will allow someone else to take over your software tomorrow.

The answer to expect: technical documentation (architecture, installation, deployment), a user guide and a record of the important decisions. It is written as the project goes along, not in the last week, and it is handed over to you with the code.

The team, life after the project and references

7. Who will actually work on our project?

The person who presents the proposal is not always the one who will deliver it.

The answer to expect: the names and roles of the people involved, the contact who will follow your project day to day, and complete transparency about any subcontracting. Also ask what happens if someone leaves the team: documentation and shared code should allow a smooth handover.

8. What happens after go-live?

Software lives for years: it has to be kept running, protected and developed further.

The answer to expect: a maintenance offer that specifies what it covers (fixes, security updates, small improvements), written response times according to the severity of the problem, and a predictable cost, for example a monthly subscription.

9. What if we want to change provider?

Nobody likes to talk about breaking up at the moment of signing. Yet it is the best time to do it: everyone is full of goodwill.

The answer to expect: an exit clause that provides for the handover of the code, the data in a usable format, the documentation and all access rights, with a transition period. A simple tip: from the start, open the essential accounts (hosting, domain name, app stores) in your company’s name. A provider confident in its work has no reason to tie you down by contract.

10. Can you show us comparable projects?

References are the best proof, provided you know how to read them.

The answer to expect: projects similar to yours, explained in concrete terms (the need, the solution, the provider’s exact role and the result). If possible, talk to a former client. And for every result given as a figure, ask how it was measured.

Before you sign: what the contract must specify

Good answers in a meeting must also be there in writing. Check that the proposal or the contract clearly specifies:

• the scope and the list of deliverables;
• the timeline, with its milestones and demos;
• the billing model (fixed price, day rate or subscription) and how new requests are handled;
• the assignment of rights to the code and the ownership of your data;
• acceptance: who approves, and against which criteria;
• the warranty after delivery;
• maintenance: what it includes and its response times;
• security and, if you entrust personal data, the clauses required by the GDPR;
• exit: what is handed over to you if you leave, and within what time frame;
• the people who will work on the project, and any subcontracting.

For the legal clauses, a lawyer’s advice is still invaluable.

Frequently asked questions

Freelancer, agency or software development company: which should you choose?

It all depends on the project. A freelancer suits a well-defined assignment, provided continuity is planned for in case of absence. A development agency often specialises in websites and web applications. A software development company or a consultancy generally covers a wider scope: design, integrations, security, maintenance. In every case, question 7 remains decisive: who will actually work on your project?

Should you choose the cheapest quote?

Not necessarily. Two quotes don’t always cover the same work: testing, documentation, data migration or maintenance may be included in one and missing from the other. Compare like with like, including maintenance in the years that follow. To understand what really drives the price, read our article on the cost of custom software.

Can you work with a remote provider?

Yes, if communication is well organised: regular video calls, demos, overlapping working hours and a shared working language. Also ask who responds in an emergency, and at what time. Distance matters less than clarity.

In short

You recognise a good IT provider not by its promises but by the precision of its answers. Ask every candidate these ten questions, and ask for the answers to be written into the contract.

Ask us too: our FAQ already answers several of them (code ownership, how projects run, support after go-live, taking back control), and we are happy to go through the others on a call. Do you have a custom software, web application or business tool project? Book a free 30-minute discovery call: we listen to your needs and, if we are not the right people for the job, we tell you so.