Free checklist

12 questions to ask before you pay a software company

Most software projects here do not fail in the code. They fail in the conversation before the code, where nobody wrote down what was being bought, and both sides remembered it differently six months later.

This is the list of questions we would want asked of us. Use it on us too. If a studio cannot answer one of these plainly, that is the answer.

Before you agree on a price

  1. What exactly am I paying for, written down?

    A straight answer: A scope document that names the screens, the user roles and the reports. Not "a complete management system". If the list is short enough to argue about, it is specific enough to build.

  2. What is not included?

    A straight answer: Anyone who has thought about your project can name three things they are leaving out. Anyone who cannot has not thought about it yet.

  3. What would change this price later?

    A straight answer: The usual triggers named upfront: extra modules, moving your old data in, connecting to a bank or a courier, training days, work outside office hours.

  4. Can I see something working before I pay in full?

    A straight answer: Payments tied to working milestones you can log into yourself, not to calendar dates or to percentages of an invisible whole.

While it is being built

  1. Who owns the code and the data when this is finished?

    A straight answer: You do, and it says so in the contract. Ownership that depends on goodwill is not ownership.

  2. Where does my data live, and can I export all of it?

    A straight answer: A named country and provider, and an export to Excel or CSV you can run yourself, whenever you want, without asking permission.

  3. Who actually writes it?

    A straight answer: How many people, which of them are on your project, and whether any of it is passed to somebody else. Subcontracting is fine. Not being told is not.

  4. How will I see progress?

    A straight answer: A link to something running that you can open on your own phone. Screenshots in WhatsApp are a report about the work, not the work.

After it goes live

  1. What does support cost, and what does it cover?

    A straight answer: A bug in their code and a feature you thought of later are two different things. Both should have a price, and the difference should be written down before you need it.

  2. How fast do you answer when I cannot take payment?

    A straight answer: The answer should not be one number. "The shop cannot bill" and "the report is missing a column" deserve different promises.

  3. What happens if we stop working together?

    A straight answer: A handover you could hand to another developer: the code, a database export, the deployment accounts, and enough documentation to run it.

  4. Who else can I call?

    A straight answer: One customer doing something close to what you do, on the phone, willing to talk. A logo on a website is not a reference.

If you get straight answers to all twelve, you are probably in good hands, whoever you hire. If you get twelve straight answers and still want a second opinion on the scope, send it to us and we will read it.

Free checklist

12 questions to ask before you pay a software company

A checklist for anyone buying custom software in Bangladesh, with what a straight answer to each question actually sounds like.

One email with the checklist in it. We write occasionally about what we learn building these systems, and every message has an unsubscribe link.