Three questions to ask whoever is building your software

Choosing who builds your software is hard because you cannot assess the work: if you could, you would do it yourself. A portfolio shows the result but not how anyone got there, and references almost always describe projects that ended well.

These three questions need no technical knowledge, and the answers are understandable.

1. “If I change supplier tomorrow, what am I left holding?”

The right answer is specific: servers, domains, mailboxes and service accounts in your name, credentials in your possession, data exportable in a readable format, documentation of how it is built.

Watch for the distinction almost nobody spells out, between the data and the infrastructure (which must be yours, always) and ownership of the source code (which often stays with whoever wrote it, unless bought outright). They are two different things and they belong in the contract separately.

If the answer is vague, or if you discover the domain is registered to them, you already have the information you needed.

2. “Who works on it, and who answers the phone in six months?”

In most projects that end badly the problem is not technical: it is that the person you spoke to is not the person who wrote the code, and the person who wrote the code has gone.

Ask for names. Ask whether development is subcontracted. Ask what happens if the person on it is ill for three weeks.

3. “What happens the day after handover?”

Software is not a painting you hang on a wall. There are security updates to apply, components that age, rules that change, and you wanting to modify something.

If maintenance is not in the quote, it does not mean it is not coming: it means it arrives later, at an hourly rate, when you have less bargaining power than you do now.

Ask exactly what it covers, with what response times, and what counts instead as new work. A serious supplier already has those answers written down.

The bonus question

“Is there anything in this project you think is not worth doing?”

Anyone answering “no, it all looks fine” has either not understood the project or has no intention of telling you. Every project contains at least one requested thing that is not worth what it costs, and hearing that before you sign is the best signal you can get.