Clients ask how to choose a good supplier. Very few ask the reverse question, which is at least as consequential for what the project costs and how it goes.
Suppliers price uncertainty. A meaningful share of the uncertainty on any software project comes from the client side rather than from the technology, and it is priced into your quote whether or not anybody names it. The difference between a client who decides quickly and one who does not is not a matter of politeness. It shows up in the number.
This article is what a supplier would tell you if the commercial relationship allowed it.
The two clients, priced
Worth making concrete, because "suppliers price uncertainty" stays abstract until you see where the money goes.
Two businesses ask the same supplier for the same system. Same scope, same complexity, same deadline.
The first has a named decider who answers within two days, sends feedback once and complete, and supplied its brand assets and API credentials in week one because somebody tracked them as tasks. The supplier can plan a continuous run of work. Nobody sits idle waiting. The estimate does not need much protection, because the main thing that would break it is not present.
The second has four stakeholders and no decider, takes two to three weeks to respond, and sends feedback in pieces as each person gets to it. Half the credentials arrive in month two. The supplier cannot plan a continuous run, so people either sit idle at your cost or get moved to another project and come back having lost context. Work gets done twice. The estimate has to carry all of that.
A supplier who has met the second client before, or who suspects they are looking at one, does the only rational thing and pads. Not dishonestly, and not itemised anywhere. It just becomes the number.
The uncomfortable part is that the second client experiences the higher price as the supplier being expensive, and experiences the delays as the supplier being slow. From inside, the pattern is invisible. That is the whole reason this article exists, because nobody in the commercial relationship is well placed to tell you.
The five things that cost your supplier time
None of them is technical.
Decisions that take weeks. A design choice or a business rule goes out and sits. The team either stops, which you are paying for, or guesses and continues, which means the work may be redone when the answer arrives.
Several people, no decider. Three opinions with nobody empowered to break a tie produces the same delay as silence, then adds rework when the informal compromise is overruled by whoever was not in the room.
Content and access arriving late. Copy, images, brand assets, API keys, sandbox credentials, a working test account with a third-party system. These sit squarely on the critical path and are invisible to you as development work, which is exactly why they slip.
Feedback in fragments. One review returned as three messages over five days, each revising the last, costs considerably more than the same feedback delivered once and complete, because each fragment triggers work the next one invalidates.
Small additions agreed verbally. Nothing changes the plan or the date, and the cumulative effect is real even though no individual conversation was unreasonable.
Read that list again and notice that all five are entirely within your control, cost nothing to fix, and require no negotiation with anybody.
Decisions: set a response budget
Agree a target at the start and treat it as a commitment. Two working days for a routine question, five for anything genuinely needing several people.
The specific numbers matter less than their existence. A supplier who knows your response time can sequence work around it. A supplier who does not know has to guess, and guessing conservatively is what padding is.
If your organisation is genuinely slow at approvals, say so rather than presenting an aspiration you will miss every time. A supplier told that approvals take three weeks can plan around three weeks. One told two days builds a plan that breaks in week one and then spends the rest of the project explaining why.
And notice what it means if your supplier never chases you for decisions. It usually means they are guessing, which is worth knowing about your own project.
Name one person who decides
Consultation and decision-making are different activities, and merging them is what causes the paralysis.
Involve whoever genuinely needs involving. Then name one person who decides once they have been heard. Say explicitly who is consulted, who is informed, and who decides.
Suppliers do not need you to have fewer stakeholders. They need to know which one to ask when the answers conflict, and they need that person to be reachable.
Feedback that can be acted on
Two habits, and they compound.
Send it once, complete, in one place. Gather everything, resolve internal disagreements before sending, and deliver a single consolidated response with a named owner. The fragmented version is not just annoying, it is measurably more expensive.
Describe the problem, not the fix. "I do not like it" is not actionable and will produce a guess and a second round. "On the checkout page, customers will not understand what this field is asking for" is actionable, and it lets a supplier apply the expertise you are paying for to a problem you have correctly identified as yours to raise.
That distinction runs right through the relationship. UK government guidance for buying digital work states the principle plainly: buyers write requirements to tell suppliers about their situation or problem, and suppliers propose a solution that meets those needs [1]. Specifying the solution yourself means buying your own guess at full price. Our guide on writing a software brief covers how to do that properly at the outset.
None of which means never disagreeing on technical matters. Where you have genuine grounds, say so and say why, and label it as a preference rather than an instruction. A supplier who cannot defend a technical decision in plain language has a problem you want to know about.
Track your own obligations
Most project plans show what the supplier owes you and leave what you owe them implicit. That asymmetry is where a surprising amount of delay lives.
Ask for your list separately at the start, with dates against each item, and track it the way you track theirs. It converts a vague sense of being chased into a small number of tasks with owners and deadlines, which is a much easier thing to manage.
The small ask that is not small
Scope creep is almost never one large request. It is a series of small, reasonable-sounding additions agreed verbally, none of which individually seemed to warrant updating the plan.
There is a single question that prevents most of it: does this change the date or the price? Ask it in the meeting, at the moment of asking, not afterwards.
Most suppliers will not volunteer the answer, partly to be accommodating and partly because saying no to a client feels commercially risky. Asking makes it safe for them to be honest, and it keeps the plan matching reality rather than drifting from it silently.
Adding scope mid-project is entirely legitimate when the business needs it. The problem is only ever the addition that arrives without a corresponding change to the plan. Handle it as a documented variation with its own price and its own effect on the date, and both sides stay honest. Our guide on reading a software proposal covers how variations should work.
The client has a defined job
This is not merely good manners. In public procurement it is written down as a role with responsibilities.
US federal guidance on agile contracting describes the government product owner as retaining responsibility for making decisions and managing the process, approving the specific plans for each iteration, and approving deliverables [2]. The buyer is defined as an active participant with decisions to make on a cadence, not a recipient waiting for delivery.
That framing is worth adopting even where nothing about your project is governmental. If nobody on your side holds that role, it is unfilled, and the supplier will end up making those decisions by default. They will make them reasonably and they will make them without knowing what you know.
What to demand in return
Being a good client is not the same as being an easy one, and the two get confused.
Demand a demonstration rather than a status report. A named list of what remains. Honesty about what is blocked and on whom. Early warning when something slips, rather than an explanation once it has. And a straight answer when you are the problem.
That last one needs active encouragement, because it will not happen by default. A supplier who has learned that disagreement is unwelcome will quietly build what you asked for, including the parts they know are wrong, and you will find out after paying. Ask directly and more than once what they think you are getting wrong.
Four questions get you better information than any status meeting: what is demonstrably working right now, what remains by name, which of those has never been started, and what is blocked and on whom. Our guide on a project that is running late covers what the answers tell you.
Being a good client is not the same as being an easy one
Worth separating these two, because they get merged and the merge is expensive.
An easy client approves quickly without reading, accepts the first thing shown, does not push on estimates, and never raises a problem until it is serious. That feels pleasant to work with and it produces worse software, because nobody is applying pressure at the points where pressure improves the result.
A good client is fast but not passive. They decide quickly, and they read what they are approving. They push back on an estimate by asking what is in it rather than by asking for a discount. They raise a concern in week two instead of storing it until month three. And they say plainly when something is not good enough, early, while changing it is still cheap.
The distinction shows up most clearly at demonstrations. An easy client watches the demo and says it looks great. A good client asks to drive it themselves, with their own data, and finds the thing that breaks. The second is more uncomfortable for everybody in the room and is worth considerably more to both sides.
The same applies to bad news. A client who reacts badly to problems being raised early is training their supplier to raise them late, which is the opposite of what they want. How you respond the first time somebody brings you a genuine problem sets the pattern for everything after it.
Involvement, in the right places
Daily interruption of individual developers substitutes activity for oversight. What you actually want is regular structured contact with somebody who can answer for the whole project, plus the ability to see working software at agreed points.
For most projects that means one substantive weekly session with a demonstration attached, and a fast channel for questions in between. Daily calls are usually a symptom rather than a cure. What matters more than frequency is that somebody with authority attends and that the meeting produces decisions rather than updates.
The one place to be more involved than most clients are is testing. You know things about your business that no test plan captures, including the cases that occur twice a year and break everything. Set aside real time for it rather than treating it as a formality at the end, because a problem found during the build is dramatically cheaper than the same problem found after launch.
What difficult costs, invisibly
None of this appears on an invoice, which is precisely why it is worth stating.
A client known to be difficult gets quoted with more padding. They get the team that is available rather than the team the supplier would prefer to assign. They get less discretionary effort on the parts nobody specified, which on software is a large surface. And they are first to be deprioritised when the supplier has a capacity problem, which every supplier eventually does.
In a market the size of the UAE, reputations also travel further than most clients assume. More practically, the same supplier remembers. The rate you are quoted for the second project, and whether they are keen to take it at all, is shaped by how the first one went in ways that have nothing to do with the technical work.
On payment specifically: pay for what has been delivered, and raise disputes separately and explicitly. Withholding payment as an unstated protest reads as a cash flow problem or bad faith, and it moves you down the list of a business with other clients. If you want to withhold for a stated reason, say the reason and say what would resolve it.
Twenty minutes, before the next project
Write down three things and share them with your supplier.
Who decides. How quickly you will respond to questions. And what you owe them, with dates against each item.
That single page prevents more delay than any amount of project management applied afterwards. Most clients have never written down any of the three, which is why the two changes with the largest effect, consolidating feedback and naming one decider, are also the two that cost nothing at all.
If you want an outside view, a review of a proposal, a brief, or how an in-flight engagement is being run starts from around AED 1,500 with us. That covers where time is genuinely being lost and how much of it sits on your side rather than theirs. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- GOV.UK, buying through the Digital Outcomes and Specialists framework
- TechFAR Hub, planning for agile
- US Digital Services Playbook
- SKIMBOX, how to write a brief for a software project
- SKIMBOX, how to read a software proposal
- SKIMBOX, your software project is late again
The UK and US government guidance cited above governs public sector procurement in those countries. It is referenced for the underlying practice, which applies broadly, rather than as a rule binding private buyers in the UAE.
