The questions to ask a software house — when technology is not your thing

Why the less you know, the more you should ask

There is a natural instinct, when technology is not your field, to keep the questions to a minimum — so as not to look naive, or because you assume you will not follow the answer anyway. That instinct is exactly wrong. You are not there to judge the code; you are there to judge the people. And you already do that well, every day, with suppliers, staff and customers.

Nobody choosing an accountant checks the tax calculations personally. They ask how the work is done, what it costs, what happens when something goes wrong — and they listen to how the answers are given. A software house is no different. The questions below fall into four groups, each with a hint about what a good answer sounds like.

Questions about understanding: did they actually hear you?

1. “Tell me in your own words what you understood about my business.” This is the most important question of all, and the end of the first meeting is the right moment for it. If the answer is a list of screens and technologies, they were not listening. If it sounds like a description of a working day in your business, irritations included, they were.

2. “What would you advise me not to build?” A firm paid by the volume of work is tempted to say yes to every idea. One that can say “keep that in the spreadsheet for another year” or “that is not worth the money” is thinking about your outcome rather than its invoice. We wrote about the price of “just one more feature” in more features, more mess.

3. “Who on my team would you like to talk to?” A good answer asks to meet the people who will use the system day to day — the receptionist, the storekeeper, the employee who has been there twenty years — and not only the person paying. A system designed around the manager alone looks excellent in a demo and is abandoned within a month.

Questions about money: what is included, and what comes later

4. “Is the price fixed, or by the hour?” Both are legitimate, but you need to know which one you are getting. By the hour, every change, misunderstanding and delay lands on you. At a fixed price, the risk moves to the software house — which is why it will invest more in understanding the job before starting. Ask, too, what happens when you request a change halfway through.

5. “What will it cost me to keep this running in the first year after launch?” Hosting, domain, licences, bug fixes, security updates, small changes. A quote that cannot answer this is a quote waiting to surprise you. We broke the items down in what it costs to own a website or an app.

6. “What exactly is not included?” A simple question that reveals a lot. Moving data from the old system, training, legally required accessibility, a link to your accounting software — any of these can be “included” in conversation and an “extra” on the invoice. Ask for it in writing.

Questions about ownership: what is yours the day after

7. “Who owns the code?” This is where many people get a late surprise. Under Israeli copyright law, as in a number of other countries, the first owner of a commissioned work — and code is a work — is its creator, unless agreed otherwise. If the contract is silent, what you paid for may not be yours. The good answer is an explicit clause in the contract and real access to the code.

8. “Where will the data be stored, and who will be able to reach it?” The answer should cover a place (which cloud, which country), people (who on their side can see the information) and an exit (how you get a complete copy). When a supplier handles personal data on your behalf, Israel's data security regulations require the arrangement to be set out in an agreement — it is not just a matter of trust. We covered the wider question in where your data actually lives.

9. “What happens if you close down, or if we want to move to someone else?” This is not an insult; it is a professional question. A good answer describes an orderly handover: code, passwords, documentation and data. An evasive one is a bigger warning sign than any price.

Questions about use: how you will know it worked

10. “How will we know the project succeeded?” If the answer is “when the system goes live”, it is the wrong answer. A system succeeds when your people use it without drifting back to the notebook. We wrote about this in the system that needs no training.

11. “Can I speak to a client who has used your system for a year?” Not someone who received a website last month, but someone who lives with the product. Ask them what happened the first time something broke, and how long the fix took.

12. “What happens when something stops working on a Friday afternoon?” You do not need a round-the-clock operations room. You do need to know whom to contact, through which channel, and how long before somebody at least replies.

How to listen when you do not know the terms

You do not have to understand every word. You do have to notice three things. First, whether they translate for you without being asked. People who understand something deeply can explain it simply; people who hide behind terminology are usually hiding something, if only their own uncertainty. Second, whether “it depends” comes with a follow-up. “It depends” is an honest answer, provided it is followed by “on what, and how we will find out”. Third, whether there is an answer in writing. Anything said in a meeting that matters to you, ask to receive by email. People who stand behind their words have no trouble writing them down.

One more thing: if you leave a meeting feeling stupid, that is not your fault. A software house that makes a client feel that way in a sales meeting will make your staff feel the same way in front of its system. And if you are tempted to skip the software house and build it yourself with an AI tool, we weighed that honestly in I built an app with base44 — why pay anyone?

Want to try the questions out on someone? Write to us about what you are planning, and we will answer all twelve — in writing and in plain language. You can also see what we have built in our portfolio.