You cannot review their code. That is a fixed constraint rather than a gap to be closed, and most advice on this subject either ignores it entirely or hands you a list of technical questions to ask without explaining how you would evaluate any of the answers you get back.
So set it aside. Whether somebody writes competent code is one factor among several, and it happens to be the only one you genuinely cannot judge. Everything else that determines whether this works out is visible to a non-technical person paying careful attention.
This is what to look at instead: how to read a proposal, what relevant experience actually means, the questions that work without technical knowledge, how to check references properly, and the one method that outperforms every interview by a wide margin.
What you are actually assessing
Three separate questions, and they fail in different ways.
Can they build this particular thing? Not general ability, but relevant experience with something comparable. This is the question everybody focuses on.
Will they finish it? This is where engagements actually fail. Not incompetence, but drift, competing commitments, an underpriced job that stops being worth their time, or a problem they hit and did not tell you about.
Can you work with them for months? Communication, responsiveness, whether disagreement is possible. This determines whether the engagement is pleasant or exhausting, and it does not improve over time.
Most hiring processes examine the first question thoroughly, assume the answer to the second, and discover the answer to the third somewhere around month three, by which point changing course is expensive.
What "relevant experience" actually means
The first of the three questions deserves unpacking, because it is where non-technical buyers are most often misled, and usually not deliberately.
Software experience does not transfer as evenly as it appears from outside. Somebody excellent at building marketing websites is not thereby equipped to build a system that handles payments and reconciliation, and somebody who has spent years on internal business systems may be a poor fit for a consumer mobile application. The tools overlap; the judgement does not.
So ask about the shape of the problem rather than the technology. You are not trying to evaluate whether they know a particular language. You are trying to find out whether they have previously solved a problem with the same characteristics as yours.
Four characteristics worth asking about directly:
Has this needed to be reliable in the way ours does? A system that can be down for an afternoon is a different discipline from one that cannot.
Has this handled money, or something equally unforgiving? Financial correctness has its own habits, and they are learned rather than inferred.
Has this had to work for people who did not choose it? Software used by staff who were told to use it fails differently from software people opt into.
Has this had to satisfy an outside party? An auditor, a regulator, a large customer's security review. That constraint changes how something is built from the beginning.
A yes to the ones that matter for you is worth considerably more than a longer list of projects in the right technology. And a candid no, accompanied by an accurate description of what would be new to them, is a better sign than a confident yes with no detail behind it.
Why the portfolio tells you less than it seems
A portfolio shows you finished screens. From a finished screen you cannot tell who built it, how much of it they did, how long it took, whether it worked after launch, whether it was delivered late, or whether the client was satisfied.
It proves something exists with their name attached. That has some value. It has far less than it appears, and it is the easiest part of any application to inflate.
Use it as a source of questions instead. Pick one piece and ask:
What was hardest about this?
What would you do differently now?
What went wrong?
Who else worked on it, and what did they do?
Somebody who genuinely built a thing can discuss its difficulties without preparation, because they lived them. Somebody who did not will produce generalities, or describe a project with no difficulties at all, which is its own answer.
Reading a proposal you cannot technically evaluate
Before any of this, most people receive a written proposal, and the temptation is to judge it on how professional it looks. Presentation is the cheapest thing in a proposal to get right, so it tells you almost nothing.
Four things do tell you something, and none requires technical knowledge.
Does it restate the problem in their own words? A proposal that opens by describing your situation more clearly than you described it is evidence that somebody understood. A proposal that repeats your brief back with formatting applied is evidence that somebody read it.
Are the assumptions written down? Every quote rests on assumptions about scope, about what you will provide, about what "done" includes. A proposal that lists them is telling you where the price could move and why. A proposal with none has the same assumptions, undisclosed, and you will meet them later as change requests.
Is the work broken into pieces with something visible at the end of each? Not a schedule of internal activities, but a sequence where you can see something at intervals. This matters more than the total duration, because it determines how early you would find out that things were going wrong.
Is there a number for what happens after launch? Software is not finished at launch. A proposal that stops at delivery is either omitting a cost you will meet later or has not thought about it. Our guide on technical debt covers why the second year costs more than people expect.
And a comparison note. When three quotes come back several times apart from each other, none of them is necessarily wrong. They reflect different assumptions about scope, different amounts of contingency, and different views of what finished means. The useful response is to ask each what they assumed, because the gap between quotes is almost always a gap in the brief rather than a difference in ability.
The method that works: a small piece of paid work
If you take one thing from this, take this.
Before any large commitment, buy two or three days of real work.
Not an interview task. Not an unpaid exercise. A genuine, small, useful piece of your actual project, paid at their normal rate.
What it reveals, none of which an interview can:
Whether their estimate held, and if it did not, when they told you.
Whether they asked about the parts you left unclear, or filled the gaps silently.
Whether problems reached you before you went looking for them.
Whether what arrived matched what you described.
Whether working with them was easy or effortful.
On paying: always. Unpaid trial work attracts people with no better options and repels people with a choice, which selects against precisely who you want. It also changes what you are entitled to expect. You are buying a few days of a real working relationship rather than staging an audition, and the behaviour you observe is genuine because the situation is.
On the task itself: real, small, and slightly underspecified on purpose.
Real, so the effort is not wasted and the stakes are honest. Small, so a wrong choice costs days rather than months. Underspecified, because how somebody handles a gap in the brief is the single most informative thing you will observe, and it never surfaces in an interview.
And on questions: somebody asking specific, well-framed questions early is preventing rework. That is what experience looks like from the outside. The concerning patterns are no questions at all, which means assumptions are being made silently, and unfocused questions suggesting the brief was never read. Our guide on writing a software brief covers making the brief good enough that the questions are the interesting ones.
Interview questions that work without technical knowledge
Ask about process and judgement rather than knowledge, because you can evaluate the former and not the latter.
"Walk me through how you would approach this." You are listening for whether they start with questions or with a solution. Anybody who arrives at an architecture before understanding the problem is telling you how the project will go.
"Tell me about a project that went badly and what you did about it." The best single question available to you. Experienced people answer immediately, with specifics, and include their own part in it. People who have not done much real work either have no example or produce one in which every problem belonged to somebody else. The difference requires no technical knowledge to hear.
"What would you need from us to succeed?" Good answers are specific and slightly demanding: a decision-maker available weekly, access to whoever understands the current process, a clear answer on a particular question. Vague answers, or "nothing really", suggest either inexperience or a plan to work in isolation and present a finished thing.
"How do you decide something is finished?" Our guide on good enough to launch covers why this matters more than it sounds. There is no correct answer; there is a difference between somebody who has thought about it and somebody who has not.
"What do you think is wrong with what we have now?" Only useful if they have looked. Which brings us to the next point.
The explanation test
Judge the explanation, not the content.
Somebody who understands a subject can explain it at the level of the person they are talking to. An answer that leaves you no better informed is either deliberately obscure or not genuinely understood, and neither is what you want in somebody whose explanations you will be relying on for months.
This is entirely fair to test, and it is the most useful instrument you have. Every decision you make during the engagement will rest on how well this person translates. Somebody who cannot or will not do that is a poor fit regardless of their ability.
A useful prompt: "Explain that to me as though I am going to have to repeat it to my board." It is a reasonable request, it is genuinely difficult to fake, and the response tells you how the next six months of updates will feel.
References, done properly
Written references are worth almost nothing. Speak to people, on a call rather than by message, because tone carries information that text does not.
Speak to somebody who managed the work, not a friendly contact who can vouch for their character.
Ask questions that have factual answers, because those get answered honestly even by a referee who wants to be helpful:
Did it finish on time?
Did the estimate hold?
What was the hardest part of working with them?
Was there a period where communication was difficult?
Would you use them again for something larger?
And listen to the pauses. The hesitation before an answer frequently carries more information than the answer. "Would you work with them again?" followed by three seconds of silence and then "yes, I think so" is a different response from an immediate yes.
On the objection that everybody offers favourable referees: they do, which is exactly why the questions matter more than the choice of referee. A friendly reference will still answer a specific factual question honestly, because lying about a date or an estimate is a different act from offering a warm general impression.
Borrowing technical judgement
Worth an afternoon of somebody competent, and it costs very little against the size of the decision.
Give them something specific. A general "what do you think" produces a debate about preferences. These four questions produce usable answers:
Does the approach fit the problem?
Would this be understandable to somebody else in a year?
Are there obvious gaps in security or error handling?
Does anything look unnecessarily complicated?
One caution. Developers can be harsh about choices they would have made differently, and that is not the same as the work being poor. Ask specifically whether a criticism is a genuine problem or a preference. A reviewer who cannot distinguish between the two is not helping you.
Red flags you can see without technical knowledge
An instant estimate. A considered estimate requires understanding the problem, and understanding takes longer than a conversation. An immediate number is either a guess presented as a figure or a price aimed at winning the work. Both end in the same conversation about why the number changed.
Reluctance to put things in writing. Everything agreed verbally is a disagreement waiting for a date.
Answers that get vaguer under follow-up. Ask the same question twice, phrased differently. Genuine knowledge gets more specific; the alternative gets more general.
No questions about your business. Somebody who wants to know only about the technical requirements is planning to build what was described rather than what is needed.
Dismissing a previous developer's work before looking at it. Specific criticism after examination is useful and is part of what you are paying for. Blanket dismissal before looking is a sales technique, and it frequently precedes a proposal to rebuild everything. Ask what they would keep, and see whether the answer contains any detail. Our guide on rebuild or fix covers how that decision should actually be made.
Reluctance to discuss what happens if it does not work out. The most telling of all, and the one people are most reluctant to raise. A supplier confident in the relationship has no difficulty discussing an exit.
Two mistakes non-technical buyers make repeatedly
Worth naming, because both feel like diligence at the time.
The first is over-weighting confidence. In the absence of a way to judge ability, confidence becomes the proxy, and it is a poor one. The person who says "that will be straightforward" is more reassuring than the person who says "that depends on three things I would need to check", and the second is almost always the better bet. Certainty about work not yet examined is not expertise; it is a personality trait, and sometimes a sales technique.
Watch for the inverse too. Somebody who says "I do not know, I would have to look" is displaying exactly the behaviour you want during the project, when the honest answer to a hard question saves you weeks. Punishing it during the interview selects for people who will not give it to you later.
The second is hiring the person who agrees with you. A supplier who accepts every request without pushing back is not being helpful, and the absence of friction early is not a good sign. Somebody who never says a request is a bad idea will build whatever you ask for, including the parts that were mistakes, and you will pay for those and then pay again to remove them.
The version of this that costs most is the feature list. You describe what you want, they agree it can all be built, nobody asks which parts matter, and the result is a large expensive product where a small one would have done. Our guide on saying no to features covers the discipline from your side, and a supplier who helps with it is worth more than one who does not.
A test for both. Ask what part of your plan they would drop, and what they think is the riskiest thing about the project. Somebody with real experience answers both. Somebody who says everything looks fine has either not thought about it or has decided not to tell you, and it does not matter much which.
Assessing an agency rather than a person
This is a different question from assessing an individual, and one specific thing dominates it.
Ask who will actually do the work, and meet them.
The people at the sales meeting are frequently not the people assigned. That substitution is where quality varies most, and it is entirely normal in the industry, which is why it needs to be asked about directly rather than assumed away.
Then ask:
How many people are on this, and what does each do?
How much of their time do we get?
Is any of this subcontracted to another company?
What happens if the person we just met leaves mid-project?
Subcontracting is not automatically a problem. Discovering it later is. And a supplier reluctant to answer that question directly has already told you something useful.
Get the answers in writing. Reassurance in a meeting is not a commitment. Our guide on checking a supplier before signing covers what belongs in the agreement, and our guide on suppliers blaming each other covers what happens when more than one is involved.
On location: it matters for working hours and for how easily a dispute can be resolved, more than for quality. A large time difference makes the daily rhythm harder and slows every clarification, which compounds. Judge that honestly against the price difference rather than assuming it will not matter.
Comparing candidates without a technical scorecard
Once you have run the process on three people, you have a comparison problem: a pile of impressions and no obvious way to weigh them.
Scoring technical ability is impossible for you and pretending otherwise produces a spreadsheet that looks rigorous and means nothing. Score the things you actually observed instead.
Six rows, each marked simply as better, similar, or worse than the others:
Did the trial estimate hold, and were you told early if it did not?
Did they surface the gap in the brief, or fill it silently?
Could you follow their explanations without effort?
Did their references answer the factual questions without hesitation?
Did they push back on anything?
Did the finished trial work match what you described?
That is a comparison you can defend to a partner or a board, because every row is something that happened rather than something you inferred.
On what to do when one candidate is clearly stronger on the soft rows and weaker on relevant experience: in most cases the soft rows win, and this surprises people. Relevant experience shortens the learning curve at the start. Communication and reliability determine whether the whole engagement works. A capable person learning your domain for two weeks is a smaller problem than a knowledgeable person you cannot get a straight answer from for six months.
The exception is where the domain genuinely carries hard constraints, such as regulated work or something with unforgiving correctness requirements. There, relevant experience is not a head start; it is the qualification, and no amount of good communication substitutes for it.
And a practical note on timing. Run the trials close together rather than sequentially over two months. Impressions decay, and comparing somebody you worked with in January against somebody you worked with in March produces a judgement about recency rather than about them.
Structuring the first month so a mistake is survivable
Assume you will occasionally be wrong. The businesses that get badly hurt are not the ones that chose poorly; they are the ones with no way out.
Get access from day one. Code repository, hosting, domain, any third-party accounts, all in your name from the first week. This is the single most important protection available to you, and it is the difference between a bad engagement costing you weeks and costing you your product.
Ask early, and treat reluctance as the answer to a much larger question. Our guide on getting your data out covers the same principle applied to systems you already run.
Agree ownership in writing before anything is built. Everything produced belongs to you, including work done by anybody they subcontract, which is the part most commonly left ambiguous.
Define how changes are handled, so the first change request is not also the first argument.
Set a review point four weeks in, agreed in advance as a normal part of the process rather than something introduced when you are already unhappy. Reviews scheduled at the start are unremarkable and everybody prepares for them calmly. Reviews introduced later are an accusation, and they change the relationship whether or not anything is actually wrong.
Watching the first month
You cannot read the code. You can read all of these, and they are available to you from the first week.
Ask to see it working, early and regularly. Not a walkthrough of screens, but the actual thing doing the actual task, even partially. Anybody genuinely making progress can show something.
Percentages are not evidence. "Seventy per cent done" is a report about work, not proof of it, and it is the easiest thing in the world to produce. Ninety per cent complete is a well-known resting place for projects that are considerably less complete than that.
If you do not understand a demonstration, say so and ask to see the part that matters to your business instead. A demonstration you cannot follow has not demonstrated anything. The request also tests something useful: whether they can connect their work to your outcome, or whether they are only comfortable describing what they built.
Four early signals worth acting on immediately:
Progress described in percentages rather than in things you can look at.
Updates that arrive only when you ask for them.
Estimates that move without explanation.
A widening gap between what you thought was agreed and what is being built.
Any of those in the first month deserves a conversation that week. Our guide on being a good client covers your half of the same relationship, which is not a small factor in how it goes.
Hiring an employee rather than contracting
Different decision with the same assessment problem underneath, plus one addition.
Contract for a defined piece of work with an end. Hire when the work is continuous and you need somebody who accumulates knowledge of your business over years.
Hiring first, before you know what needs building, is the more common and more expensive mistake. Our guide on the first technical hire covers when that point actually arrives.
The addition for a permanent role: can they work without a technical manager? You cannot be one. That means judgement about what to prioritise, willingness to say no to a request, and comfort explaining trade-offs to colleagues who do not share their background.
In a first technical hire, those matter more than raw ability. A brilliant developer who needs direction from somebody more senior is a poor first hire, however good the code is, because the direction is not available.
The cost of doing this properly
The assessment is cheap. That is the point worth ending on.
A paid trial piece is a few days at somebody's rate. An afternoon of independent technical review is less than most businesses spend on a single month of the wrong engagement. Reference calls cost an hour of somebody's time, and usually less than that.
Set against six months producing something unusable, plus the time lost, plus starting again, all of it is close to free.
And the one change worth making: stop trying to evaluate skill and start observing behaviour. Give a small paid piece of real work, watch how they handle the parts you deliberately left unclear, and check whether what arrived matches what you described.
That single change tells you more than a month of interviews, and it costs less than almost any alternative available to you.
If you would rather not do it alone, an independent technical assessment covering the supplier's proposal, an interview of the people who would actually do the work, a review of anything already built, and a written recommendation starts from around AED 5,000 with us. Ongoing technical oversight during a project is quoted separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- SKIMBOX, how to write a software brief
- SKIMBOX, checking a software supplier before signing
- SKIMBOX, your first technical hire in the UAE
- SKIMBOX, how to be a good client
- SKIMBOX, when suppliers blame each other
- SKIMBOX, rebuild or fix a legacy system
- SKIMBOX, getting your data out
- SKIMBOX, good enough to launch
- The Official Portal of the UAE Government, employment and labour
