Choosing who builds your system is one of the few decisions that is expensive to undo. The proposal will look professional whoever wrote it. The way to tell vendors apart is to ask questions whose answers cannot be polished in advance.
Here are the twelve we would ask if we were in your seat.
Ownership
1. Who owns the source code, the data and the documentation?
A good answer: you do, from the first day, written into the contract. The code is kept in a repository you can access.
A warning sign: “We license the system to you”, unless that is clearly what you are buying and the price reflects it.
2. If we stop working together, can another team take over?
A good answer: yes, because the system is documented, uses common technology, and the vendor will hand over everything needed. Ask to see documentation from a past project.
3. Can we export all of our data at any time?
A good answer: yes, in a standard format, without asking permission or paying a fee.
Delivery
4. When will we see something working?
A good answer: within the first few weeks, and then every week or two. You should be able to click through a real version long before go-live.
A warning sign: months of design documents before any working software.
5. What happens when we change our minds?
Requirements change in every project. A good answer explains a simple process: changes are written down, estimated, agreed and scheduled, and nothing is changed silently.
6. Can we see a system you built, running?
Screenshots and slides prove little. Ask for a demonstration of a live system, or a call with a client who uses one every day.
Security and reliability
7. How is our data protected?
Listen for specifics: encryption in transit and at rest, access by role, two-step sign-in for administrators, an audit trail of who changed what, and tested backups. Ask how the system handles personal data under Ethiopia’s data protection law.
8. What happens when something breaks at night?
A good answer names who is alerted, how they are reached and how quickly they respond, and puts it in a support agreement.
9. Where will the system be hosted, and who pays for it?
You should know where your data lives, who holds the hosting account and what it costs each month. Ideally the account is in your organisation’s name.
People and support
10. Who exactly will work on our project?
Ask to meet the project lead and the senior engineer. The people who present the proposal are not always the people who build the system.
11. How will our staff be trained?
A good answer includes training for each role, in the language your staff use, written guides, and a second session after people have used the system for a few weeks.
12. What does support look like after go-live?
Ask what is included, what is extra, how requests are made and how fast they are answered. Get it in writing, with response times.
How to use these questions
Send all twelve to every vendor on your shortlist and ask for written answers. Then compare them side by side, along with prices for the same written scope. The differences will be obvious.
These are the questions we expect to be asked ourselves, and we answer them in writing before any agreement. If you would like our answers for your project, start a brief.