What to Ask Before Someone Builds You Software

This is the question people assume they do not need to ask, and it is the one that causes the most expensive surprises. Paying someone to build something does not automatically make you the owner of it. Unless a contract says the intellectual property transfers to you, the person who wrote it may still own it, and you may hold nothing more than permission to use it.

You want the answer in writing, in the agreement, before work starts. Not a verbal yes in a meeting.

Your domain name is the single most important asset in the whole arrangement, and it is routinely registered in the developer's name because it was easier that way on the first day. The same goes for the hosting account, the email service, the analytics, and anything else the build depends on.

If your domain is in someone else's account, you do not control your own email or your own website, and recovering it depends entirely on their goodwill and their responsiveness. Ask for a list of every account the build touches, and whose name is on each one.

Not whether you can. Everyone says you can. Ask how, and ask them to show you. There is a large difference between a button that exports a spreadsheet you could actually use, and a technical possibility that requires hiring someone to extract it from a database.

Ask a second question too: who can read your data, and under what circumstances. If the system holds information about members, clients, patients or donors, you are responsible for it, whoever built the software.

A build has a price and everyone discusses it. Running the thing has a price too, and it is often discovered later: hosting, the domain, email, backups, security updates, and the hours when something needs fixing.

Software is not a painting. It sits on the internet, where the things around it keep changing, and something that is never updated slowly becomes something that is not safe to run. Ask for the monthly figure in the first conversation and treat a vague answer as a number you will find out the hard way.

Everything breaks eventually. The question is not whether, it is who you call and what you can reasonably expect.

You do not need round the clock support and you should be suspicious of a small shop that promises it. You need an honest answer about response times, and you need to know whether anyone is watching the system at all or whether the first alarm is you noticing.

You are not asking this because you plan to leave. You are asking because the answer tells you whether the thing was built to be maintained or built to be dependent.

A system built on ordinary, widely used technology can be handed to somebody else. One built on an unusual private setup, with no documentation, can only be maintained by the person who built it, and that is a commercial position rather than a technical one.

This is the question that tells you whether you are talking to someone who thinks, or to someone who says yes to everything. Anyone who agrees to every feature in a first meeting is either not listening or is planning to bill for the difference later.

A good answer will push back on something you asked for. That is not a bad sign. It is the clearest indication you will get that the person is thinking about what you will actually use rather than about the size of the invoice.

Ask it plainly, early, and without apology. It is not a sign of distrust. It is the single most useful question in the list, because it forces every previous answer to become concrete.

You want to hear a description of a handover: what you receive, in what form, and how long it takes. A person who has thought about this has built accordingly. A person who has not is telling you something important about what you would be left holding.