Quick checklist
- Who owns the code, the data, the domain and the accounts?
- Where does it run, and whose name is on that account?
- What happens to the price when the scope changes?
- What does the first thing I can actually use look like, and when?
- Who maintains it, and what does that cost each year?
- If I want to move to someone else, what do I take with me?
- What have you built that I can look at?
Commissioning software is uncomfortable because you are buying something you cannot inspect, from someone whose work you cannot evaluate, to do a job you may not be able to specify yet.
These are the questions that get you the most information for the least technical knowledge. Ask us the same ones.
1. Who owns the code, the data and the accounts?
The answer should be short: you do. Your code, your data, your domain, your hosting account, your Google and payment accounts in your name.
Be careful of arrangements where the developer holds the domain, the hosting login or the repository “for convenience”. It usually is convenience, right up until a disagreement, at which point it is leverage.
2. Where does it run, and whose name is on that account?
Software has to live somewhere and somebody pays for that somewhere. If you cannot log in to the place your system runs, you do not really control it.
3. What happens to the price when the scope changes?
It will change. This is not a sign of a bad project — it is what happens when people start using something and discover what they actually needed.
The answer you want is a process, not a promise. “Small things are absorbed, anything bigger gets a number before it is built, and you decide” is a good answer. “It’s fixed price, don’t worry” is not reassuring; it usually means either a padded quote or an argument later.
4. What does the first usable thing look like, and when?
Beware anyone happy to disappear for four months. You want something you can open and use early, even if it does one thing, because that is when you find out whether the plan survives contact with reality.
If the first deliverable is months away, the risk is entirely yours.
5. Who maintains it, and what does that cost a year?
The build is a one-off. The software is forever — things it connects to change, browsers change, your business changes. A quote that covers only the build is not cheaper, it is incomplete.
Ask for the annual number. If there isn’t one, ask what happens in month seven when something stops working.
6. If I want to leave, what do I take with me?
The best question on the list, because the answer reveals the whole relationship. You should be able to take the code, a copy of the data in a usable format, and the accounts. If leaving is difficult by design, that difficulty is the product.
7. What have you built that I can look at?
Not a portfolio of logos — something working, that they can walk you through and answer awkward questions about.
Ours is the platform we run this business on, and we will happily show it to you. It is also the honest answer to a question we get a lot, because most of our client work is under wraps.
The question they should ask you
If nobody asks what problem you are trying to solve — and pushes back when the answer is vague — be careful. Somebody who takes the brief without examining it is selling you hours, not outcomes.
We talk people out of building fairly regularly, because an existing product usually does the job for a fraction of the cost. That conversation is what a free systems review is, and if the answer is “buy this, don’t build anything”, you have lost nothing by asking.
Bottom line
You are not buying a piece of software, you are entering a dependency. Nearly every question that matters is about how easily you could end it.
Want a hand with this?
Tell us what you're trying to sort out and we'll give you practical, plain-English advice before you spend money.
