12 questions to ask a software house before you sign

Buying software is unlike buying most things, because you cannot inspect it before it exists and you usually cannot judge it after it arrives. The quote is a number, the portfolio is screenshots, and the difference between a firm that will still be answering in a year and one that will not is invisible at the point of signing.

These are the twelve questions that make it visible. We are a software house, so we get asked some of these and dodge none of them, and we have written down what a good answer sounds like next to each.

Use it like this. Ask all twelve. Two of them make most vendors uncomfortable, which is the point, and they are marked. The answers matter less than whether the person has clearly thought about the question before you asked it.

1. Whose name is on the domain registrar account?

Good answer: yours, from the first day, with your email on it.

Bad answer: anything involving "we manage that for you" without a plan to transfer it. A domain held in a vendor's account is the single most common way a business ends up trapped with a supplier it wants to leave. If the domain is a .pk registered through PKNIC, this matters more, because the renewal process is less forgiving than an international registrar's and a lapse is harder to recover from.

2. What exactly do I receive at handover?

There should be a list, and it should have five things on it: the domain registrar login, the DNS records, the hosting account, the code repository and the database. All in your name.

Bad answer: "we will give you access." Access to a vendor's account is not ownership. When you leave, so does the access.

3. Can I see something you built that is still running?

Not a screenshot. A URL you can open now.

Then open it. Does it load quickly? Does it work on your phone? Is the content current, or is there a copyright date from three years ago and a news section with two posts? A site the vendor built and then never touched again tells you what your relationship after launch will look like.

4. Who fixes it when it breaks, and what does that cost?

Good answer: a named arrangement with a number attached. Monthly retainer, or hourly with a stated rate, or nothing but here is what a call-out costs.

Bad answer: "we will look after you." That is a feeling, not an arrangement, and it evaporates the first time you need it during a busy month.

5. Will you show me the contact form actually sending an email?

Ask them to submit the form on a site they built while you watch, and show you the message arriving.

This sounds paranoid. It is not. A form that silently discards submissions looks completely normal from the outside: the visitor sees a success message, nobody complains, and the business quietly loses every enquiry for months without a single symptom. It is one of the easiest things in web development to get wrong and one of the hardest to notice.

6. What will I be able to change myself, and what will I not?

Good answer: a specific boundary. Text, images, prices and products yes; page structure and layout no, that needs a developer.

Bad answer: "you can change everything." Nobody builds that, and being told you can is how you discover in month three that you cannot.

7. What is the total first-year cost?

Not the build price. The build, plus hosting, plus the domain, plus maintenance, plus anything with a licence fee, for twelve months.

Vendors quote the build because the build is the number that wins the deal. The first-year total is the number that tells you whether you can afford the thing.

8. Is that a breakdown or a single figure?

Uncomfortable question one.

A single number for a whole project is a number you cannot evaluate, negotiate or compare. Ask for it split: pages, integrations, admin system, content, testing, deployment. A vendor who will not break it down either does not know their own costs or does not want you to see them.

If a competing quote is half the price, the breakdown is the only way to find out whether that is because they are cheaper or because they are building less.

9. What is not included?

The most useful question on this list and the least asked.

Content writing, photography, logo design, payment gateway registration and its fees, third-party licences, ongoing hosting, training your staff. Every one of those is routinely outside a build quote and routinely assumed to be inside it by the client.

10. Who else works on this, and what happens if they leave?

You are told you are hiring a company. Find out how many people that actually means for your project.

Good answer: names, roles, and a real answer about cover.

Bad answer: vagueness about team size. A "software house" that is one person with a company name gives you the freelancer risk profile at firm prices, which is the worst of both. That is a fine thing to be, but you should know you are buying it, and we have written about that tradeoff in full.

11. Are you registered, and can I verify it?

Good answer: an SECP registration number, an NTN, a PSEB registration, any of which you can check against a register the vendor does not control.

This matters more than it sounds. Anyone can put "Pvt. Ltd" on a website. A number you can look up is a claim somebody else is standing behind. For a project large enough that a dispute would hurt, and for any public-sector or institutional buyer, this is not optional.

12. What would make you turn this project down?

Uncomfortable question two, and the most revealing.

A vendor who has never declined work will take yours regardless of whether they can do it. A good answer is specific: a budget that cannot meet the brief, a technology they do not know, a timeline that would require cutting testing, a client who wants an app when a website would do the same job for less.

The answer tells you whether you are talking to someone with judgement or someone with a sales target.

Two you can skip

"How many projects have you delivered?" Unverifiable and universally inflated. Question 3 gets you the same information in a form you can check.

"Do you use the latest technology?" The answer is always yes and it means nothing. Newer is not better, and a boring stack that the next developer can also read is usually the right call.

The short version, if you only ask three

Questions 1, 5 and 12. Who owns the domain, prove the form sends, and what would you say no to. Ownership, competence, judgement, in about four minutes.

Talk to us

We publish these because we would rather compete against firms that have good answers than win by being the only one nobody questioned. Ask us all twelve, and if any answer is unsatisfying, that is worth knowing before you sign rather than after.