How to Choose a Software Partner in Oman: The RFP, the Red Flags, and the Clauses That Matter
Most software projects that fail were lost at selection, not at delivery. The wrong partner was chosen for defensible-looking reasons — the lowest quote, the most impressive slide deck, a recommendation from someone whose project was nothing like yours — and everything after that was the consequence.
This is a buyer’s guide, written by a company that bids for this work. You should read it with that in mind, and the fairest way to handle it is to say up front what this article will not do: it will not list criteria designed so that we win. Several of the tests below are ones any serious buyer should apply to us, and a few of them are tests we would rather you did not skip, because the projects that go badly for a supplier are usually the ones where nobody asked.
Before you contact anyone, write down four things
The single biggest cause of incomparable bids is an unclear brief. If five suppliers are guessing at what you want, you will receive five different guesses and no way to compare them.
You do not need a specification. You need four answers, in writing, in about two pages:
1. What decision or process is broken. Not “we need a system” — what happens today, who does it, how long it takes, and what it costs when it goes wrong. A supplier who understands the problem can propose something better than what you asked for. A supplier who only has your feature list cannot.
2. What “working” looks like in numbers. Orders processed per day. Days to close the month. Hours a week someone spends re-keying. Pick two or three measures you would actually check twelve months later. This is also the raw material for your acceptance criteria, which is why it matters more than it looks.
3. What already exists and must keep working. Every system the new one has to talk to, every export somebody depends on, every spreadsheet that turns out to be load-bearing. This list is always longer than the first draft. It is also the single largest driver of cost variance between bids — a supplier who did not know about your two legacy integrations quoted a different project than the one you have.
4. Your constraints, including the ones you find awkward. Budget range, deadline and why, whether tenders you bid for score In-Country Value, whether the data is subject to Oman’s data protection law, whether you have anyone in-house who can run this afterwards. Withholding the budget in the hope of a lower quote mostly produces proposals aimed at a different company.
If writing those two pages is difficult, that difficulty is the finding. It is not a reason to delay — it is the thing to discuss in the first meeting, with a supplier who is willing to charge for a short scoping engagement rather than guess for free.
The RFP that makes bids comparable
Comparability comes from structure, not length. A ten-page request that forces the same shape of answer from everyone beats a sixty-page specification that invites everyone to answer differently.
Ask every bidder for the same seven things:
- Their understanding of the problem, in their own words. The most informative page in any proposal. If it is your brief rephrased, they have not thought about it yet.
- The proposed approach, with the parts they are uncertain about named. Certainty across the board is not confidence, it is inexperience or salesmanship.
- A phase breakdown with deliverables and dates, where each phase produces something you can see and judge.
- The team, by name and role, with the proportion of their time this project gets. This is where the gap between the pitch and the delivery usually opens.
- A price broken down by phase, plus what is explicitly excluded, plus the day rate for work outside scope.
- The support arrangement after go-live, with response times and what they cost.
- Two references on comparable work, with permission for you to contact them directly.
Give everyone the same deadline and answer questions by circulating both the question and the answer to all bidders. It costs you nothing and it tells you which suppliers read carefully — the questions you receive are often more diagnostic than the proposals.
One thing to resist: asking for a fixed price against a brief you have described as two pages. You will get one, and it will contain a risk premium you cannot see, or an assumption you will discover in month three. Fixed price is reasonable for a phase whose scope is genuinely settled. Across a whole discovery-to-delivery project, it mostly transfers risk into the contract rather than removing it.
The seven red flags
In rough order of how much damage they do.
1. A price quoted before anyone asked what your systems currently do. Software cost is driven by integration and data quality, and neither is visible from a feature list. A number produced without that conversation is a guess, and you will pay for the guess either in change requests or in a rushed build.
2. No named team. “Our developers” is not an answer. You are buying specific people’s time. Ask who, ask what else they are working on, and ask what happens if that person leaves mid-project.
3. Every requirement is met, without qualification. Real systems involve trade-offs. A supplier who agrees to everything either has not understood the requirements or intends to renegotiate later. The best proposals contain at least one paragraph explaining why something you asked for is a bad idea.
4. The demo is a different product than the proposal. A polished demonstration of a platform is evidence the platform exists. It is not evidence that the platform does what you need, and the gap between the two is where budgets go. Ask to see the specific workflow you described, even roughly, even badly.
5. Ownership of the code and data is vague. If the contract does not say plainly that you own the work you paid for and can take your data out in a usable format, assume you do not and cannot. This one is covered below because it deserves its own section.
6. No process for changing anything. Requirements will change. A supplier with no written change process is not a flexible supplier — they are a supplier who will handle changes by argument, at the worst possible moment.
7. Pressure on the timeline that comes from them rather than from you. Discounts expiring, a slot in the schedule about to be filled, a price valid until Thursday. These are sales instruments. A supplier confident in the work does not need you to decide this week.
An eighth, harder to detect and worth more than the rest: a supplier who never tells you no. You are hiring judgement as much as capacity. If everything you suggest is a good idea, you have hired a pair of hands and you are still the only person responsible for whether the system makes sense.
The five clauses that decide what you actually own
Most disputes are not about quality. They are about what was promised, who owns it, and what happens at the end. Five clauses carry almost all of that weight.
Intellectual property
State explicitly that on payment, ownership of the custom work developed for you transfers to you. Then handle the part most contracts leave silent: suppliers reuse internal libraries and frameworks, which is normal and usually to your benefit. What you need is a licence to keep using them, perpetual and irrevocable, so that a component you never knew about cannot become leverage later.
Third-party components have their own licences. Ask for the list.
Source code and handover
Ownership without possession is a theory. The contract should say where the code lives and that you have access to it throughout — not delivered at the end, but visible from the first week, in a repository you can see. The same applies to infrastructure: accounts in your company’s name, with the supplier holding access, rather than the reverse.
Escrow is a reasonable answer for licensed platforms where you will not hold the code. For custom work you commissioned, it is a worse version of just having the repository.
Acceptance criteria
Write down what “done” means before work starts, in the language of your business rather than the supplier’s. Not “the invoicing module is complete” — “an invoice can be raised, approved, sent and settled, and the resulting figures reconcile to the ledger.”
Tie payment milestones to these. This is the clause that most reliably prevents the argument at the end, and it is the one buyers most often leave until the end, by which time it is a negotiation instead of a definition.
Support, in specifics
Response time is not fix time. Define both, define severity levels, define working hours and what happens outside them, and define what is included versus billable. A support agreement that promises “ongoing support” without those four things has promised nothing measurable.
Also settle the boring question of who pays when the platform underneath you changes — a payment gateway deprecates an API, a tax rule changes, an operating system update breaks a dependency. That work is certain to arrive.
Exit
The clause nobody wants to discuss at the start, which is exactly why it should be discussed at the start, while goodwill is at its maximum. What happens if you want to leave: how much notice, what gets handed over, in what format, at what cost, and how long they will help your next supplier. A supplier who is comfortable with a clear exit clause is telling you something about how they expect to retain you.
How to read three quotes that are wildly different
You will get a low bid, a middle bid and a high bid, and the spread will be larger than seems reasonable. It usually is not irrational. It is usually four things:
Different scope. The most common by far. Compare what is excluded, not what is included. The low bid frequently omits data migration, testing, training and the second integration.
Different assumptions about your data. A supplier who assumes your existing records are clean quotes a shorter project than one who has seen this before. Ask each bidder what they assumed about data quality, and what changes if the assumption is wrong. The answers will separate them fast. Our own note on what custom software really costs covers where this money actually goes.
Different levels of seniority. Two developers at different rates is a real cost difference and also a real capability difference. Neither is automatically right; a straightforward system built by mid-level developers with good supervision is often the correct purchase.
Different amounts of risk priced in. A supplier who has read your brief carefully and seen the ambiguity may have priced the ambiguity. That premium disappears if you resolve the ambiguity, which is an argument for a paid discovery phase — a small, fixed, time-boxed engagement that produces a specification you then take to bid. It converts the largest unknown into a known before anyone commits to a number.
If a quote is dramatically below the others, the correct response is not suspicion or delight. It is one question: what did you assume that the others did not?
Questions to ask their references
References are almost always positive, so the useful questions are not about satisfaction. They are about behaviour under difficulty:
- What went wrong, and how did they handle it? Every project has something.
- Did the people who pitched do the work?
- How were changes to scope handled commercially?
- What was the gap between the estimate and the final number, and why?
- Since go-live, how quickly do they respond, and has that changed?
- Would you use them for something larger? (This one produces more honesty than “would you recommend them.”)
- What did you have to do that you did not expect to have to do?
That last question is the most valuable in the list. It is where you learn how much of the project lands on your side of the table — because it always does, and the projects that fail are frequently the ones where the buyer never budgeted for their own people’s time.
What to check specifically in Oman
Four things that are locally relevant and easy to verify:
Registration and the ability to invoice you properly. From the dates in Oman’s e-invoicing mandate, a supplier’s own invoicing has to be compliant too. It is a small thing that tells you whether they are paying attention to the same obligations they are advising you on.
Where they will host your data, stated before you sign. This is a regulated decision, not a preference — see where your data is allowed to live. A supplier who has not thought about it will default to whichever region their tooling picked.
Whether they can genuinely deliver Arabic. Bilingual is not a translation layer bolted on at the end; it changes layout, data entry, sorting, reporting and printed documents. If Arabic matters to your business, ask to see a working Arabic interface, not a translated screenshot. We wrote separately about what building bilingual software actually involves.
Who operates it after they leave. Related to your Omanisation obligations and your technology team, and to whether the system you are buying is one your business can staff. A design that requires three specialists you cannot hire is a design that will fail slowly.
A note on how to weigh all of this
Do not build a scoring matrix with twenty weighted criteria. It produces a number that feels objective and hides the two or three things that will actually determine the outcome.
The three that do: have they solved a problem structurally like yours before, will the people who impressed you do the work, and can you have a difficult conversation with them. Everything else in this article is a way of testing those three from the outside.
The last one is not soft. Every project of any size reaches a week where something is wrong and someone has to say so. Whether that conversation is possible is decided long before it happens, and you can usually sense it during the bid — in whether they disagreed with you about anything, and how that went.
Frequently asked questions
Should I choose a local supplier or an international one? It depends on what fails if you choose wrong. Local matters most when the work touches Omani regulation, Arabic, in-person operational knowledge, or tenders where in-country spend is scored. International may be right for specialised product work with no local dependency. The failure mode to avoid is a supplier in a distant time zone with no local presence handling a system your operations staff need help with daily.
Is a fixed price safer than time and materials? Fixed price is safer when scope is genuinely settled — which usually means after a discovery phase, not before one. Fixed price against a vague brief buys you a risk premium and a supplier motivated to argue about scope. A common middle path is fixed price for discovery, then fixed price per delivery phase once the specification exists.
How long should selection take? For a mid-sized business system, two to six weeks from brief to decision is normal and sufficient. Shorter usually means you did not compare properly. Much longer usually means the internal decision is not actually agreed, which is a problem no supplier can solve for you.
What should a proposal cost me? Nothing, for a proposal. But a serious estimate for a complex system requires real analysis, and a supplier offering that for free is either amortising it across their winning clients or not doing it. Paying for a short, defined discovery engagement — with the deliverable owned by you and usable with any supplier — is usually the cheapest money in the whole project.
Do I need a technical person on my side? For anything substantial, yes. Not necessarily an employee — an independent adviser for a few days across the bid and the contract is enough. Buying software with no technical representation is the situation every red flag in this article is designed to exploit.
What if the project is already going badly? Stop and establish the facts before deciding anything: what was agreed in writing, what has been delivered, what you own and can access today. Most recoverable projects are recovered by fixing scope and acceptance criteria, not by changing supplier. The patterns are covered in why ERP and CRM projects fail; changing supplier mid-project is expensive and sometimes still correct.
This article is general guidance for business readers as at 21 August 2026, not legal advice. Have any contract reviewed by a qualified adviser before signing.
Sources: Oman Tax Authority · Ministry of Commerce, Industry and Investment Promotion — business services
About us: ZAWAT builds custom software, business systems, web platforms, e-commerce, AI automation and integration and support. Our delivered work is documented — including Al Jazeera Steel and Lynnify — and you are welcome to apply every test above to us. Book a call.