How to choose a custom software vendor: questions, red flags and a scorecard.

Start with a one page brief

Most bad vendor choices start with a vague request. If you ask five companies to "build us an app", you will get five proposals for five different products, and you will have no fair way to compare them. Before you contact anyone, write a brief of about one page. It does not need technical language. It needs to answer these questions:

• The problem. What is going wrong today, in plain words? For example: "Leave requests arrive by WhatsApp and get lost, and we cannot see who is off next week."
• The users. Who will use the system, roughly how many of them, and on what devices? Staff on phones and managers on laptops are different needs.
• The must haves. The five to ten things the first version cannot launch without.
• The nice to haves. Things you would like later. Listing them separately stops them sneaking into the first quote.
• Existing tools. What it must connect to: your accounting software, a payment provider, email, a government portal, a spreadsheet you rely on.
• Data. What personal or sensitive data it will hold, such as staff records, customer contact details or ID numbers.
• Timing and budget range. A real deadline if there is one, and a budget range. Sharing a range is not weakness; it lets vendors propose something realistic instead of guessing.

Send the same brief to every vendor. That single step makes the rest of this guide work.

How many vendors to talk to

Three is usually enough. Fewer and you have nothing to compare; many more and you will spend weeks in meetings and start choosing on fatigue. Look for vendors who have built something of similar shape before, not necessarily in your industry. A team that has built booking systems will understand your clinic booking problem faster than a team that has only built marketing websites.

Questions to ask in the first meeting

The point of the first meeting is to see how the vendor thinks, not to hear a pitch. Good questions invite specific answers.

About their understanding

• "What would you leave out of the first version, and why?" A good vendor will push back on scope. A vendor who agrees to everything is either not listening or planning to charge for it later.
• "What part of this do you think is hardest?" Their answer shows whether they have actually thought about your problem.
• "What questions do you have for us?" Silence here is a warning sign.

About the team

• "Who will actually build this, and can we meet them?" Find out whether the people in the meeting are the people doing the work, or whether it will be passed to another team or a sub-contractor.
• "Who is my day to day contact, and how quickly do they usually reply?"
• "What happens if a key person leaves during the project?"

About past work

• "Can you show us a system you built that is in use today?" A live demo beats a screenshot.
• "Can we speak to a client whose project went badly, and hear how you handled it?" Every honest vendor has had a difficult project. How they talk about it tells you a lot.

About the way they work

• "How often will we see working software?" You want to see real progress every one or two weeks, not a big reveal at the end.
• "How do you handle a change request in the middle of the project?"
• "How do you test before something goes live?"
• "Where will the system be hosted, and who pays for hosting?"

Red flags worth taking seriously

• A firm price after a 20 minute call. Nobody can price a custom system accurately without understanding it. Either the price is padded heavily or the scope will be cut quietly.
• No questions about your data. If a vendor does not ask what personal data you will store, they will not protect it properly either.
• "We own the code" or vague answers about ownership. Covered in detail below.
• Large upfront payment with no milestones. Paying most of the price before seeing anything puts all the risk on you.
• No written scope. If the proposal is a single price and a list of feature names, there will be arguments later about what each name meant.
• Pressure tactics. "This price is only valid until Thursday" has no place in a software purchase.
• They cannot explain things simply. Jargon in the sales meeting usually means jargon in every status update after it.

Fixed price or time and materials?

These are the two common ways to pay for custom software. Neither is always better.

Whatever the model, ask for payments tied to things you can see: a working prototype, a first release you can test, go-live, and the end of a warranty period.

Ownership: code, domain and accounts

This is the single most important contract point, and the one most often ignored. At the end of the project you should own, or have full control of:

• The source code, stored in a repository you can access, such as a company account on a code hosting service.
• The domain name, registered in your company's name and on your account.
• Hosting and cloud accounts, either in your name or with you as an administrator who can add and remove people.
• Third party services such as email sending, maps, payment gateways and app store developer accounts.
• Documentation good enough for another competent team to take over.

Vendors sometimes reuse their own libraries or frameworks across clients. That is normal and can save you money. The contract should then give you a permanent licence to use those parts, so you are never locked in.

Personal data and the PDPL

If the system holds personal data about staff or customers, Bahrain's Personal Data Protection Law (Law No. 30 of 2018) applies to how that data is collected, stored and processed. Your company remains responsible for the data even when a vendor builds or hosts the system. In practice, ask the vendor:

• Where will the data be stored, and in which country?
• Who on their team can see production data, and is that access logged?
• How are backups taken, and how would you get a full copy of your data if you left?
• Will they sign a data processing agreement that sets out these points?

The PDPL has specific rules, including on transfers of data outside Bahrain. This guide is not legal advice; check current requirements with the Personal Data Protection Authority or a lawyer for anything beyond the basics.

Handover and support after launch

Software needs care after it goes live: security updates, small fixes, and changes as your business changes. Ask each vendor:

• Is there a warranty period during which bugs are fixed at no charge? How long is it?
• After that, what does support cost, and what does it include? Response times, number of hours, what counts as urgent.
• If we choose to move to another team, what will you hand over, and will you cooperate?

A simple scorecard to compare proposals

Once you have the proposals, score each one against the same criteria. Give each criterion a weight that reflects what matters to you, then score each vendor from 1 to 5.

Notice that price is only one row. Cheap software that fails costs far more than its price.

Worked example: scoring two proposals

A trading company with 40 staff wants a system to track customer orders and deliveries. It sends the same brief to two vendors.

Vendor A sends a polished proposal within two days with a low fixed price. The scope is a list of eight feature names. They did not ask about data. The code stays on their servers and the client receives a licence to use the system.

Vendor B asks for a second meeting, suggests dropping two features from the first version, and sends a screen by screen scope with four milestones. The price is higher. The client owns the code and all accounts.

Scoring each from 1 to 5 and applying the weights:

Vendor A wins on price but loses clearly overall. The scorecard also gives you something concrete to show a partner or board when you explain the decision. If two vendors score close together, ask both for a small paid discovery piece, such as clickable wireframes, and choose based on that.

Contract points to check before signing

1. A written scope as an annex, ideally with screens or user stories.
2. Milestones, what is delivered at each, and the payment linked to it.
3. Ownership of code, domain, accounts and data, transferred to you on payment.
4. A change request process: how changes are estimated and approved in writing.
5. Acceptance: how long you have to test each delivery, and what counts as a defect.
6. Warranty period and the support terms after it.
7. Confidentiality and a data processing clause in line with the PDPL.
8. Exit: what happens, and what is handed over, if either side ends the contract.

Frequently asked questions

Should we choose a local vendor or an overseas one?

Both can work. Local teams are easier to meet, understand local rules and work in your time zone. Overseas teams can be cheaper but need clearer written scopes and more management time. Judge each on the scorecard rather than on location alone.

Is it worth paying for a discovery phase?

Often, yes. A short paid phase that produces a detailed scope and wireframes reduces risk for both sides, and the output belongs to you even if you then choose another vendor to build.

How do we check a vendor's references?

Ask for a client contact and call them. Ask what went wrong and how it was handled, whether the project finished on time and on budget, and whether they would hire the vendor again.

What if we already signed and do not own the code?

Raise it with the vendor now, while the relationship is good. Many will agree to transfer ownership or place the code in an escrow arrangement, sometimes for a fee. It is much harder to negotiate during a dispute.

Can we use a no-code tool instead?

For simple internal workflows, sometimes. The same questions apply: who owns the data, what happens if prices change, and can you export everything if you leave.

If you would like a second opinion on a brief or a set of proposals, you can get in touch with RAL.

This article is general information, not legal or procurement advice. For contract terms and data protection obligations, take advice specific to your situation.